Darren Reed <avalon@cairo.anu.edu.au> 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
   driver?

 * 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").

        - Nathan