Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Mar 2006 18:58:30 +0300
From:      Yar Tikhiy <yar@comp.chem.msu.su>
To:        Scott Long <scottl@samsco.org>
Cc:        current@freebsd.org, cokane@freebsd.org, Coleman Kane <cokane@cokane.org>
Subject:   Re: RFC: separate 3dfx_linux module
Message-ID:  <20060301155829.GB84296@comp.chem.msu.su>
In-Reply-To: <44034201.4040304@samsco.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060301155829.GB84296>