public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Pat LaVarre <p.lavarre@ieee.org>
To: patmans@us.ibm.com
Cc: stern@rowland.harvard.edu, mdharm-usb@one-eyed-alien.net,
	usb-storage@one-eyed-alien.net, linux-scsi@vger.kernel.org
Subject: Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?
Date: 12 Sep 2003 12:43:14 -0600	[thread overview]
Message-ID: <1063392194.3677.7.camel@patehci2> (raw)
In-Reply-To: <20030910170227.C3367@beaverton.ibm.com>


> From: Patrick Mansfield <patmans@us.ibm.com>
> ...
> last April: ... changes since then
> in how the MODE SENSE is handled (sd.c only?)

Anybody know more?

> If you moved a device from one transport to
> another, the commands sent to the device
> should not change: for example, you move an
> iSCSI attached device onto your local system
> via SPI.

Eh?

I thought in linux we have competing cdb authors on purpose.  For
example, how sr decides if a device is writable differs from how ide-cd
decides if a device is writable.  I thought that the powers that be like
linux that way.

No?

Having multiple cdb authors necessarily means that the cdb's passed thru
one kind of transport or another do differ any time the multiple
versions of copy-edited authoring code differ.

In particular, people designing an unusual device to work with linux
have to repeat their work: once for sr, again for ide-cd, and so on.

No?

Pat LaVarre




  parent reply	other threads:[~2003-09-12 18:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F5E434D.6080801@unixsol.org>
2003-09-10 16:23 ` [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi? Alan Stern
2003-09-10 18:16   ` [usb-storage] " Pat LaVarre
2003-09-10 18:49     ` sg MiB writes scheduling while atomic Pat LaVarre
2003-09-10 19:30       ` Pat LaVarre
2003-09-16  6:35         ` Douglas Gilbert
2003-09-16 11:42           ` Matthew Wilcox
2003-09-16 12:58             ` Christoph Hellwig
2003-10-14 23:36             ` Pat LaVarre
2003-09-10 20:08       ` [PATCH] mount -w of dvd+rw etc. in vanilla 2.6 Pat LaVarre
2003-09-10 22:49         ` Patrick Mansfield
2003-09-22 14:52       ` max GiB written per boot Pat LaVarre
2003-09-10 20:51     ` unsolicited sense in 2.6.0-test5 usb-storage.ko Pat LaVarre
2003-09-10 21:03       ` [usb-storage] " Alan Stern
2003-09-10 21:24         ` Pat LaVarre
2003-09-10 21:52           ` Matthew Dharm
2003-09-10 22:08             ` Pat LaVarre
2003-09-12  0:21               ` Pat LaVarre
2003-09-12  0:29                 ` Pat LaVarre
2003-09-16 11:28             ` Douglas Gilbert
2003-09-11  0:02   ` [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi? Patrick Mansfield
2003-09-11 20:04     ` [usb-storage] " Pat LaVarre
2003-09-11 20:05     ` Alan Stern
2003-09-11 20:19       ` James Bottomley
2003-09-12 21:17         ` Alan Stern
2003-09-11 20:42       ` Pat LaVarre
2003-09-12 19:59         ` Alan Stern
2003-09-12 19:18       ` Pat LaVarre
2003-09-12 18:43     ` Pat LaVarre [this message]
2003-09-12 20:56       ` Patrick Mansfield
2003-09-12 21:53         ` Pat LaVarre
2003-09-10 21:07 Pat LaVarre

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=1063392194.3677.7.camel@patehci2 \
    --to=p.lavarre@ieee.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=patmans@us.ibm.com \
    --cc=stern@rowland.harvard.edu \
    --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