Date: Sun, 3 Jul 2011 19:51:30 -0500 From: Warner Losh <imp@bsdimp.com> To: "Ronald Klop" <ronald-freebsd8@klop.yi.org> Cc: svn-src-head@freebsd.org, Alexey Dokuchaev <danfe@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, Hans Petter Selasky <hselasky@freebsd.org> Subject: Re: svn commit: r223519 - head/etc/devd Message-ID: <A33DB2B5-C874-40D5-ADEC-F56C79BE66FF@bsdimp.com> In-Reply-To: <op.vx1lolht8527sy@212-182-167-131.ip.telfort.nl> References: <201106242132.p5OLW3DL071062@svn.freebsd.org> <op.vxofipu38527sy@pinky> <CAEA5F96-D0B6-4A82-A137-5886A7CE5718@bsdimp.com> <20110628084558.GA35392@FreeBSD.org> <9521FD1A-3D77-4F37-B37C-CC73B13BC6B5@bsdimp.com> <op.vx1lolht8527sy@212-182-167-131.ip.telfort.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 3, 2011, at 7:15 AM, Ronald Klop wrote: > On Tue, 28 Jun 2011 18:01:37 +0200, Warner Losh <imp@bsdimp.com> = wrote: >=20 >>=20 >> On Jun 28, 2011, at 2:45 AM, Alexey Dokuchaev wrote: >>=20 >>> On Sun, Jun 26, 2011 at 10:14:13PM -0600, Warner Losh wrote: >>>> Not in GENERIC. 9.0 is getting ready to feature freeze any minute, = so >>>> there's no time to do the testing that a radical change like that = would >>>> require. >>>=20 >>> Fair enough. Right now, this work seems to cover only USB kernel = modules, >>> is it so? Is expansion into generic PCI area also planned, provided = that >>> you've already had some ideas and seem to be willing to pick up the = work >>> given enough support from the other developers (please excuse me if = my >>> understanding is wrong)? >>=20 >> The reason we were able to relatively quickly generate this file from = USB is because USB is very regular and uniform in its probe routines. = They all have (or could be converted to have) something approximating = the same format. >>=20 >> PCI isn't even remotely close to this, and the techniques that worked = for USB (and some of the short cuts taken) can't work for PCI for us. = There's no uniformity in the PCI space, although many of the PCI drivers = use a similar design pattern. They would all have to be converted to = using the same thing, which is kinda impractical at the moment (since = many have additional, driver specific fields). While the tool is kinda = flexible enough to cope with this situation, more and more code winds up = in the tool to cope than is appropriate for the tool. >>=20 >> That's why this feature is experimental. For what it works for, it = works great. For everything else, it is a lot of work to make it happy = on a wide-spread enough scale. It is very instructive for how to = approach things, but embeds too much knowledge of the bus code into the = tool to generate these files than is appropriate (since it is duplicated = information from the driver, not exported from the bus/driver). >>=20 >> Warner >=20 > Maybe something for a GSOC 2012 project? Yes. that would make a good GSOC for the right student... It would = also scale well depending on the students skills. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A33DB2B5-C874-40D5-ADEC-F56C79BE66FF>