On Fri, 9 Feb 1996 13:29:07 +0100 (MET) 
 Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de> wrote:

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

Yah ... What I ended up having to do to manage the ISA io/mem space 
sanely was implement a new "extent manager", which I'm finishing up now.  
rmap wasn't flexible enough, and if I added the flexibility, it became a 
memory pig.

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

If you could mail me *all* of the details, I'd be happy to at least look 
at it. :-)

 > 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...

Umm ... You're right ... I misread config_scan().  Ok .. a small change 
to each of the config_*() functions that search cfdata[] ... how's that?  
:-)  This includes config_scan() and config_search(), and 
config_rootsearch(), too, actually.  The change to these functions will 
be *really* trivial.

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

Yah .. I'm not convinced that we're really in any condition to deal with 
most forms of loadable drivers at the moment.  This example is a shining one.

 > It would be nice if the different improvements could be coordinated.

Yup.  SPEAK UP, FOLKS!  :-)

 > I'll look at your changes next week. I hope I can apply them,
 > my devolopment tree is basically release 1.1.

You should be able to...They're pretty simple/straightforward.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939