Re: [example PATCH - not for applying] exclude certain commands

[James Bottomley <James.Bottomley@steeleye.com>]

On Thu, 2003-04-24 at 15:14, Matthew Dharm wrote:
> Well, at this point, I guess I should just be happy that something is being
> done.  But, what I'm really afraid of, this coming right back to this
> point.
> 
> In the past, I modified the write-protect probing in 2.4.x to be more compatible
> with what usb-storage wanted.  But then someone changed it, and it broke.
> So we changed it again... and it was fine for a while.  Then someone
> changed it in 2.5.x, and it broke again.
> 
> I guess what's got me frustrated is that this is very fragile, tends to
> cause serious problems when it fails, often gets changed, and isn't really
> necessary -- after all, that's why the 'assume write-enabled' code path is
> there for when the request fails.
> 
> I've just been around and around this merry-go-round, and I'm trying to get
> off.  We can fix it now, but I am truly afraid that it's going to get
> broken again in 6 months.

To some extent, I'm afraid you can't get off:  you're stuck on here with
the rest of us.

I can't guarantee that changes to the SCSI subsystem won't break USB
devices.  However, what I can guarantee is that we'll work to fix the
problems as they arise.

> And, as for the need for filtering, I know we have such a need.  I have
> several devices on my desk which choke at INQUIRY EVPD -- so right now I
> filter it in the usb-storage driver.  I also have devices that report bogus
> INQUIRY data lengths, but (luckily) the sanity checks in the INQUIRY
> probing code generally catch those cases and save us.

I think the evpd code can be thrown out into user land (where the rules
governing how it's used can be much more flexible).  All we really use
it for is to get a unique name.  However, even WWN inquiries don't
always guarantee even that...

> I've seen devices that choke on START_STOP, unless that START_STOP is an
> eject command.  I fixed this by eliminating the only non-eject use of
> START_STOP in sd.c -- but how long is it before someone decides they need
> to use START_STOP for something?

sd.c uses START_STOP to spin up an inactive disc (but only if we get a
check condition/NOT READY). sr_ioctl.c uses it to eject or close a cd
tray.

> We may have fixed MODE_SENSE, but what about the other cases?

I think we just have to identify them and tackle them in the same way.

Do you have any other current bug reports you'd like to share with us?

James