Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load

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=
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[e-mail]"