On Jun 12, 2011, at 8:46 AM, Daniel O'Connor wrote: > On 12/06/2011, at 20:51, Alexey Dokuchaev wrote: >>> I think trasz@ tried that and there is a problem. Loading modules on >>> boot is very slow. If you try to load everything that GENERIC has as >>> modules the boot will take forever. >> >> Perhaps then we need to come up with something more intelligent, i.e. do not >> load everything trying to get maximum coverage of users' hardware, but >> load only required bits based on what we see on PCI bus (roughly speaking). > > Now the tricky part is extracting supported device IDs from drivers in an > automatic fashion :) > > I imagine some symbol magic could be done for the general case so a tool > could extract the IDs & the bus type (so it could work for PCI & USB which > covers about 99.9% of the hardware in question). > > 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. Warner_______________________________________________ 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"
