>
>> I looked at some of the specifications once; it didn't seem very
>> well-specified, i.e. many things didn't seem very clearly defined.  I
>> must admit that I didn't look _too_ carefully, though.
>
>My main impression of the spec was that it was *huge*, while at the
>same time being not very clearly written.   I was somewhat horrified
>when DEC decided to implement it.
>
>			       _MelloN_

I should probably clarify "what I've written" and "why I've written
it that way", before all of this speculation gets out of hand.

CAM in and of itself is not the greatest of specifications.  There
are many portions of it that are space or cpu inefficient for no
good reason or are otherwise poorly specified.  But, a few of the
things it achieves are very powerful:

1) type drivers (sd, st, cd, worm, etc) whether implemented inside
   the kernel or as a userland process have full control over the device
   (including tag type specifications), with as much error information as
   possible exported from the controller drivers.

2) Freezing a device's transaction queue when an error occurs.  This
   ensures that a type driver can take the proper action, "before it's
   too late".

3) The notion of priority scheduling of commands.  At a course level,
   this allows you to "slip in" error recovery commands without perterbing
   those you have already queued to the system but are held back from the
   device until the queue is released.

4) Async event notifications for events that even a "non-busy" device
   might want to know about, but wouldn't see otherwise since it doesn't
   have any outstanding commands.

I've taken these and other "good things" from the CAM spec and
implemented a SCSI (and eventually ATAPI) system.  My work is "CAM
like", but not "CAM compliant".  Where features I implemented
overlapped with the CAM spec, I used the spec's variable names and
terminology since in these cases, CAM is perfectly reasonable and
can serve as a reference for what I've done.  In other cases, I've
chosen to implement features differently or to provide extentions
in areas I found lacking.  Some of these differences are:

1) Round-robin per-priority level scheduling of both multiple type drivers
   accessing the same physical device, and individual commands that are queued
   to a device.  There are 2^32 priority levels possible.

2) Sane resource (i.e. CAM Control Block) management.  Type driver's ask to
   be scheduled to receive CCBs instead of "allocating as many as they think
   they need" as in the original spec.  There can never be more CCBs in 
   he system than the number of total transactions physically queuable.

3) A simple polling hook used only for dumps.

4) A software interrupt used to process completed commands.  This greatly
   reduces the amount of time a controller card's hardware interrupt (and
   that of any devices that shares this interrupt) is blocked.  It also
   gives controller drivesr a much needed tool to prevent re-entrancy,
   especially during error recovery.  In the past, a "completed"
   command would trigger a new command to be queued to the controller,
   but simple spl protection now prevents this.

5) Interrupt driven probing/configuration of devices allowing for increased
   parallelism and robustness during boot.  The system probes all busses
   in parallel and can use it's normal, timeout based, error recovery
   methods at all times.

So far, the basic transport layer, the aic7xxx device driver, and the 
disk, cdrom, and application pass through type drivers have been completed.
The goal is to complete support for all controllers and type drivers supported
by the old system, by year end and to pull it into FreeBSD-current at that
time.  The performance of the code so far, with no performance tuning to
date, already greatly outperforms the original system.  Although by no
means has all error recovery code been written, for the type drivers that
are supported, the new system is already much more robust.

Hopefully this will kill most of the idle speculation and CAM bashing.  8-)

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================