Subject: Re: PCI device recognition
To: Darren Reed <firstname.lastname@example.org>
From: Nathan J. Williams <email@example.com>
Date: 11/15/2004 12:29:38
Darren Reed <firstname.lastname@example.org> writes:
> How hard would it be to make it possible to add PCI vendor/device
> IDs to the list a device recognises, at run time ?
It would be a fair bit of work, but mostly mechanical. I think it's
been desirable for a while to move from the model we have now for
direct-config buses, where each driver checks its suitability for each
device on its bus-type, to something more table-driven, where a
device's ID information is looked up and mapped to a driver. The
details are tricky, of course:
* 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.
* What would be the mechanism for updating the table?
* Which identifers would be handled? (On PCI, for example, this could
include vendor, device, subsystem vendor, subsystem device, class,
subclass, interface, and revision).
* 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)?
* How would the quirk/chipset-variant options be handled? In the
drivers as now, or as a parameter in the table passed to the
* Would drivers still be given an opportunity to accept or reject a
match from the table?
This work could apply to all the direct-config buses, and so would
probably fit in better with the new drvctl(4,8) interface than
something PCI-specific (I'll note that we already have rescan
implemented for PCI, as "drvctl -r").