> Ahh...  OK.  I think I see.  It provides the interface to the scsi bus
> for things like CD-ROM drivers or easier addition of things like custom
> drivers or OCR engines or some such?  That is, it's an interface to
> drivers for drivers?

Yes, it's an interface "to drivers, for drivers."

> There is no standard w/in Unix for accessing scsi devices.  I have
> noticed that at least one or two vendors are starting to use CAM or
> something similar (OSF/1 on the DEC Alpha appears to use CAM),

yes, as did ULTRIX...  of course, that's DEC's CAM, which i _think_
(but i'm not sure) is slightly tweaked...

Worth noting that DEC's CAM spec is published, and that they've got
smart devices (e.g. the KZTSA and KZPSA) that implement it mostly on
the adapter...  Not really sure how it all works, as i've not looked
into it, but that's what i understand, from having worked with KZTSAs
and from hunting through their docs.

> but
> the usual case is that the SCSI system is accessed directly through
> specific drivers.

right.  user-programs wouldn't often use CAM, but i believe there are
CAM ioctls exported to user-land, for the cases where they do need them.

> [ ... ]
>
> CAM might be a win if it could be implemented efficiently w/o breaking
> anything.  When I looked at the spec once, it seemed pretty large,
> though, and implementing it looked like a job for a CAM expert.

I, too, have always held the impression that CAM is a relatively thick
set of software.  However, i'm not really sure how true that is,
especially if you can push most of it into smart adapters.

It may be reasonably "necessary" to implement a CAM interface
eventually, especially once SCSI-3 gets really nailed down.  However,
having looked at the volume of SCSI-3 "standards and related stuff"
that's in the works, i can honestly say that _i_ don't want to be the
one to implement it all...  8-)



later,

chris