In message: <200305051435.12481.ebakke_at_trolltech.com> "Erik H. Bakke" <ebakke_at_trolltech.com> writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Monday 05 May 2003 14:22, M. Warner Losh wrote: : > : Or use modules.. : > : The vast majority of drivers are loadable as modules. It would be : > : feasible to standardise the PCI ID tables of drivers and then generate a : > : list from it which you can use to load modules for cards you find. : > : > There's more than just pci ID. Also, there are a couple of drivers : > that don't base their decision on the pci id, but other things in the : > headers to attach to all devices of a certain class. This makes : > autoloading a little harder. : > : Wouldn't this be the drivers that would always be on the kernel floppy? Not necessarily. Cardbus bridges fall into this category as do many of the usb drivers and some of the bluetooth stuff. This is in addition to the sio, ppc, and those sorts of generic drivers. : I think the drivers that would be candidates for autoloading based on PCI ID : would be more specialized drivers, and typically not drivers for things such : as IDE controllers, bus bridges, etc. These are good candidates. You really only need your '/' device compiled into the kernel. All else can be autoloaded. There's an issue with cam scsi drivers at the moment that requires a userland workaround (camcontrol rescan) when you load one of these drivers. You really want something like devd to do the loading, but that might be merged into sysinstall. Standardizing the drivers so that one can generate the tables isn't too hard, but is tedious and leads into many-a-bikeshed for unsuspecting victums. WarnerReceived on Mon May 05 2003 - 03:45:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:06 UTC