Why not CAM?

Why not CAM?

[Christer Weinigel]

Hi,

I've wanted to ask this for a long time: Why not switch to SCSI CAM
when you are redoing the Linux SCSI layer anyways? 

This is not intended to start a flamewar of any kind, I don't know
very much about CAM except that it is some kind of standard and
FreeBSD uses it and they seem to be mostly happy with it.  So I'm just
curious if any of the SCSI hackers think that CAM would be worthwhile
and if not, why?  Too heavyweight?  Too ugly?  Won't fit well with the
new BIO design in the 2.5 kernel?

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: Why not CAM?

[Matthew Jacob]

> Hi,
> 
> I've wanted to ask this for a long time: Why not switch to SCSI CAM
> when you are redoing the Linux SCSI layer anyways? 
> 
> This is not intended to start a flamewar of any kind, I don't know
> very much about CAM except that it is some kind of standard and
> FreeBSD uses it and they seem to be mostly happy with it.  So I'm just
> curious if any of the SCSI hackers think that CAM would be worthwhile
> and if not, why?  Too heavyweight?  Too ugly?  Won't fit well with the
> new BIO design in the 2.5 kernel?

CAM (Common Access Method) is an ANSI standard. I fought against it
bitterly back in the last '80s, but in retrospect, it's a fine if
slightly somewhat overcomplicated model.

There are two extant widespread implementations: FreeBSD and Tru64
(formerly known as Digital Unix).

It has a lot to recommend it, but its success of failure in Linux would
probably be due to whomever has the time (and/or employer's backing) to
do a fairly complete implementation and present it for review.

Like a lot of standards, the devil is in the details.

-matt