Date: Sun, 26 Jun 2011 00:00:27 -0600 From: Warner Losh <imp@bsdimp.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Jeremy Messenger <mezz.freebsd@gmail.com>, Robert Millan <rmh@debian.org>, freebsd-current@FreeBSD.org Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] Message-ID: <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> In-Reply-To: <201106260738.21847.hselasky@c2i.net> References: <201106242342.47194.hselasky@c2i.net> <ACCD2B48-1E78-42B6-883E-542FDFD567F6@bsdimp.com> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FC50F07-2C7B-4DD4-A75C-49001CFEF85D>