Re: MODULE_CLASS_DRIVER and locators stuff

[Andrew Doran <ad%netbsd.org@localhost>]

Hi,

On Sat, May 03, 2008 at 12:50:07PM +0200, Juan RP wrote:

> module loaded
> auich: cfdriver_attach sucess
> auich: cfattach_attach success
> Intel 82915GM/GMS IGD Companion (miscellaneous display, revision 0x04) at
> pci0 dev 2 function 1 not configured
> 
> auich0 at pci0 dev 30 function 2: i82801FB (ICH6) AC-97 Audio
> auich0: interrupting at ioapic0 pin 17 (irq 10)
> auich0: ac97: Analog Devices AD1981B codec; headphone, 20 bit DAC, no 3D
> stereo
> auich0: ac97: ext id 605<AC97_22,AMAP,SPDIF,VRA>
> auich0: measured ac97 link rate at 47999 Hz, will use 48000 Hz
> audio1 at auich0: full duplex, mmap, independent
> Intel 82801FB/FR AC'97 Modem Controller (modem communications, revision
> 0x04) at pci0 dev 30 function 3 not configured
> Texas Instruments PCI7x21/7x11 Integrated FlashMedia Controller
> (miscellaneous mass storage) at pci2 dev 6 function 3 not configured
> Texas Instruments product 0x8034 (SD Host Controller system) at pci2 dev 6
> function 4 not configured
> auich: cfdata_attach success
> 
> audio1: detached
> auich0: detached
> auich: cfdata_detach success
> auich: cfattach_detach success
> auich: cfdriver_detach success
> module unloaded

Cool! It would be great to get the audio drivers out of GENERIC and into
loadable modules.
 
> The patch is available at:
> http://www.netbsd.org/~xtraeme/locs_kmod.diff

I have a couple of problems with the approach:

First I think we'd be falling into the LKM trap by putting a bunch of class
specific code into the module system. :-). I think that it doesn't belong
there: as I see it, all the module framework really needs to do is get the
module loaded, linked and call its mi_modcmd() routine so that it can get
itself noticed by the rest of the kernel. I think that the driver attachment
code should belong to autoconf, not kern_module.c.

Second, you can build modules into the kernel and they operate mostly like
loadables. There shouldn't be a need for seperate wrapper code under
sys/modules. The ideal solution would be a Makefile under modules/auhci that
pulls in the existing sources and does nothing else. You can do this with
file systems already, for built-in drivers we probably need a
module_init_class(MODULE_CLASS_DRIVER) somewhere in or around configure(),
so that they're available at the right time.

So the idea is that drivers would link into the system the same way,
irrepective of whether or not they were built into the kernel. Problems:

- Autoconf already has an way to establish drivers, linking them into
  tables etc. We already have the cfattach data and so on. Problem because
  it's also the way that we get the object code into the kernel in the first
  place.

- When loading drivers from the file system, we probably want to pick up
  a prop dictionary that contains locators / options etc. If a driver
  is built into the kernel, that info already exists in another form.

We could add a flag for config(1) that indicates that a particular driver is
modular and will register itself, but what would you do about locators? I
don't have good ideas at this point.

Thanks,
Andrew