>> For "indirect" busses (e.g. ISA, VME), you have different semantics...the 
>> bus has no mechanism for cards to say "I'm here", and no discrete 
>> "slots".  Thus, the driver is called to probe for the device.  This is 
>> why "indirect" busses don't support "cloning" (e.g. ed*).
>> 
>> The order of the "indirect" probes is dependent on the order in files.isa 
>> (or whatever), last I checked..

>Souldn't then the call to the drivers to do the probe obey the order of 
>the devices in the CONFIG file? It wouldn't be much of a change to the 
>actual config code, right? Actually, reading the files.isa and 
>reorganizing its contents according to the order of appearance in 
>the CONFIG file would do it, wouldn't it?

Sorta.  But, not completely.

The PCI and EISA busses are going to have to be probed first, so the
intelligent matching can find the cards on those busses.  After that,
the ISA bus will have to be probed the old fashion way for things that
aren't yet matched, and have addresses that haven't yet been claimed
by already matched devices.  (Correct me if any of this is inaccurate,
Jason.)

So, *within* the ISA bus, you might be able to enforce ordering in
some fashion.  But, you're still going to have PCI or EISA first, the
other second, and ISA last.  If all your cards are ISA, then the
ordering you predicted might actually happen.

-----------------------------------------------------------------------------
  Michael L. VanLoon                                 michaelv@HeadCandy.com
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...

   Roll your own Internet access -- Seattle People's Internet cooperative.
                  If you're in the Seattle area, ask me how.
-----------------------------------------------------------------------------