Subject: Re: PCI device recognition
To: Nathan J. Williams <nathanw@wasabisystems.com>
From: Darren Reed <avalon@cairo.anu.edu.au>
List: tech-kern
Date: 11/16/2004 08:47:32
Hi Nathan,

While I have your attention, have you had a look at kern/27023?
Any thoughts?

Back to PCI..

You've taken it a step beyond what I was thinking but perhaps it
is a logical extension of the direction my thoughts were headed
in making the whole driver/device association table driven ?

Some answers to your questions that I think make sense:

>  * Would the table live only in the kernel? That's probably the
>    simplest thing, but one can imagine keeping only a minimal set of
>    entries in the kernel for booting, and calling out to some userland
>    app or socket or something for either the contents of the rest of
>    the table; or having the kernel pass all the identifying
>    information out and putting all of the table and rules in userland.

I think having the kernel call out to userland is a bad idea.
I'd rather see a minimal table in the kernel to boot and then
drvctl load the "full table" early.

>  * What would be the mechanism for updating the table?

Run some program that takes input either via command line
options or some configuration file and talks to the kernel ?

>  * Which identifers would be handled? (On PCI, for example, this could
>    include vendor, device, subsystem vendor, subsystem device, class,
>    subclass, interface, and revision).

There should be the capability to match on any or all of them.

Is there a natural hierarchy in the fields about what is considered
to make up the most specific match ?

>  * What rules would be used for matching and for resolving conflicts
>    (say one rule matches by PCI class and subclass and another matches
>    by vendor and device)?

I think vendor & device are more specific than PCI class/subclass,
so vendor/device should be given priority ?

>  * How would the quirk/chipset-variant options be handled? In the
>    drivers as now, or as a parameter in the table passed to the
>    driver?

I think they have to be per-driver.

>  * Would drivers still be given an opportunity to accept or reject a
>    match from the table?

If all the device/driver matching is table driven then yes.

Darren