This is slightly unfair of me. I posted these questions with
reasonably clear answers of my own in mind, but did not speak them.

Bill Studenmund <wrstuden@netbsd.org> writes:

> I think we should have two tables. The one that matters is the one in the 
> kernel. The other one would be a userland one.

So the kernel would look something up, and then somehow if it didn't
find something this fact would be communicated to userland to try and
see if there's a handy LKM avaliable?

> >  * What would be the mechanism for updating the table?
> 
> My thought is that it'd get updated by loading a driver into the kernel.

The point is to separate the driver from the table entirely. Given,
say, tlp and de, or the current ath driver and a reverse-engineered
one, both drivers would have conflicting entries. Which of competing
drivers is to be preferred is likely to be a policy decision, not
something the drivers can encompass.

> >  * Which identifers would be handled? (On PCI, for example, this could
> >    include vendor, device, subsystem vendor, subsystem device, class,
> >    subclass, interface, and revision).
> 
> Not sure. The ones we match on now would be good.

Well, part of the problem here is that a PCI device's match routine
isn't constrained at all. It can check the phase of the moon or only
decide to load up on alternate Thursdays.

> >  * 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'd expect we want to have these tables really list candidate drivers. 
> So I'd think we'd want to still call each driver's match routine.

See above about drivers not being able to encompass policy decisions.

> >  * 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?
> 
> I'd expect yes. I think this bit's still important. Among other things,
> given our config methodology, we also get a measure of the quality of a
> match.

That "quality" measure is only for conflict-resolution purposes; as
I've said, I think that's wrong. I also think that the quirks/features
should be in the table; a large part of the point is to be able to add
new entries, and adding an entry often means telling the driver which
subtype to treat a device as. If the submodel list is in the driver,
then adding a previously unknown device will require recompiling the
driver, and avoiding that was the whole point.

My belief is that in a table-driven world, match routines would
disappear, but attach routines would be permitted to fail in
extordinary circumstances (more like "I know that revision 17 of this
chip will self-destruct if I start to use it", and not "I don't think
I know what this is").

> A big win we'd still get is for any given device, we only bother calling 
> match routines that have a chance of working.

I don't see that match routines add any benifit at all in a
table-driven world. Getting rid of the call-all-match-functions would
be a slight benefit, but I doubt it's significant.

Finally, I think we should all consider this topic dead until and
unless someone writes working code. We can chat all day about how we'd
like it to work, but it's pretty pointless if nobody's going to go
ahead.

        - Nathan