Excerpts from netbsd: 8-Feb-96 PMS driver and ISA Jason
Thorpe@nas.nasa.go (10722)

> The idea is to create an ISA iospace/iomem resource map so that once a 
> device is probed and attached, other devices won't be subsequently probed 
> at an overlapping iospace/iomem location. 

Wonderful - this is what I was waiting for. Hope it will be generic enough
to be used for other address maps too - I'm concerned about hardware
with some live insertion capabilities (not PCMCIA).
If you touch the ISA code anyway, you should think of the "plug and play"
cards which can probably not be ignored in the future (at least, if you have
to share the machine with M$ victims). I recently got the PnP 3c509 working,
but the binding to the existing if_ep driver is somwhow unsatisfying.
The ISA PnP spec allows for up to 4 memory windows, 8 io ranges, 2
interrupts and 2 dma channels per logical device. The ressource
allocation is managed by the BIOS - very PCI-like. (I'm quite familar
with it - ask if you need more details.)
The isa_attach_args should reflect this or, at least, allow for a pointer
to the PnP specific data.
Once cgd's EISA code is brought in, some code portions can be shared
because the vendor and device IDs are similar.

[order of device probes]
> The second stage of this will be a small, non-obtrusive change to 
> config_search(), which is the MI autoconfig routine that returns 
> "matching information" to pass onto the probe routines. Basically, the 
> change is to add a field to the cfdriver structure, cd_priority, which 
> will tell config_search() how important it is that this device be probed 
> before somethine else.

You are confusing me a bit. Al least in the -current sources, ISA uses
config_scan(). Seems that you describe the _basic_ idea only - there
must be more...
Anyway, I'd suggest thinking about loadable driver issues before
doing these changes. It seems that not all cases can be handled -
if a device whose driver is not present gets messed up in the first
autoconf run, the loaded driver has no chance...
On the other hand, loadable driver support probably requires some more
additions to struct cfdriver. (And, imo, in the config_search and
related functions.)
It would be nice if the different improvements could be coordinated.

[changes to pms driver]
> If someone with a pms mouse could apply these 
> diffs to their -current tree and tell me if it works, I'd really 

I recently tried the pms driver on a P120/SiS. Its probe fails if
dynamically loaded. I didn't get X11 up even with the driver
statically configured.
I'll look at your changes next week. I hope I can apply them,
my devolopment tree is basically release 1.1.

best regards
Matthias Drochner