[ so, this isn't isn't coherent. 8-]

> I guess that I'm alarmed that at this point bits turn off disc/rec
> are still needed. I found them useful, but *rarely* necessary
> in 1988 (helloooo! It's 1996....). Disconnect/reconnect should really
> not be a problem any more. If they are because of a few devices, a
> reasonable approach is to be unfriendly to these devices: run, w DISC/REC
> enabled, but if the devices boob things, let a command timeout blow the
> xfer away (noisily) and then restart the command (possibly with
> disco/reco disabled automatically)- this might give market
> encouragement to moving onto reasonable devices.

And NetBSD is in the position to make a difference in what SCSI device
manufacturers do?  "Uh, no."


At least in terms of the NetBSD SCSI drivers' capabilities, well, i
think it's unfair to compare a vendors' SCSI drivers to those in
NetBSD...  Vendors not only tend to be better-connected (for stuff
like documentation), but are well paid to make their drivers be rock
solid.

That's not meant to be an excuse, but rather an explanation...


> Sigh... This stuff is *still* not worked out. Time for fibre channel.....

Unfortunately, that won't help too much, at least for a while...

Even if FC drives and boards are perfect (working with a group that
has a lot of contacts with people who're making these things, i can
safely say "even if," at least for now 8-), then there's still the
driver problem.  Knowing the complexity of the systems that many
vendors are building to support fibre channel (e.g. Symbios's planned
I2O-compliant boards), there's going to be a lot of debugging and
testing and coding on all sides before they're up for production use.


There are drivers and (large) sets of code in our source tree which
are functional -- i.e. the basic functionality is there -- but nothing
more.  They're not actually _usable_ in real environments yet, because
they're missing so much support code (or so much testing &
bulletproofing).  That's not such much a "bug" as a problem inherent
to the environment in which the NetBSD Project operates...




chris