In message <FL9oI7.1uw@tac.nyc.ny.us>, you write: 

-> In article <199911151852.TAA0000022046@zel459.zel.kfa-juelich.de>,
-> Matthias Drochner <M.Drochner@fz-juelich.de> wrote:
-> >
-> >This would make some sense. There would be some waste of memory
-> >because there are PnP BIOS devices which never show up as ISAPnP
-> >and vice versa, but this wouldn't be too much.
-> >What I don't like about the way isapnpdevs is implemented is that
-> >there is a somewhat arbitrary distinction between device IDs
-> >and compatible IDs. An ID is an ID and has its meaning whether
-> >the hardware vendor has chosen it as primary or compatible ID.
-> >There could be more code shared, but the isapnp code would need
-> >some restructuring first.
-> 
-> I beg to differ. Vendor specific id's are nice because then you
-> can provide custom drivers that take advantage of extra features
-> that are not available in the lowest-level-common-denominator
-> compat set. The way to do a match is to first check the vendor
-> specific id, and then failing to match one, try the compat ids.

I imagine the same effect could be achieved by making the match routine
of any *PNP device return a value > X[*] if the ID does not start with "PNP".
While I don't know much about the autoconfig system, I'm also guessing it 
could be done at a level higher than the match routines of all the drivers,
like the PNP emueration routine, so each driver wouldn't have to be touched.

For example, my laptop has a CS4237B sound chip which reports CSC000 and
PNPB007 (WSS compatibility ID).  The WSS driver could match the PNPB007, 
while my custom CS423x driver could match CSC0000 and have the PNP enumerator
automatically bump its' priority.  Or, the PNP enumerator could first query
the non-compatibility ID and if that doesn't match query the compatibility
ID (or skip it if the non-compat one matched).  Same idea, bit different 
implementation.  Since we know any PNPxxxx ID is a compatibility one, this
is pretty easy to do.  

--rafal

[*] Since some drivers already use this method, we'd have to reserve some
    range of the "match levels" for internal use of the autoconfig goo, but
    I don't see this being a problem since there are probably only a finite
    number of drivers that would ever want to attach to the same piece of
    hardware.

----
Rafal Boni                                                  rafal@mediaone.net