Re: PATCH: exclude certain commands from emulated SCSI hosts

[Matthew Dharm <mdharm-scsi@one-eyed-alien.net>]

[-- Attachment #1: Type: text/plain, Size: 3678 bytes --]

On Mon, Apr 21, 2003 at 02:28:05PM -0700, Patrick Mansfield wrote:
> Matthew -
> 
> On Mon, Apr 21, 2003 at 12:35:41PM -0700, Matthew Dharm wrote:
> 
> > Then can we have it the way I proposed?   I have tested patches that use
> > this code as I proposed it waiting to be merged as soon as this is
> > accepted.
> 
> I think it is OK, but as argued before: I was hoping to see attributes and
> code that can be used for all scsi_devices off a particular adapter/LLDD,
> or a specific scsi_device. Then we would not need separate attributes (or
> filters) for adapters/LLDD and for the scsi_devices (the current BFLAGS
> like code accessed via the scsi_dev_info_list; though being able to filter
> any command is certainly more powerful).

I think this is a nice idea, but you're talking about filtering at an
entirely different level from what I'm talking about.  I'm filtering at the
LLDD level, you want to filter in the mid-layer before the command gets out
the door to the LLDD.

> It would be very usefull to allow modification or addition of the filter
> via user land (or at boot/insmod time), eventually via sysfs.  Embedding
> the filter call in the queuecommand prevents such additions for arbitrary
> adapters (i.e. if the adapter does not call the filter, we can't add any
> filtering).

I can see how this would all be useful.  This, of course, assumes that you
can enumerate the device successfully (thus creating a device node) before
needing to tweak the flags, which is exactly NOT the case I'm dealing with.

I won't argue that such an implementation wouldn't be useful.  But it's a
_much_ bigger project than we're talking about here.  And, frankly, I think
it's a project for another day.

> And we would be better off avoiding only the cache page (mode sense page
> 0x8) without blocking all mode sense commands (I assume that is what
> you'll do when using the filter) - so we don't block other pages that
> might be used (via sg), and we don't block the mode sense commands used to
> used to figure out if the device is read only (sd.c sd_read_write_protect_flag,
> though I don't understand WTF the second page code 0 is supposed to
> return).

Actually, my plan is to block all MODE_SENSE for TYPE_DISK devices.  I'm
going to have some code that will not apply the filters (any filters) if
the request comes from sg, but that's down the line.  It turns out that 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.

> > You may recall that my first approach was to set the BLIST flag for 36-byte
> > INQUIRY -- Linus shot that down in favor of a command-filter approach.
> 
> I thought his main objection was using the per-adapter emulated bit to
> determine how to handle all scsi_devices on the adapter.

Yes, which led to a discussion of where and how the filtering should take
place, which led to SCSI core code for filtering which would be applied by
whoever/whatever wanted to.

I agree that some sort of super-flexible multi-layered filtering system
would be great.  It might even use some of the same filter calls that we're
talking about here -- but that's a project for another day.  For now, let's
solve the the problem which has been with us since 2.3.x and get a filter
framework that usb-storage can use into place.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It's not that hard.  No matter what the problem is, tell the customer 
to reinstall Windows.
					-- Nurse
User Friendly, 3/22/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]