Date: Sun, 12 Jun 2011 16:16:03 -0600 From: Warner Losh <imp@bsdimp.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Alexey Dokuchaev <danfe@freebsd.org>, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, svn-src-all@freebsd.org, Adrian Chadd <adrian@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Joel Dahl <joel@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf Message-ID: <5506A922-E3FF-477D-AB12-4B47C4D6CE04@bsdimp.com> In-Reply-To: <94A51677-0181-471A-B4D6-DC596C7BCBFD@gsoft.com.au> References: <201106110908.p5B98kkE066709@svn.freebsd.org> <alpine.BSF.2.00.1106111403060.44950@fledge.watson.org> <BANLkTik%2B-gVXGQkFmTH%2Bm2hswfnrRcawrg@mail.gmail.com> <alpine.BSF.2.00.1106111445460.44950@fledge.watson.org> <75DAEF7E-F43E-427E-8AFA-586E0B56D450@bsdimp.com> <20110611184549.GB3284@garage.freebsd.pl> <20110612112150.GB62801@FreeBSD.org> <94A51677-0181-471A-B4D6-DC596C7BCBFD@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>=20 >> 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). >=20 > Now the tricky part is extracting supported device IDs from drivers in = an automatic fashion :) >=20 > 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). >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5506A922-E3FF-477D-AB12-4B47C4D6CE04>