[ On Wed, December 9, 1998 at 23:54:51 (-0800), Ross Harvey wrote: ]
> Subject: Re: aix7xxx problems with negotiating "Ultra" speeds....
>
> "*must*"?!  Why do you say that?  Standards that don't make it need not be
> adopted. Sometimes it can be quite harmful to follow a dead standard.
> 
> The ANSI CAM spec has been [1] around for a long time, and [2] kind of a
> dud, adopted by only a couple of system vendors.

1. Lots of standards are "dead" but still provide useful guidelines to
   solving real-world problems.

2. What do we care about what other vendors implement?  ;-)

Gary Field's "SCSI - A Game With Many Rules and no Rulebook?"  seems to
give a slightly different story about CAM, though I don't pretend to
understand all the politics involved between the vendors and ANSI, etc.
<URL:http://www.ultranet.com/~gfield/gary/scsigame.txt>

In any case, CAM is a *software* layer that, so far as I understand,
affects operating systems, not external device support, so except for
the implications of interfacing with modern host adapters that lean one
way or another in providing a software interface, it really shouldn't
matter to NetBSD what other OS vendors do.  However we've already seen
that there are possible advantages to adopting the FreeBSD CAM
implementation which are separate from the advantages of implementing
CAM without using the FreeBSD code.

Not to mention, but the ANSI X3T10 group continues to push forward with
CAM-3, so there must be some future in it.

> Be careful about those authoritive-sounding pronouncements. :-)

OK, then if not CAM then something like CAM *must* be implemented
eventually.  I think the explanations in Justin's paper are more than
sufficient (<URL:http://www.freebsd.org/~gibbs/>) to explain why just
"some improvements" are not sufficient to fix the problems in a full
blown implementation of SCSI.  Maybe CAM isn't the ideal solution, but
it is documented (as a standard <URL:http://www.symbios.com/x3t10/>) and
I think the FreeBSD implementation shows that it is a workable solution
and that it does solve some very apparent problems that are not solved
by the current NetBSD SCSI framework.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>