From: jag@decvax.DEC.COM (John A. Gallant UEG)
Subject: Re: Would there be any interest in splitting this group?
Reply-To: jag@zk3.dec.com
Organization: OSF Engineering, Digital Equipment Corp.
Date: Mon, 14 Dec 1992 19:21:13 GMT

In article <37702@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
>jag@zk3.dec.com writes:
>>In article <37468@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:

>	Huh?  I thought it had the CCB (and therefore the CDB)?  Admittedly,
>it may not _understand_ what's in the CDB, so that may not matter...  It
>also knows the direction of transfer.

    The SIM can't use any of the CDB information, in reality it has to 
act as if there is no CDB.  All the informaion that the SIM has to go
on is contained in the CCB fields, the data info and flags are there
to be used.

>>   Any type of data overrun or underrun is a *non-normal* happening. 
>[ data-in-underrun is "not bad", data-in-overrun generates error,
>  data-out-underrun is "not bad", data-out-overrun requires hard Reset(!!!!) ]
>
>	While your reasoning seems valid, can you tell me where it says this
>in the spec?  If it doesn't, should it?  ...............................

    It is not in the spec.   When we were discussing it in the committee
it was like "self evident".  

>......................................?  I can conceive of arguments for
>a number of different interpretations of how over/underrun should be
>handled.  If I were implementing it from the spec, I probably would have
>created an implementation that disagreed with yours.  I think this point
>needs clarification.  Also, a hard bus reset seems IMMENSELY drastic!
>What if some other device was writing to a tape from a buffer when it saw
>reset?  Etc, etc.  I agree writing non-provided data has it's problems too,
>but I think hard reset is worse!  The peripheral driver submitted the request.
>Either it didn't provide enough data (bug in driver), or the device is
>requesting more data than the command specified (can this ever happen due to
>noise/reflections?)

    In any event an this occurring in DATA OUT is an error, either a bug
in the driver or a bug in the device/Hardware.  Digital as a company
has this "thing" about data corruption.  We figured that it was "better"
to risk loosing Tape position, rather than writting 0's over some Banks
accounting data base.  At least I would be perturbed if my checking accout
balance suddenly went from "near zero" to zero :-).

>	Can't you assert ATN, transfer 0's until you get a message out,
>then send ABORT, ABORT_TAG, or TERMINATE_IO_PROCESS?  That at least seems
>possible...

    We to this for DATA IN at least.  I was kind of in favor of sending 
out on the bus, "Dump sh*t".  This way the user could "see" what ended
up on the disk, (but I was out voted in one of our design reviews :-).

>>>	The spec says they must be validated when registered.  It doesn't
>>>say what to do with commands not on the list.  I suspect they should be 
>>>rejected in Processor mode.
>>
>>    I think that the spec indicates, check condition with Illegal command.

    The check condition was for CDBs that came in over the SCSI bus, sorry.

>	"Any invalid CCB in the list shall be rejected and the LUN shall
>not be enabled."  It never defines invalid - it implies above that other
>checks are done as well.  It says that supported commands include Inquiry,
>Receive, Send, and Request Sense - it doesn't say that all others are
>invalid.  ................................................................

    These were choose for being the most useful.  There should be no
reason why any other CDB can not be added to the list on the Enable LUN.
The list of "things" to check in the CAM spec is really there to show 
you what level of checking the SIM should perform.

>........  This may seem to be semantic quibbling, but I've had other people
>tell me they implemented other commands for processor mode, and I was unsure
>enough I wanted to ask.  Also, it says the invalid ones will be rejected.
>What about valid CCB's in the same Enable LUN request?  Are they rejected?
>Are they merely ignored and the Enable LUN rejected?  If the invalid ones are
>rejected, and the Enable LUN is rejected, and valid ones are not, is there
>a guarantee that the invalid ones will be rejected before the Enable LUN is
>rejected?  This is way too fuzzy.

    The enable lun CCB is rejected or accepted as a whole, this includes
the CCBs that are attached to it, an all or none situation.  If any of
the CCBs are rejected then the enable lun is failed, along with the CCBs.
It is up to the peripheral driver to make sure that the enable lun command
succeeds before it can "use" the CCBs.

>>    The processor mode was originaly set to be a "canned" mode.  The
>>send/receive pair were sufficient for communication between the two
>>systems.  The other commands are really needed to allow the "other 
>>systems SCSI software to do the normal thing like bus probes and misc
>>administriva.
>
>	Yes.  So why aren't they supported?  Processor mode allow many
>more commands than just those 4 (and I still don't see how request sense
>CCB's work in processor mode).

    The request sense CCB is like an appendix, it does not make a whole
lot of sense but it has to be there in the event the the "other" system
should issue a request sense CDB.  At least it can be a was to get general
status information.

>>   The phase cognizant mode will really allow you to get down and dirty.
>>And any kind of commands can be emulated.  The phase cognizant mode was 
>>actually written by an engineer who was using it to control a SCSI
>>target.  The processor mode model was sort of created by an engineer who
>>did not like the phase cognizant mode :-).
>
>	Sort of like the choice between fast food and having to grow your
>own vegetables and raise your own cows to make hamburger... :-)

    As an OS level person, I tend to "shudder" when I think of trying to
run phase cognizant mode on one of our disk servers.

>	How many people have actually implemented this stuff?  I know
>vail@tegra (or whatever) has.  I think processor mode (and maybe phase-
>cognizant, I haven't really looked at it closely) needs to be better
>documented in the spec to avoid wildly varying (and incompatible)
>implementations.

    We will have it as part of our SCSI/NSF failover project, and we
are using processor mode.  It would be very useful to have an additional
implementation "note" or something.  There are a number of holes that
need to be filled.

-- 
John A. Gallant                                jag@zk3.dec.com
Software Engineer - OSF Engineering Group
Digital Equipment Corp. (603) 881-2472

        In the common people there is no wisdom, no penetration, no
        power of judgment.
    Marcus Cicero
Newsgroups: comp.periphs.scsi