cvs commit: src/release/alpha dokern.sh drivers.conf

[Scott Long]

Daniel O'Connor wrote:
> [moved to -hackers]
> 
> On Tue, 20 May 2003 11:07, Scott Long wrote:
> 
>>The third step is to make the installer actually install the
>>user-supplied drivers.  Right now sysinstall has an option for loading
>>KLD's from floppy, but that is all that it does.  It doesn't help much
>>when the driver you are loading is the storage driver for your
>>installtion, and once you reboot the driver is not loaded automatically.
> 
> 
> You'd need some way of knowing whether it's worth trying to load the module - 
> IMHO that is the difficult bit - it requires the most change to existing code 
> and is more likely to break things.
> 
> 
>>I've wanted to work on this for quite a while, but I'm not sure I want
>>to further the viability of sysinstall.  However, others with less of a
>>dislike of sysinstall are welcome to take this proposal and run with it.
> 
> 
> If you tell me how to work out whether it's worth loading a given module from 
> a floppy I will quite happily write the code to implement it.
> 
> Currently there is no special section which tells you whether you should try 
> and load something because a known PCI ID is present (for example - and yes I 
> know some modules use other criteria, but IMHO checking PCI ID's is a good 
> start)
> 
> You could just trying loading every module on a disk but that is slow and you 
> can't really tell if the loaded module actually did anything useful without 
> kludgery.
> 
> IMHO the module itself should hold descriptions and lists of ID's, but if they 
> have to be in a separate file then so be it.
> 
> Currently I don't see a way of extracting PCI IDs from module source in a 
> standard way which means the lists would have to be maintained manually and 
> that would _suck_. Perhaps some standard struct array could be used, and if 
> it isn't present then you can't do a guess about whether to load the module 
> or not, so you just prompt the user.
> 


Having dealt with it in FreeBSD, SuSE, and RedHat, I see four
possibilities.

1.  The RedHat way: driver floppies carry a pci-id table file of id's 
that the driver supports.  RedHat of course is a bit silly about this
since their table only covers the Device and Vendor ID's and leaves out
the sub-* Id's.  It also doesn't have any wildcard matching
capabilities.  Also, it  requires a separate effort to keep this table
in sync with the driver.  Certain scripting magic might be employed to
help with this.

2.  The SuSE way: driver disks contain only modules, and are loaded in
a brute-force manner.  I'm not really sure if they know that a driver
succeeded/failed to load, and I think they just blindly install whatever
drivers the user supplied.

3.  Update the driver API to include requirements to give a PCI ID table
in a certain format, and then update the module building framework to
take this table and turn it into an elf section or something similar.

4.  Update the kldload semantics so that the kldload syscall returns an
indication of the driver's attach success/failure.  This will allow the
brute-force method to intelligently work.

Scott