All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Andre Hedrick <andre@linux-ide.org>
Cc: Jens Axboe <axboe@suse.de>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SAM-3 status codes
Date: Mon, 27 Jan 2003 21:36:12 +1100	[thread overview]
Message-ID: <3E350B9C.4020203@torque.net> (raw)
In-Reply-To: Pine.LNX.4.10.10301230007110.20139-100000@master.linux-ide.org

Andre Hedrick wrote:
> Jens,
> 
> One of the problems is chasing down all the  variations of SAM and pre
> SAM.  I do not know, and maybe Doug can help, but did bit0 become
> obsoleted in the age of SASI's transformation to SCSI ?

In SCSI-2 bits 0, 6 and 7 of the status byte were
reserved for the _implementation_. Not sure if any SCSI
devices every used them because that would make this
code:
    if (status == SCSI_CHECK_CONDITION) ....
problematic. [It should be:
    if (status & SCSI_CHECK_CONDITION)  ...
which also correctly picks up COMMAND_TERMINATED but you
don't see code like that very often.]
BTW There is a '#define SCSI_MASK 0x3e' in
the scsi.h header allowing:
    if ((status & SCSI_MASK) == SCSI_CHECK_CONDITION)  ...

In SCSI 3 (or later) bits 0 and 7 are reserved (period) and
bit 6 is in use. The masking that was (strictly speaking) required
in SCSI-2 seems to be no longer required.

> I can not find anything about it, and my knowledge in the history of SCSI
> is vastly weaker then ATA during the X3 split.
> 
> The naming issue is what stopped me in the process of working on a
> bus-phase rewrite to convert scsi to a logical state machine.  Dealing
> with all the issues related to the HBA's was more than any mad man could
> attempt, much less a sane one.
> 
> Comments on fixing 2.5 to use proper status values?

Well, the only problem is that CHECK_CONDITION in
/usr/src/linux/include/scsi/scsi.h is visible to
the user space (and is replicated in RH8.0's
/usr/include/scsi/scsi.h by the glibc people).
It would be surprising if Joerg Schilling (cdrecord)
used it but I should check SANE and a few other long
term sg users. scsiinfo + sg(3)_utils don't use it.

If we don't cause user space pain and we can change
the kernel code that uses CHECK_CONDITION (and friends)
then we could make the change in lk 2.5 . Some names
are still not ideal (e.g. "GOOD") so prefixing them
with SCSI_ or SAM_ still might be useful.
That is replace:
   #define GOOD                 0x00
   #define CHECK_CONDITION      0x01
   #define CONDITION_GOOD       0x02
   #define BUSY                 0x04
   #define INTERMEDIATE_GOOD    0x08
   #define INTERMEDIATE_C_GOOD  0x0a
   #define RESERVATION_CONFLICT 0x0c
   #define COMMAND_TERMINATED   0x11
   #define QUEUE_FULL           0x14

   #define STATUS_MASK          0x3e

with:

   #define SAM_GOOD            0x00
   #define SAM_CHECK_CONDITION 0x02
   #define SAM_CONDITION_MET   0x04
   #define SAM_BUSY            0x08
   #define SAM_IMMEDIATE       0x10
   #define SAM_IMMEDIATE_CONDITION_MET 0x14
   #define SAM_RESERVATION_CONFLICT 0x18
   #define SAM_COMMAND_TERMINATED 0x22       /* obsolete in SAM-3 */
   #define SAM_TASK_SET_FULL   0x28
   #define SAM_ACA_ACTIVE      0x30
   #define SAM_TASK_ABORTED    0x40

   #define SCSI2_MASK          0x3e
   #define SAM3_MASK           0x7e


Doug Gilbert

> 
> Cheers,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 
> On Thu, 23 Jan 2003, Jens Axboe wrote:
> 
> 
>>On Thu, Jan 23 2003, Douglas Gilbert wrote:
>>
>>>The perverse CHECK_CONDITION in include/scsi/scsi.h seems
>>>to have struck again (see "Can't burn DVD under 2.5.59 with
>>>ide-cd" thread on the linux kernel list). Most users of
>>>CHECK_CONDITION found out to their surprise that it is
>>>shifted 1 bit (right) from those values found in the
>>>standards.
>>>
>>>The attachment marks the orginal list of SCSI status codes
>>>as deprecated and supplies defines taken from the most
>>>recent SAM-3 draft.
>>>
>>>The patch is against 2.5.59 but may also be suitable for
>>>the lk 2.4 tree.
>>
>>Thanks Doug, the old defines were really sick, dunno who was smoking
>>what. I not so sure I like the naming, though. The old ones still have
>>the most obvious naming :(
>>
>>-- 
>>Jens Axboe


      reply	other threads:[~2003-01-27 10:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-22 23:10 [PATCH] SAM-3 status codes Douglas Gilbert
2003-01-23  2:30 ` Andre Hedrick
2003-01-23  7:48 ` Jens Axboe
2003-01-23  8:24   ` Andre Hedrick
2003-01-27 10:36     ` Douglas Gilbert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E350B9C.4020203@torque.net \
    --to=dougg@torque.net \
    --cc=andre@linux-ide.org \
    --cc=axboe@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.