svn commit: r222980 - in head/sys: amd64/conf i386/conf

Daniel O'Connor doconnor at gsoft.com.au
Sun Jun 12 23:53:38 UTC 2011


On 13/06/2011, at 7:46, Warner Losh wrote:
>> ISTR there a few modules which call some blob to determine if the module is supported but I think it's quite rare (the 80/20 rule works for me here :)
> 
> I've looked into this extensively.  usb comes the closest right now, since nearly all of its drivers use the right interface to match driver to device.  There is a standard structure people use.  However, even it is impossible to extract this data in a reliable automated fashion.  Ideally, these tables would move to their own section which could then be extracted by a tool to see when to load it.  This section would also need some additional metadata in it so we know how to interpret the section.
> 
> The situation with the PCI bus is much less uniform.  While many drivers have tables, these tables are all ad-hoc.  There's no standard structure so everybody invents their own.  In addition to annotating the tables, you'd have to regularize them all across all pci drivers.  Doing this for 100+ drivers is a bit tedious.  Also, there are at least two cases where we have to load two drivers to be sure that one of them attaches because there's matching done outside of the normal plug and play identifiers (eg vendor/device/function/subvendor/subdevice) in their probe routines.

> PC Card has also had the standard structure and interface for many years.  When I tried to move this to PCI many years ago, I encountered a lot of resistance that didn't make sense to me at the time (so I can't do it justice now).  This should tell you how long the problem has languished.  It was the primary motivator behind writing devd, but the pci resistance lead me to put aside the problem for a while.  I'll be happy to pick it back up, especially if I can get some help going through all the drivers and tagging things appropriately.

I would be interested in helping, certainly with the mechanical changes.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C








More information about the svn-src-all mailing list