>  | I must not be fully understanding the order of parsing of a config file;
>  | if you put sd0 after sd*, won't the wildcard be picked first?
>
>`It depends'.

no.  sd0 is sd0 if you say sd0.  the sd* won't match the device that
you want at sd0.  if you remove the physical device that matches the
description of sd0, you get no sd0 and drives start numbering at sd1.

>When I was testing a new puc card in an i386 machine, I had the
>following config entries:
>	puc*    at pci? dev ? function ?
>		# [ ... ]
>	com*    at puc? port ?
>		# [ ... ]
>	com0    at isa? port 0x3f8 irq 4
>	com1    at isa? port 0x2f8 irq 3
>	com2    at isa? port 0x3e8 irq 5
>
>I still got com0 & com1 on the isa card, and com2..5 from the puc,
>even though the puc was probed before the isa cards.

there you have com0, com1, and com2 "wired down" to specific places.

>However, in my pc164 alpha, with a similar config, the puc got
>com0..3, the serial console ended up on com4 and com5 was the second
>on-board port.  I think I tried listing the puc entries after the
>isa entries but I can't recall the effect of that.

the pc164 is a little weird.  i used to be using just the onboard ide
controller in mine and one drive.  that probed as this:

	pciide0 at pci0 dev 11 function 0: CMD Technology PCI0646 (rev. 0x01)
	...
	wd0 at pciide0 channel 0 drive 0: <Maxtor 90680D4>

then i added a promise card with a big honkin' drive on it.  that
(initially) probed like this:

	pciide0 at pci0 dev 5 function 0: Promise Ultra66/ATA Bus Master...
	...
	wd0 at pciide0 channel 1 drive 0: <Maxtor 98196H8>

which *SUCKED* because that particular wd0 is not my boot drive.  so i
added this to my kernel config:

	pciide0 at pci? dev 11 function 0
	wd0 at pciide0 channel 0

and now the onboard ide controller attaches as pciide0 (even though
pciide1 is found first) and my boot drive attaches as wd0 (even though
the drive on pciide1 is found first).  this'll really start to be fun
if i add more drives to each controller, because i've only got wd0
wired down, so i could conceivably end up with a situation like this:

	pciide0 at pci0 dev 5 function 0: Promise Ultra66/ATA Bus Master...
	...
	wd1 at pciide1 channel 1 drive 0: <Maxtor 98196H8>
	wd2 at pciide1 channel 1 drive 0: <Maxtor 98196H8>
	...
	pciide0 at pci0 dev 11 function 0: CMD Technology PCI0646 (rev. 0x01)
	...
	wd0 at pciide0 channel 0 drive 0: <Maxtor 90680D4>
	wd3 at pciide0 channel 0 drive 0: <Maxtor 90680D4>

because all the other wd attachments are wildcarded.

in the GENERIC alpha config file (which, i presume, you started from),
the com attachments are like this:

	com*    at      isa? port 0x3f8 irq 4           # standard serial ports
	com*    at      isa? port 0x2f8 irq 3

and they probe (and attach) like this:

	sio0 at pci0 dev 8 function 0: Intel 82378ZB System I/O (SIO)...
	...
	isa0 at sio0
	...
	com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
	com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo

so if you add a puc card in a pci slot, it will get a dev number (note
that my oboard sio0 is at 8, my promise card is at 5, and my onboard
ide controller is at 11) lower than the dev number of the thing that
the isa bus is on.  therefore, the puc will probe before the isa bus,
and the com attachments, which are all wildcarded, will get attached
as they're found.  you can always hardwire the isa com ports...

wacky, eh?

>I need to look further into this particular behaviour (which is
>orthogonal to my proposal).

if there's anything else you need explained...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."