RFC: separate 3dfx_linux module

[Yar Tikhiy]

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