From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.periphs.scsi
Subject: Re: CAM (was Re: Would there be any interest in splitting this group?)
Date: 5 Jan 93 21:03:16 GMT
 <38228@cbm
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

jag@zk3.dec.com writes:
>    There has to be a different set of criterion for systems, both in 
>hardware and software, if they wish to play in a multi-initiator
>environment.  It is my opinion that an off the shelf $15 adaptor card
>does not have a prayer of working in a multi-initiator environment.
>There is a *LOT* of work that has to go into the support of multi-initiator.
>One of the minimums is dealing with hard resets.  A system has to make the
>assumption that one of the other systems can have a problem and will have
>to make use of the big RED switch on the side of the bus.  In CAM there
>was the entire async-callback sequence that allowed the peripheral
>device drivers to be notified for things just like RESET.

	You're probably right on this.  However, I hope(d) to be able to
communicate with most existing Amiga SCSI controllers, though few of them
were designed to work in a multi-initiator environment.  As far as I know,
none of them use timeouts on SCSI commands (and most probably ignore hard
resets).

>    At the time of spec there was only one vendor that was using any
>of the target mode(s), and this was an *internal* effort.  Perhaps 
>the CAM working group can take some time during the work on the next 
>generation CAM spec to produce a TIB using the input from the companies
>that are attempting to implement these modes.  Your work in this 
>direction is a great base to start with.

	I'll do what I can to help it along.

>>	Excluding processor-mode, it has some flaws but most are merely
>>vagueness or lack of clarity (other than that address sizes should be OSD,
>>not fixed at 4 bytes).
>
>    The 32/64/128/... pointer size issue was one that was fixed very
>early on.  The primary members of the CAM committee were the DOS/adaptor
>vendors, and at the time 64 bits was not a reality.  Those of us who
>had 64's comming down the pike realized that we would have to deal 
>with it at a source level and plan on working on it within the next
>CAM spec.  There was the goal that the CCB would look the same across
>the OSD's.  Especially with U*nx running in the PC hardware space this
>was a goal worth keeping.

	I was under the impression that while it was supposed to be similar,
there were far too many OSD-issues for any driver to have any chance of
running under different OS.  In which case, strict binary-offset compatibility
is useless.  In my experience, drivers are so tied to the OS model (interrupt
handling, tasking issues, memory allocation, etc) that on anything written
for an OS there's no way it can be used without modification in another OS
even on the same hardware.  I suppose on PC's the BIOS is simplistic enough,
and drivers basically ignore any OS enough that it's possible (but of course
this can cripple the drivers, since they can't use any OS functionality).

	I had taken the spec to mean that an OS device driver or application
using CAM would work with any HBA/CAM driver for that OS.  I see no major
problems with defining a separate 64-bit "univos" OSD for 64-bit Unixes,
other than the fact that the spec says that the pointers are 4 bytes instead
of being OSD.  (In reality, a 32-bit Unix driver would merely require a 
recompile with 64-bit Unix CAM headers to work with 64-bit CAM "univos" OSD.)
 
>>	By your interpretation, if a request sense command comes in, and the
>>SIM has no internal sense stored for that initiator, it uses the request
>>sense CCB handed in with Enable LUN.  If, before the driver makes the
>>request sense CCB available again, another request sense (from any initiator)
>>comes in, the SIM will have to return BUSY.  While legal, I think it's best
>>to avoid returning busy to request sense where possible.  In fact, there's
>>no need for request sense at all here - it must be default (no error) data,
>>since there's no way to associate it with an I_T_x nexus, in which case the
>>SIM could handle it perfectly easily itself (it already has to store and
>>return sense data for initiators anyways).
>
>    This is possible, but I would like to keep the SIM out of the loop, WRT
>dealing with creating any CCB data, unless it has to.  I can see where
>the other initiator can re-issue the REQUEST SENSE on a busy condition
>with the knowledge that is the behavior.  On the flip side why is the
>other initiator sending a REQUEST SENSE CDB out of the blue anyway ?
>Any REQUEST SENSE CDBs should idealy be part of any HBA or CAM autosense
>functionality.

	It has to create request sense data already to handle requests for
disabled LUNs, request sense after sending an unimplemented command (i.e. no
match in the CCB list at all), etc.

	It's possible that a command failed, then the machine running as a
target was rebooted, and after it came back up the initiator gets around to
sending the request sense.  Ok, highly unlikely, but possible.  Also, some
silly application or device driver might do it, since it's harmless it
should work fine.

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.