public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	USB Developers <linux-usb-devel@lists.sourceforge.net>,
	USB Storage List <usb-storage@one-eyed-alien.net>,
	Linux SCSI list <linux-scsi@vger.kernel.org>
Subject: Re: [usb-storage] Re: PATCH: exclude certain commands from emulated SCSI hosts
Date: Mon, 24 Mar 2003 11:05:25 +1000	[thread overview]
Message-ID: <3E7E59D5.2020200@torque.net> (raw)
In-Reply-To: 20030323101314.E17056@one-eyed-alien.net

Matthew Dharm wrote:
> On Sat, Mar 22, 2003 at 11:39:05PM -0800, Linus Torvalds wrote:
> 
>>How about making the SCSI stuff pass a "common" flag (or "required") down
>>with the command? Then, a emulated thing could just decide to punt all 
>>commands with an immediate failure if they aren't marked "required".
>>
>>That still _allows_ the driver to implement it if it wants to, unlike your 
>>previous approach.
> 
> 
> That seems reasonable... but we need to define a standard way to
> reject/fail non-common commands.  Special sense data?  Special result
> code?  It doesn't really matter to me, but we need to pick something.
> 
> Do you have a preference?

Matt,
Evidentally your driver (and/or sbp2) synthesizes INQUIRY
responses in some cases. So if you think a SCSI command
is risky then why not follow the standard and synthesize
the scsi status and auto-sense buffer. Here is a modern
rendition from a (draft) standard:

"If a device server receives a CDB containing an operation
code that is invalid or not supported, it shall return
CHECK CONDITION status with the sense key set to ILLEGAL
REQUEST and an additional sense code of INVALID COMMAND
OPERATION CODE." [SPC-3, T10/1416-D Revision 10 2002/11/10]

If it is a field within a command that is in doubt (e.g.
the enable Vital Product Data (EVPD) bit in an INQUIRY)
then the additional sense code becomes INVALID FIELD IN
CDB.

In the case of a disk the commands that must be
supported are:
    - 36 byte INQUIRY (EVPD=0, CmdDt=0)
    - READ CAPACITY
    - READ (10 byte)
    - WRITE (10 byte)

For SCSI mid level scan code and the sd
disk initialization code a flag could be added to
struct scsi_cmnd to indicate that "I can live without
knowing the answer to this command".

I always wanted the emulated flag generalized (e.g.
indicating SPI, ATAPI, iSCSI, FC, SAS, SBP-2,
USB_mass_storage). Knowledge of the SCSI transport
protocol is important for device discovery,
identification and asynchronous notification sources.
As a boolean flag, "emulated" has outlived its usefulness.
With sysfs we can now find which hardware system a
SCSI low level driver belongs  to (e.g. SCSI Parallel
Interface (SPI) adapters are either PCI or ISA).

Doug Gilbert





  reply	other threads:[~2003-03-24  1:05 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030322193046.A17056@one-eyed-alien.net>
     [not found] ` <20030322193149.B17056@one-eyed-alien.net>
2003-03-23  3:37   ` PATCH: exclude certain commands from emulated SCSI hosts Matthew Dharm
2003-03-23  4:09     ` Linus Torvalds
2003-03-23  7:31       ` Matthew Dharm
2003-03-23  7:39         ` Linus Torvalds
2003-03-23 18:13           ` [usb-storage] " Matthew Dharm
2003-03-24  1:05             ` Douglas Gilbert [this message]
2003-03-24  1:26         ` James Bottomley
2003-03-24  1:37           ` Matthew Dharm
2003-03-24  1:39             ` James Bottomley
2003-03-24  7:04               ` Matthew Dharm
2003-03-24 15:15                 ` James Bottomley
2003-03-24 16:29                   ` Linus Torvalds
2003-03-24 16:43                     ` James Bottomley
2003-03-24 16:52                     ` Jens Axboe
2003-03-24 16:56                       ` James Bottomley
2003-03-24 17:30                   ` Matthew Dharm
2003-04-05 15:30                     ` James Bottomley
2003-04-05 19:27                       ` Matthew Dharm
2003-04-05 19:45                         ` James Bottomley
2003-04-05 19:55                           ` Matthew Dharm
2003-04-05 20:08                             ` James Bottomley
2003-04-06  0:20                               ` Matthew Dharm
2003-04-06  0:22                           ` Matthew Dharm
2003-04-06 15:39                             ` James Bottomley
2003-04-07 22:33                       ` Patrick Mansfield
2003-04-07 23:14                         ` James Bottomley
2003-04-08  0:51                           ` Patrick Mansfield
2003-04-20 21:33                       ` Matthew Dharm
2003-04-20 21:35                         ` Matthew Dharm
2003-04-21 16:20                           ` James Bottomley
2003-04-21 17:02                             ` Matthew Dharm
2003-04-21 16:28                         ` James Bottomley
2003-04-21 17:01                           ` Matthew Dharm
2003-04-21 19:23                             ` James Bottomley
2003-04-21 19:35                               ` Matthew Dharm
2003-04-21 21:27                                 ` James Bottomley
2003-04-21 23:37                                   ` Matthew Dharm
2003-04-21 21:28                                 ` Patrick Mansfield
2003-04-21 23:45                                   ` Matthew Dharm
2003-03-24  1:58             ` Linus Torvalds
2003-03-24  6:58               ` Matthew Dharm
2003-03-24 18:17 [usb-storage] " Pat LaVarre
2003-03-24 18:19 ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2003-03-24 19:16 Pat LaVarre
2003-03-24 20:20 ` Matthew Dharm
2003-04-08 13:29 Pat LaVarre
2003-04-09  7:45 ` Douglas Gilbert
2003-04-09 15:08 Pat LaVarre
2003-04-09 15:15 Pat LaVarre
2003-04-22  1:09 Andries.Brouwer
2003-04-22  1:17 ` Matthew Dharm
2003-04-22 14:31   ` Alan Cox
2003-04-22 15:36     ` Matthew Dharm
2003-04-22 16:07     ` James Bottomley
2003-04-22 17:08 Andries.Brouwer
2003-04-22 17:22 Andries.Brouwer
2003-04-22 17:34 ` Mike Bursell
2003-04-22 17:37 ` James Bottomley
2003-04-22 18:50 ` Matthew Dharm
2003-04-22 17:38 Andries.Brouwer
2003-04-22 18:23 ` Alan Stern
2003-04-22 18:44 Andries.Brouwer

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=3E7E59D5.2020200@torque.net \
    --to=dougg@torque.net \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mdharm-scsi@one-eyed-alien.net \
    --cc=torvalds@transmeta.com \
    --cc=usb-storage@one-eyed-alien.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox