Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jul 2011 14:15:46 +0200
From:      "Ronald Klop" <ronald-freebsd8@klop.yi.org>
To:        "Alexey Dokuchaev" <danfe@freebsd.org>, "Warner Losh" <imp@bsdimp.com>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Hans Petter Selasky <hselasky@freebsd.org>
Subject:   Re: svn commit: r223519 - head/etc/devd
Message-ID:  <op.vx1lolht8527sy@212-182-167-131.ip.telfort.nl>
In-Reply-To: <9521FD1A-3D77-4F37-B37C-CC73B13BC6B5@bsdimp.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Jun 2011 18:01:37 +0200, Warner Losh <imp@bsdimp.com> wrote:

>
> On Jun 28, 2011, at 2:45 AM, Alexey Dokuchaev wrote:
>
>> 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, s=
o
>>> there's no time to do the testing that a radical change like that wou=
ld
>>> require.
>>
>> Fair enough.  Right now, this work seems to cover only USB kernel =20
>> modules,
>> is it so?  Is expansion into generic PCI area also planned, provided =20
>> that
>> you've already had some ideas and seem to be willing to pick up the wo=
rk
>> given enough support from the other developers (please excuse me if my
>> understanding is wrong)?
>
> The reason we were able to relatively quickly generate this file from =20
> USB is because USB is very regular and uniform in its probe routines.  =
=20
> They all have (or could be converted to have) something approximating =20
> the same format.
>
> PCI isn't even remotely close to this, and the techniques that worked =20
> for USB (and some of the short cuts taken) can't work for PCI for us.  =
=20
> There's no uniformity in the PCI space, although many of the PCI driver=
s =20
> use a similar design pattern.  They would all have to be converted to =20
> using the same thing, which is kinda impractical at the moment (since =20
> many have additional, driver specific fields).  While the tool is kinda=
 =20
> flexible enough to cope with this situation, more and more code winds u=
p =20
> in the tool to cope than is appropriate for the tool.
>
> That's why this feature is experimental.  For what it works for, it =20
> works great.  For everything else, it is a lot of work to make it happy=
 =20
> on a wide-spread enough scale.  It is very instructive for how to =20
> approach things, but embeds too much knowledge of the bus code into the=
 =20
> tool to generate these files than is appropriate (since it is duplicate=
d =20
> information from the driver, not exported from the bus/driver).
>
> Warner

Maybe something for a GSOC 2012 project?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.vx1lolht8527sy>