From owner-svn-src-all@FreeBSD.ORG Sun Jun 12 22:19:32 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1D0106566C; Sun, 12 Jun 2011 22:19:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B67A78FC0C; Sun, 12 Jun 2011 22:19:31 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5CMG5Su067245 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 12 Jun 2011 16:16:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <94A51677-0181-471A-B4D6-DC596C7BCBFD@gsoft.com.au> Date: Sun, 12 Jun 2011 16:16:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5506A922-E3FF-477D-AB12-4B47C4D6CE04@bsdimp.com> References: <201106110908.p5B98kkE066709@svn.freebsd.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> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 12 Jun 2011 16:16:08 -0600 (MDT) Cc: Alexey Dokuchaev , src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, Adrian Chadd , Robert Watson , Joel Dahl , svn-src-head@freebsd.org Subject: Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:19:32 -0000 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=