Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

I see Google didn't thread my first try properly, sorry.  Here I am
again with an edited subject line.

-----Forwarded Message-----

From: Pat LaVarre <p.lavarre@ieee.org>
To: stern@rowland.harvard.edu
Cc: mdharm-usb@one-eyed-alien.net, usb-storage@one-eyed-alien.net, linux-scsi@vger.kernel.org
Subject: Re: [usb-storage] Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?
Date: 10 Sep 2003 12:16:31 -0600


> What do the SCSI folk have to say about it?

Anyone?

> > for 2.6.0 ... drivers/scsi/sd.c ...
> > sd_read_cache_type ...
> > Get rid of (or #ifdef out) most ...
>
> Is there any feeling about how to handle these
> ongoing problems with the mode-sense cache
> page?

Yes, much.

Maybe more feeling if you remind/teach me what breaks if we don't fetch
page 8 re Cache.  First I imagine automounters mount read-only disks rw,
and then the write cache gets errors while flushing.  I wonder what else
breaks.  Maybe thruput varies for devices that do or do not bother to
claim they have write cache.

Maybe more feeling if you can say how in/accurate page 8 re Cache
commonly is.  For example, I know of no clear & broadly adopted standard
that requires a device to declare write-behind or background defect map
updates as a form of write cache.

> There doesn't seem to be any general solution
> that can work with all USB storage devices.

I understand you to be saying we can settle for an sd solution, we don't
mind if the sd heuristic we discover then doesn't apply to pdt x05
dvd/cd.

> some hang when asked to read just the page
> header.
> ...
> some hang when asked to read just part of the
> page;
> ...
> Some hang when asked to read the entire page;

Device folk ship bugs, aye, same as host folk.

Are not two of these three failures disproportionately common?

Me, I would expect asking anything but what Windows asks would fail most
often.  Is that not so?  Do we know what Windows asks?  Do we know
if/how Win ME/ 2K/ XP differ here?  Have we matched CBWCB and
dCBWDataTransferLength in every bit?

Pat LaVarre

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Alan Stern]

On Wed, 10 Sep 2003, Georgi Chorbadzhiyski wrote:

> Alan Stern wrote:
> > 
> > More problems with that stupid MODE-SENSE cache page!  There are so many 
> > USB storage devices that have problems with that -- I wonder if it's worth 
> > the effort to try to continue supporting it?

> > If you want a temporary fix for 2.6.0, you can do this:  Edit the 
> > routine sd_read_cache_type in the file drivers/scsi/sd.c (near line 1100).  
> > Get rid of (or #ifdef out) most of the function; just leave the last few 
> > lines where it does:
> > 
> > 		printk(KERN_ERR "%s: assuming drive cache: write through\n",
> > 		       diskname);
> > 		sdkp->WCE = 0;
> > 		sdkp->RCD = 0;
> > 
> > You might want to change the KERN_ERR to KERN_NOTICE.
> 
> Thanks a lot! That worked fine! Now the device is detected and working.

Is there any feeling about how to handle these ongoing problems with the 
mode-sense cache page?  There doesn't seem to be any general solution that 
can work with all USB storage devices.  Some hang when asked to read the 
entire page; some hang when asked to read just part of the page; some hang 
when asked to read just the page header.

What do the SCSI folk have to say about it?

Alan Stern

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Patrick Mansfield]

On Wed, Sep 10, 2003 at 12:23:43PM -0400, Alan Stern wrote:

> Is there any feeling about how to handle these ongoing problems with the 
> mode-sense cache page?  There doesn't seem to be any general solution that 
> can work with all USB storage devices.  Some hang when asked to read the 
> entire page; some hang when asked to read just part of the page; some hang 
> when asked to read just the page header.
> 
> What do the SCSI folk have to say about it?

There was at least this thread last April:

http://marc.theaimsgroup.com/?t=104839042700001&r=1&w=2

Matthew had a simple patch so that emulated hosts did not do any (sd.c)
mode-sense cache checks, James had a filter commands patch.

There were changes since then in how the MODE SENSE is handled (sd.c
only?).

In current 2.6 code, the scsi_host emulated flag does nothing, and can
be deleted.

I don't like per-host (or transport) flags or filters that cannot be
modified. They make some sense for hosts that process the scsi commands
(like a RAID card). 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.

IMO we ought to go with two new BFLAGS, one to block the MODE SENSE page 8
(for the cache), and one to block the MODE SENSE page 0x3f (to check the
write protect). 

A per host bflags could be added, and overwritten by per device (devinfo)
settings. I'd rather we black list the broken ones but that does not
appear to be practical. usb-storage could then set the per-host bflag to
include the two new flags.

We still end up sending some non-popular SCSI commands to all SCSI
devices.

Such flags would not stop sg from sending those commands, but that is
postive as well as negative in that you can override what the kernel is
doing via user space (sort of what Pat LaVarre experienced).

Also mentioned in the above thread:

The EVPD code has been removed, and is not an issue.

There is now code to set BLIST_INQUIRY_36 (we can still potentially hang
broken devices before it is set, but you should get a warning, and then
could modify devinfo on the boot/module command line or via proc devinfo).

-- Patrick Mansfield

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Alan Stern]

On Wed, 10 Sep 2003, Patrick Mansfield wrote:

> On Wed, Sep 10, 2003 at 12:23:43PM -0400, Alan Stern wrote:
> 
> > Is there any feeling about how to handle these ongoing problems with the 
> > mode-sense cache page?  There doesn't seem to be any general solution that 
> > can work with all USB storage devices.  Some hang when asked to read the 
> > entire page; some hang when asked to read just part of the page; some hang 
> > when asked to read just the page header.
> > 
> > What do the SCSI folk have to say about it?

> I don't like per-host (or transport) flags or filters that cannot be
> modified. They make some sense for hosts that process the scsi commands
> (like a RAID card). 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.
> 
> IMO we ought to go with two new BFLAGS, one to block the MODE SENSE page 8
> (for the cache), and one to block the MODE SENSE page 0x3f (to check the
> write protect). 
> 
> A per host bflags could be added, and overwritten by per device (devinfo)
> settings. I'd rather we black list the broken ones but that does not
> appear to be practical. usb-storage could then set the per-host bflag to
> include the two new flags.

What do people think of just having per-device flags that the host driver
could set during the slave_configure() callback?  The point of these flags
is not to prevent bad commands from being sent to the device --
user-generated commands sent via sg should always be allowed.  Rather, the
point is to prevent sd.c from generating these commands in the first
place.  (Apparently the commands don't present a problem for sr.c.)

So for example, usb-storage could set the BFLAG to block MODE-SENSE page 8
for any disk-type device.  This isn't a perfect solution; consider an
iSCSI-attached device that is actually a usb-storage disk on some server.  
Nevertheless, this might take care of the majority of the problems we see.  
(I haven't seen any MODE-SENSE page 0x3f problems, but others have.)

Alan Stern

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[James Bottomley]

On Thu, 2003-09-11 at 16:05, Alan Stern wrote:
> What do people think of just having per-device flags that the host driver
> could set during the slave_configure() callback?  The point of these flags
> is not to prevent bad commands from being sent to the device --
> user-generated commands sent via sg should always be allowed.  Rather, the
> point is to prevent sd.c from generating these commands in the first
> place.  (Apparently the commands don't present a problem for sr.c.)

I'm not in principle opposed to this.  That's essentially what Andries
did for the mode sense 6 vs 10 problem.

> So for example, usb-storage could set the BFLAG to block MODE-SENSE page 8
> for any disk-type device.  This isn't a perfect solution; consider an
> iSCSI-attached device that is actually a usb-storage disk on some server.  
> Nevertheless, this might take care of the majority of the problems we see.  
> (I haven't seen any MODE-SENSE page 0x3f problems, but others have.)

They can't be BLIST flags, they have to be flags in the struct
scsi_device, but they're easy to add as long as we get a definitive list
of what's necessary.

James

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Alan Stern]

On 11 Sep 2003, James Bottomley wrote:

> On Thu, 2003-09-11 at 16:05, Alan Stern wrote:
> > What do people think of just having per-device flags that the host driver
> > could set during the slave_configure() callback?  The point of these flags
> > is not to prevent bad commands from being sent to the device --
> > user-generated commands sent via sg should always be allowed.  Rather, the
> > point is to prevent sd.c from generating these commands in the first
> > place.  (Apparently the commands don't present a problem for sr.c.)
> 
> I'm not in principle opposed to this.  That's essentially what Andries
> did for the mode sense 6 vs 10 problem.
> 
> > So for example, usb-storage could set the BFLAG to block MODE-SENSE page 8
> > for any disk-type device.  This isn't a perfect solution; consider an
> > iSCSI-attached device that is actually a usb-storage disk on some server.  
> > Nevertheless, this might take care of the majority of the problems we see.  
> > (I haven't seen any MODE-SENSE page 0x3f problems, but others have.)
> 
> They can't be BLIST flags, they have to be flags in the struct
> scsi_device, but they're easy to add as long as we get a definitive list
> of what's necessary.

James and Matt:

Please tell us what you think of the two patches below.  The first patch 
introduces 2 bitflags: one causes sd.c to skip the mode-sense request for 
page 0x08 and the other causes it to skip the request for page(s) 0x3f.

The other patch makes usb-storage set the page-8 flag for disk-type
devices.  I didn't set the page-3f flag because I haven't noticed that
causing much problems.  If Matt wants to add it that will be easy to do;
if we end up not needing it then it will be easy to remove it from the
first patch.

Alan Stern


PATCH: (as95)
===== include/scsi/scsi_device.h 1.5 vs edited =====
--- 1.5/include/scsi/scsi_device.h	Fri Sep  5 07:48:41 2003
+++ edited/include/scsi/scsi_device.h	Fri Sep 12 16:17:08 2003
@@ -85,6 +85,8 @@
 				     * because we did a bus reset. */
 	unsigned use_10_for_rw:1; /* first try 10-byte read / write */
 	unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
+	unsigned skip_ms_page_8:1;	/* do not MODE-SENSE for page 0x08 */
+	unsigned skip_ms_page_3f:1;	/* do not MODE-SENSE for page 0x3f */
 	unsigned no_start_on_add:1;	/* do not issue start on add */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */
===== sd.c 1.56 vs edited =====
--- 1.56/drivers/scsi/sd.c	Fri Sep  5 12:16:39 2003
+++ edited/drivers/scsi/sd.c	Fri Sep 12 16:21:28 2003
@@ -1059,6 +1059,15 @@
 	struct scsi_mode_data data;
 
 	/*
+	 * Don't try to issue mode sense for page 0x3F if the device
+	 * won't like it.
+	 */
+	if (sdkp->device->skip_ms_page_3f) {
+		printk(KERN_NOTICE "%s: assuming Write Enabled\n", diskname);
+		return;
+	}
+
+	/*
 	 * First attempt: ask for all pages (0x3F), but only 4 bytes.
 	 * We have to start carefully: some devices hang if we ask
 	 * for more than is available.
@@ -1104,6 +1113,18 @@
 	const int modepage = 0x08; /* current values, cache page */
 	struct scsi_mode_data data;
 
+
+	/*
+	 * Don't try to issue mode sense for page 0x08 if the device
+	 * won't like it.
+	 */
+	if (sdkp->device->skip_ms_page_8) {
+		printk(KERN_NOTICE "%s: assuming drive cache: write through\n",
+		       diskname);
+		sdkp->WCE = 0;
+		sdkp->RCD = 0;
+		return;
+	}
 
 	/* cautiously ask */
 	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);


PATCH: (as96)
===== drivers/usb/storage/scsiglue.c 1.59 vs edited =====
--- 1.59/drivers/usb/storage/scsiglue.c	Mon Jul 28 14:29:04 2003
+++ edited/drivers/usb/storage/scsiglue.c	Fri Sep 12 16:55:26 2003
@@ -68,6 +68,12 @@
 	sdev->use_10_for_ms = 1;
 	sdev->use_10_for_rw = 1;
 
+	/* For disk-type devices, skip the mode-sense query for page 8
+	 * (the caching page).  Lots of USB Mass Storage devices crash
+	 * no matter how carefully we ask. */
+	if (sdev->type == TYPE_DISK)
+		sdev->skip_ms_page_8 = 1;
+
 	/* this is to satisify the compiler, tho I don't think the 
 	 * return code is ever checked anywhere. */
 	return 0;

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

> From: Matthew Dharm <mdharm-scsi () one-eyed-alien ! net>
>
> I think allowing write to read-only media is
> the only way to go.  I don't see another way
> to get write-protect status.

Does write-protect work for dvd-ram?

How?

> From: 	Alan Stern <stern@rowland.harvard.edu>
> ...
> (Apparently the commands don't present a
> problem for sr.c.)

sr.c shows this problem by getting the wrong answer.

sr.c is getting cd->device->writeable wrong for all the seven-or-so mmc
writable profiles except dvd-ram.

Some background from me and patches from Andy Polyakov and Jens Axboe
appear in:
Subject: Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6
http://marc.theaimsgroup.com/?t=106123318400007

> From: Matthew Dharm <mdharm-scsi () one-eyed-alien ! net>
> ... I'm going to have some code that will not
> apply the filters (any filters) if the request
> comes from sg,

More old good sense!

Following are relevant posts from me that some archives before now have
not included in this thread.

Pat LaVarre

---

Subject: Re: PATCH: exclude certain commands from emulated SCSI hosts 
Date: 2003-04-23 14:45:31 PST 
From: Pat LaVarre (ppaatt@aol.com)

> http://groups.google.com/groups?group=mlist.linux.scsi
> Subject: Re: PATCH: exclude certain commands from emulated SCSI hosts 
>
> > From: Patrick Mansfield (patmans@us.ibm.com)
> > Date: 2003-04-07 15:42:13 PST 
> >
> > Would a user ever want to send a MODE SENSE
> > to USB storage device?)
>
> From: Matthew Dharm (mdharm-scsi@one-eyed-alien.net)
> Date: 2003-04-21 17:04:05 PST  
>
> a very large number of USB devices of TYPE DISK do
> not  support MODE SENSE in any form.  Apparently,
> the 'popular' OSes don't use it.

I have some reason to believe Windows often passes thru something like:
-x "1A 00 08 00 18 00" -i x18
i.e. a ModeSense6 of Cacheing page x08 for the whole 4 byte header plus
one whole 8 byte block descriptor plus the whole xC byte standard page.

But I haven't studied this closely enough to know if that's precisely
correct, nor do I know when it gets translated to op x5A ModeSense10,
nor do I know when it is faked out in the host entirely, never reaching
the bus.

> From: Alan Stern (stern@rowland.harvard.edu)
> Date: 2003-04-22 11:21:36 PST ...
>
> a comment in drivers/storage/usb/protocol.c
> indicating that 8 is the minimum size for a
> MODE-SENSE (line 257).

Perhaps we mean:
http://lxr.linux.no/source/drivers/usb/storage/protocol.c?v=2.5.56#L274
/* again, for MODE_SENSE_10, we get the minimum (8) */

I don't know of any merely public standard that admits 8 (i.e. the whole
standard header) is a minimum.

I do know Win 2K kernel dies if a root-privileged app is so rude as to
express an x5A ModeSense10 ModeSense for less than 8 as op x1A
ModeSense6:
http://support.microsoft.com/?kbid=813908
SCSI Pass-Through Mode Sense Command May Crash the Computer

> > From: Matthew Dharm (mdharm-scsi@one-eyed-alien.net)
> > Date: 2003-04-05 11:40:24 PST 
> >
> > (1) can't filter TEST UNIT READY (opcode 0).
> > Not a big deal, but a theoretical problem.
> >
> From: James Bottomley (James.Bottomley@steeleye.com)
> Date: 2003-04-05 12:00:18 PST 
>
> TUR has been mandatory since SCSI-1, ...

A zeroed six byte CDB has been mandatory.  Other forms of TUR are less
widely supported.
...

-----Forwarded Message-----

From: 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: [usb-storage] Re: [linux-usb-devel] [2.6-test] Bug in
usb-storage or scsi?
Date: 11 Sep 2003 14:04:54 -0600

> http://marc.theaimsgroup.com/?t=104839042700001&r=1&w=2

Thanks, there I find 44 posts dated since 2003-03 with Subject's like:
"PATCH: exclude certain commands from emulated SCSI hosts".

By the way, Google yields [an interestingly] different set of 44 posts:
http://groups.google.com/groups?threadm=linux.scsi.20030322193705.C17056%40one-eyed-alien.net

In both archives I think I see much sense:

> > From: Matthew Dharm <mdharm-usb () one-eyed-alien ! net> ...
> >
> > (a) don't ask for EVPD data, ...
> > (b) assume ... only 36-bytes of INQUIRY data, ...
> > (c) ... assume write-enabled for all disk-like media.
>
> From: Linus Torvalds <torvalds () transmeta ! com>
>
> suggest ... make the Linux SCSI layer
> ... use the sequences of commands that "that other OS" uses ...
> "don't use commands that haven't gotten much testing" ...
...

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Alan Stern]

On 11 Sep 2003, Pat LaVarre wrote:

> > From: 	Alan Stern <stern@rowland.harvard.edu>
> > ...
> > (Apparently the commands don't present a
> > problem for sr.c.)
> 
> sr.c shows this problem by getting the wrong answer.
> 
> sr.c is getting cd->device->writeable wrong for all the seven-or-so mmc
> writable profiles except dvd-ram.

Getting a wrong answer isn't quite as bad as crashing the peripheral's 
firmware.  My proposed solution is meant to attack the problems of USB 
mass storage devices that crash when asked to report MODE-SENSE page 8, 
possible also when asked for page 0x3f.

Alan Stern

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

> From: Alan Stern <stern@rowland.harvard.edu>
>
> the MODE SENSE page 0x3f (to check the write
> protect) ... (I haven't seen ... problems,
> but others have.)

I imagine page x3F is an sd issue only?

I remember Ansi says the mode sense header reports writability only for
pdt x00 hdd.

I remember pdt x05 dvd/cd devices misbehaving when their available x3f
AllPages data exceeded the xFF bytes that x1A MODE_SENSE can copy,
though x5A MODE_SENSE_10 worked fine.

And I often repeat, I remember clearly that the popular OS doesn't often
ask only for a four-byte x1A MODE_SENSE header, because I saw that
actually doing that crashes Win 2K kernels up thru SP3, if Windows has
concluded the device needs the host to translate to x5A MODE_SENSE_10.

Pat LaVarre

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

> 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

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Patrick Mansfield]

On Fri, Sep 12, 2003 at 12:43:14PM -0600, Pat LaVarre wrote:
> 
> > 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?

The mode sense 6 vs 10 that James mentioned, search the code for
use_10_for_ms, used in scsi_lib.c, set to 0 in scsi_scan.c and set to 1 by
drivers/usb/storage/scsiglue.c.

> > 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?

More specifically, if you are using some LLDD or transport X as a bridge
to another transport Y, we might set flags - maybe what commands we can
send - relative to transport X, when they might be inappropriate for
transport Y.

Examples:

If USB (usb-storage) bridged to a remote device that is actually connected
via SPI, today we will try and send 10 byte MODE SENSE commands to the
device.

If iSCSI bridged to a remote USB device, we will only send 6 byte MODE
SENSE commands.

There are also devices that work with FCP or SPI, but those generally
don't have borken devices like the USB storage ones.

> 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?

I don't get your point - I was talking about the transport (LLDD), not the
actual scsi device or upper level drivers.

Code used for different upper level scsi devices should not be duplicated,
I don't know ide or cd enough to comment in that area, except that there
is common cd code (struct cdrom_device_ops).

sr could probably do some of the same things as sd to figure out if a
device is writable, but we are best maintaining current algorithms (don't
have sr send new mode sense commands) to avoid borken devices.

-- Patrick Mansfield

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

> I don't get your point ...
> 
> Code used for different upper level scsi
> devices should not be duplicated, ...

Re whether a pdt x05 dvd/cd device is writable, I think I see
duplication among ide-cd, ide-scsi, and sr.  I hear ide-scsi is dying,
but that ide-cd and sr plan to continue competing.

For example:

sr.c get_capabilities decides CDC_DVD_RAM and cd->device->writeable by
fetching & parsing as raw hex the 2Ah Capabilities mode page via
scsi_lib.c scsi_mode_sense of page x2a, sending op MODE_SENSE = x1a or
MODE_SENSE_10 = x5a.

ide-cd.c ide_cdrom_probe_capabilities decides CDC_DVD_RAM (also stored
as CDROM_CONFIG_FLAGS(drive)->dvd_ram) by fetching & parsing as a
asm/byteorder.h packed struct the 2Ah Capabilities mode page via
ide_cdrom_get_capabilities via cdrom_mode_sense of page
GPMODE_CAPABILITIES_PAGE = x2a, always sending op GPCMD_MODE_SENSE_10 =
x5a.

Neither yet proceeds to try op 46h GET_CONFIGURATION to discover the
other six writable mmc profiles.

> talking about the transport (LLDD),
> not the actual scsi device or upper level drivers ...

Thank you for your patience, sorry at first I did not understand how
narrowly we mean "transport" here.

> use_10_for_ms ...
> set to 0 in scsi_scan.c ...
> set to 1 by drivers/usb/storage/scsiglue.c ...
>
> transport X as a bridge to another transport Y,
> flags ... maybe what commands we can send ...
> relative to transport X,
> when they might be inappropriate for transport Y ...
> Examples ...

Clear to me now (and cool) thank you.

> I don't know ide or cd enough ...
> except ...there is common cd code (struct cdrom_device_ops).

Aye, helpful.

Pat LaVarre