From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 06:02:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16641065670 for ; Sun, 26 Jun 2011 06:02:20 +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 952FB8FC0A for ; Sun, 26 Jun 2011 06:02:20 +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 p5Q60U9h038569 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 26 Jun 2011 00:00:31 -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: <201106260738.21847.hselasky@c2i.net> Date: Sun, 26 Jun 2011 00:00:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> To: Hans Petter Selasky 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, 26 Jun 2011 00:00:32 -0600 (MDT) Cc: Jeremy Messenger , Robert Millan , freebsd-current@FreeBSD.org Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 06:02:21 -0000 On Jun 25, 2011, at 11:38 PM, Hans Petter Selasky wrote: > On Saturday 25 June 2011 19:07:01 Hans Petter Selasky wrote: >> On Saturday 25 June 2011 18:45:14 Warner Losh wrote: >>> On Jun 25, 2011, at 9:42 AM, Hans Petter Selasky wrote: >>>> On Saturday 25 June 2011 01:05:26 Jeremy Messenger wrote: >>>>> Jeremy Messenger >>>>=20 >>>> Done. >>>>=20 >>>> http://svn.freebsd.org/changeset/base/223536 >>>=20 >>> Please move it back. It doesn't belong in /etc/defaults. It = belongs in >>> /etc/devd if we're going to have it at all. If you have a full = GENERIC >>> kernel, there will never be a NOMATCH line generated, so these = entries >>> will just be ignored. >>>=20 >>> Warner >>=20 >> Done. >>=20 >> http://svn.freebsd.org/changeset/base/223543 >>=20 >=20 > Hi, >=20 > I see that a lot of PCI device drivers use code to check their ID's. >=20 > One simple way to dump all the PCI device ID's is to compile or load = all=20 > modules and then make a dummy PCI device, which only calls = device_probe on the=20 > full 32-bit space of the pci_get_devid(). This should take in matter = of some=20 > minutes to produce a complete list of PCI ID's. Then add these ID's to = all the=20 > respective drivers like a generic device ID table: >=20 > struct pci_device_id { > uint32_t device_id; > uint32_t card_id; > const char *description; > unsigned long driver_info; > } __aligned(32); >=20 > Then export those automatically generated structures into the = "pci_device_id"=20 > section and have tools/bus_autoconf generate the matching rules. >=20 > PCI format structure for bus_autoconf: >=20 > "pci_device_id{256,:}" > "device_id[0]{" U32_XOR ",8}" > "device_id[1]{" U32_XOR ",8}" > "device_id[2]{" U32_XOR ",8}" > "device_id[3]{" U32_XOR ",8}" >=20 > "card_id[0]{" U32_XOR ",8}" > "card_id[1]{" U32_XOR ",8}" > "card_id[2]{" U32_XOR ",8}" > "card_id[3]{" U32_XOR ",8}" I like the idea of having a standardized table. I've done this with PC = Card and it really works well. It isn't the design pattern that all = drivers use, and it may be hard to get everyone lined up on this. I = tried PCI back after I did PC Card and met resistance. Most of the = resistance was from people that are no longer active in the project, so = I think that we could do this today. I suspect that some of the vendor = drivers today might stand in the way of having PCI be completely = uniform. The big advantage of USB is that it is uniform now. PCI isn't. It = would take a lot of work to make it uniform. Also, like I was saying on IRC, I don't like the fact that we have to = have different bus code in this automatic tool. It shouldn't know nor = care about what the bus or drivers do. The drivers should export a = table and a descriptor for the table that would allow it to either = generate the devd.conf lines needed to do the matching, or for some = other program to examine the pnp_string information from newbus and = figure out which module(s) to load. Also, I don't find the above syntax = easy to read or understand (sorry). Don't get me wrong. I love the USB autoload code you've done so far, = but I consider it more of a prototype for the final system than the = final system itself. Warner=