From owner-svn-src-head@FreeBSD.ORG Tue Jun 28 16:07:58 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAC64106564A; Tue, 28 Jun 2011 16:07:58 +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 49F008FC16; Tue, 28 Jun 2011 16:07:58 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5SG3BKF070339 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 28 Jun 2011 10:03:14 -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: <20110628084558.GA35392@FreeBSD.org> Date: Tue, 28 Jun 2011 10:01:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9521FD1A-3D77-4F37-B37C-CC73B13BC6B5@bsdimp.com> References: <201106242132.p5OLW3DL071062@svn.freebsd.org> <20110628084558.GA35392@FreeBSD.org> To: Alexey Dokuchaev 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]); Tue, 28 Jun 2011 10:03:15 -0600 (MDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Hans Petter Selasky , Ronald Klop Subject: Re: svn commit: r223519 - head/etc/devd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:07:58 -0000 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, = 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)? 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. 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. 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). Warner