>I believe there is a way to disable the ISA-compatible I/O port from
>the PCI probe so that there is no penalty in leaving the ISA port
>enabled in the BIOS.  Here's a code snippet from the Linux driver:

[snip]

Thank you for pointing that out; but, as it happens, I had that in an
editor buffer at the time  I sent the message.  I assumed   we didn't
need  explicit advice  to look at other souce.   

In fact, the linux driver is where I gleaned the idea of using the
BusLogic id string byte that identifies a parent bus type.  That fits
the  NetBSD model of separate bus-specific attach front-ends rather
well.   My apologies for not attributing that idea.

It does, of course, leave open the issue of whether it's
architecturally preferable for the NetBSD  Buslogic attach functions
to

	a)  autodisable the ISA ports on a PCI buslogic adaptor
            (when the ports were not disabled by  the user via the
	  SCSI BIOS) , making the releveant io ports available for
	   other, conflicting devices; or

	b) leave a PCI/EISAthe BusLogic  card which is
	    BIOS-configured to respond to ISA primary or secondary
	    addresses in that state, whilst _not_ configuring  the 
	    alreayd-configured PCI devices as an ISA device too.

(or both).

This could make a difference to, for instance, user-space direct
access to the relevant io ports. I concede that's a far-fechted
example.  It's not clear (to me) whether it's better for the kerrnel
to second-guess the user by disabling access to a PCI card via the
standard ISA ioports. 

It *is* clear that not booting, with a default/distribution config, in
the hardwre configuration *mandated* by NetBSD 1.2, is a palpable bug.

I took all the above as read, on the principle that Charles Hannum
(who seems to have touched the NetBSD buslogic drivers most) would
also take it as read.  As best I understand, that's the communication
protocol he prefers.   My apologies to anyone who needed to have that
pointed out explicitly.  It's always hard to please a wide-ranging audience.