Date: Mon, 13 Jun 2011 09:23:26 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Warner Losh <imp@bsdimp.com> 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: <D6F16B31-03B5-46A6-8E78-A8E7440E9DA7@gsoft.com.au> In-Reply-To: <5506A922-E3FF-477D-AB12-4B47C4D6CE04@bsdimp.com> 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> <5506A922-E3FF-477D-AB12-4B47C4D6CE04@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :) >=20 > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6F16B31-03B5-46A6-8E78-A8E7440E9DA7>