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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
