Subject: Re: PCI device recognition
To: Nathan J. Williams <email@example.com>
From: Darren Reed <firstname.lastname@example.org>
Date: 11/16/2004 08:47:32
While I have your attention, have you had a look at kern/27023?
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
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.