From owner-freebsd-current@FreeBSD.ORG Wed Mar 1 15:58:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CC5916A420; Wed, 1 Mar 2006 15:58:57 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934D843D55; Wed, 1 Mar 2006 15:58:49 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id k21FwZpV084875; Wed, 1 Mar 2006 18:58:35 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id k21FwUCv084870; Wed, 1 Mar 2006 18:58:30 +0300 (MSK) (envelope-from yar) Date: Wed, 1 Mar 2006 18:58:30 +0300 From: Yar Tikhiy To: Scott Long Message-ID: <20060301155829.GB84296@comp.chem.msu.su> References: <20060225140509.GC79616@comp.chem.msu.su> <44008314.8030205@samsco.org> <20060225201102.GA6936@pint.candc.home> <20060227121305.GO6435@comp.chem.msu.su> <20060227175740.GA6099@pint.candc.home> <44033D92.2020009@samsco.org> <20060227181610.GB6099@pint.candc.home> <44034201.4040304@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44034201.4040304@samsco.org> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org, cokane@freebsd.org, Coleman Kane Subject: Re: RFC: separate 3dfx_linux module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 15:58:57 -0000 On Mon, Feb 27, 2006 at 11:16:33AM -0700, Scott Long wrote: > Coleman Kane wrote: > >On Mon, Feb 27, 2006 at 10:57:38AM -0700, Scott Long wrote: > > > >>Coleman Kane wrote: > >> > >>>On Mon, Feb 27, 2006 at 03:13:05PM +0300, Yar Tikhiy wrote: > >>> > >>> > >>>>It was exactly my point, too: the TDFX_LINUX option has to be there > >>>>so that people still can compile device tdfx with Linux support into > >>>>the main kernel file. > >>> > >>> > >>>Not to mention so that they can omit said functionality if it is not > >>>desired. I believe that the kmod by default compiles this in though. > >>> > >>> > >>> > >>>>-- > >>>>Yar > >> > >>Ok, I envisioned this as: > >> > >>device tdfx > >>device tdfxlinux # Optional Linux compatibility > >> > >>I don't have a strong opinion on it, and I'll defer to whatever Coleman > >>and Yar think is most appropriate. > > > > > >My impression was more that the current config format would stay the > >same, but there'd be separate modules (rather than incorporating it all > >into tdfx.ko): > >tdfx.ko > >tdfx_linux.ko > > > >Much like how wlan.ko and wlan_*.ko operate? > > > > Well, we are talking about different things here, I think. I absolutely > agree with having separate .ko files, regardless of what kernel options > or devices are specified. What I'm wondering about is when building the > tdfx driver into the kernel, does the tdfx-linux functionality come in > via an 'option' or a 'device'. If it's an 'option', does that mean that > you can load the tdfx_linux.ko module into a kernel that has the tdfx > device included? It should be possible, as tdfx_linux.ko just installs an ioctl handler in the linuxolator. tdfx_linux.ko could be loaded in a kernel without tdfx at all, too, because it doesn't have explicit dependency on the tdfx code, it just converts an ioctl data structure using basic C types; but it would be little sense in such possibility, so I added MODULE_DEPEND(tfdx) to tdfx_linux.ko so that people can just kldload tdfx_linux and get all the stuff in the kernel at once. I really don't care about how the functionality will be reflected in the kernel conf file because I've never used the tdfx thingie. I just tried to keep the old way of things so that users don't complain that their old kernel conf files stopped working in 6.1-RELEASE: POLA and all that. OTOH, in perspective, it's better for tdfx_linux to be a `device' so that the separate module can be built based only on the /sys/conf data, without the limited /sys/modules framework. -- Yar