[PATCH] Hidden scsi devices

[PATCH] Hidden scsi devices

[Brian King]

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

Here is a patch that adds a flag to struct scsi_device which prevents
upper layer drivers from binding to it. This flag can be set by LLDs
in their slave_configure routine. I plan to use this in the ipr driver
so I can have scsi disks that are in RAID arrays show up in sysfs and
have sg devices created for them, but prevent sd devices from being
created since these devices will fail reads and writes with data protect
errors. I tested this out with the ipr driver it worked as expected.



-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

[-- Attachment #2: patch-2.6.1-hidden_devs --]
[-- Type: text/plain, Size: 1147 bytes --]

diff -Naur linux-2.6.1/drivers/scsi/scsi_sysfs.c linux-2.6.1-hidden/drivers/scsi/scsi_sysfs.c
--- linux-2.6.1/drivers/scsi/scsi_sysfs.c	Fri Jan  9 00:59:10 2004
+++ linux-2.6.1-hidden/drivers/scsi/scsi_sysfs.c	Thu Jan 22 08:54:39 2004
@@ -149,7 +149,13 @@
 /* all probing is done in the individual ->probe routines */
 static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
 {
-	return 1;
+	struct scsi_device *sdev;
+	sdev = to_scsi_device(dev);
+
+	if (sdev->hidden)
+		return 0;
+	else
+		return 1;
 }
 
 struct bus_type scsi_bus_type = {
diff -Naur linux-2.6.1/include/scsi/scsi_device.h linux-2.6.1-hidden/include/scsi/scsi_device.h
--- linux-2.6.1/include/scsi/scsi_device.h	Fri Jan  9 00:59:06 2004
+++ linux-2.6.1-hidden/include/scsi/scsi_device.h	Thu Jan 22 08:50:33 2004
@@ -94,6 +94,7 @@
 	unsigned skip_ms_page_8:1;	/* do not use MODE SENSE page 0x08 */
 	unsigned skip_ms_page_3f:1;	/* do not use MODE SENSE page 0x3f */
 	unsigned no_start_on_add:1;	/* do not issue start on add */
+	unsigned hidden:1;	/* do not bind to upper level driver */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */
 

Re: [PATCH] Hidden scsi devices

[Christoph Hellwig]

Ok.  Although I'd maybe write it a bit more compact, and a bit commentary
could't hurt.

/*
 * Sort out hidden devices early.  All real probing is done in the
 * individual ->probe routines
 */
static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
{
	struct scsi_device *sdev = to_scsi_device(dev);

	return (sdev->hidden ? 0 : 1);
}

Re: [PATCH] Hidden scsi devices

[Martin Peschke3]

Brian,

why should a LLDD need to bother about device characteristics?
I tend to say that it is completely up to upper layer drivers to
handle such device specialties.
How does a LLDD know about that r/w protection feature anyway?

Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349


Brian King <brking@us.ibm.com>@vger.kernel.org on 22/01/2004 16:21:23

Sent by:    linux-scsi-owner@vger.kernel.org


To:    linux-scsi@vger.kernel.org
cc:
Subject:    [PATCH] Hidden scsi devices


Here is a patch that adds a flag to struct scsi_device which prevents
upper layer drivers from binding to it. This flag can be set by LLDs
in their slave_configure routine. I plan to use this in the ipr driver
so I can have scsi disks that are in RAID arrays show up in sysfs and
have sg devices created for them, but prevent sd devices from being
created since these devices will fail reads and writes with data protect
errors. I tested this out with the ipr driver it worked as expected.



--
Brian King
eServer Storage I/O
IBM Linux Technology Center
diff -Naur linux-2.6.1/drivers/scsi/scsi_sysfs.c
linux-2.6.1-hidden/drivers/scsi/scsi_sysfs.c
--- linux-2.6.1/drivers/scsi/scsi_sysfs.c        Fri Jan  9 00:59:10 2004
+++ linux-2.6.1-hidden/drivers/scsi/scsi_sysfs.c             Thu Jan 22
08:54:39 2004
@@ -149,7 +149,13 @@
 /* all probing is done in the individual ->probe routines */
 static int scsi_bus_match(struct device *dev, struct device_driver
*gendrv)
 {
-            return 1;
+            struct scsi_device *sdev;
+            sdev = to_scsi_device(dev);
+
+            if (sdev->hidden)
+                        return 0;
+            else
+                        return 1;
 }

 struct bus_type scsi_bus_type = {
diff -Naur linux-2.6.1/include/scsi/scsi_device.h
linux-2.6.1-hidden/include/scsi/scsi_device.h
--- linux-2.6.1/include/scsi/scsi_device.h             Fri Jan  9 00:59:06
2004
+++ linux-2.6.1-hidden/include/scsi/scsi_device.h            Thu Jan 22
08:50:33 2004
@@ -94,6 +94,7 @@
             unsigned skip_ms_page_8:1;          /* do not use MODE SENSE
page 0x08 */
             unsigned skip_ms_page_3f:1;         /* do not use MODE SENSE
page 0x3f */
             unsigned no_start_on_add:1;         /* do not issue start on
add */
+            unsigned hidden:1;            /* do not bind to upper level
driver */

             unsigned int device_blocked;        /* Device returned
QUEUE_FULL. */





-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Hidden scsi devices

[Brian King]

Martin Peschke3 wrote:
> Brian,
> 
> why should a LLDD need to bother about device characteristics?
> I tend to say that it is completely up to upper layer drivers to
> handle such device specialties.
> How does a LLDD know about that r/w protection feature anyway?

Because the device is reported to the LLDD by the adapter as a
specific device type. The adapter creates a configuration table
describing all attached devices that the LLDD must retrieve. In this
configuration table there are several types of devices:

1. Adapter itself.
2. Generic SCSI devices.
3. Logical disk array devices (VSET)
4. Advanced function devices (devices in RAID arrays).

In my situation the only one who knows about this device characteristic
is the LLDD.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

Re: [PATCH] Hidden scsi devices

[James Bottomley]

On Thu, 2004-01-22 at 12:07, Brian King wrote:
> Because the device is reported to the LLDD by the adapter as a
> specific device type. The adapter creates a configuration table
> describing all attached devices that the LLDD must retrieve. In this
> configuration table there are several types of devices:

If you can't ever get access to these devices and you only want sg
access for SCSI command ioctls, you could just alter the device type to
something like PROCESSOR (or even an unclassified type) which will solve
the error messages from sd problem.

The true solution to this issue looks to be more flexibility in the
binding process.  We did discuss this previously, certainly in a SAN
environment there are reasons for only actually binding (and allocating
resources to) devices you're interested in.

James

Re: [PATCH] Hidden scsi devices

[Brian King]

James Bottomley wrote:
> On Thu, 2004-01-22 at 12:07, Brian King wrote:
> 
>>Because the device is reported to the LLDD by the adapter as a
>>specific device type. The adapter creates a configuration table
>>describing all attached devices that the LLDD must retrieve. In this
>>configuration table there are several types of devices:
> 
> 
> If you can't ever get access to these devices and you only want sg
> access for SCSI command ioctls, you could just alter the device type to
> something like PROCESSOR (or even an unclassified type) which will solve
> the error messages from sd problem.

I agree that this is a solution as well (requires more code), but
then sysfs will show the device as a different device type, which
I would think might be confusing.

> The true solution to this issue looks to be more flexibility in the
> binding process.  We did discuss this previously, certainly in a SAN
> environment there are reasons for only actually binding (and allocating
> resources to) devices you're interested in.

Who generally has this knowledge in your example? The LLDD? Would a
LLDD host template function that gets called for each disk be more
palatable?


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

Re: [PATCH] Hidden scsi devices

[James Bottomley]

On Thu, 2004-01-22 at 12:33, Brian King wrote:
> I agree that this is a solution as well (requires more code), but
> then sysfs will show the device as a different device type, which
> I would think might be confusing.

Isn't there a volume manager type ... don't have access to the standards
at the moment, but I vaguely remember this.  That is essentially what
you're doing isn't it? discs that are part of an array?

> > The true solution to this issue looks to be more flexibility in the
> > binding process.  We did discuss this previously, certainly in a SAN
> > environment there are reasons for only actually binding (and allocating
> > resources to) devices you're interested in.
> 
> Who generally has this knowledge in your example? The LLDD? Would a
> LLDD host template function that gets called for each disk be more
> palatable?

This is definitely a TBD in the future item.  The idea is that some user
process does the binding, and would have a list of devices to identify
and ignore (or to identify and bind ignoring everything else).

It would benefit us if we begin to trigger hotplug events on FC storage
discovery.  Without zoning, we'd get may FC events that we simply
weren't interested in.  We could simply log the ID in a database, and if
the user says "I want that storage" then bring it in and bind it.  You
would be able to use the same mechanism in ipr to say "don't bind
here"..

James

Re: [PATCH] Hidden scsi devices

[Mike Anderson]

James Bottomley [James.Bottomley@steeleye.com] wrote:
> On Thu, 2004-01-22 at 12:33, Brian King wrote:
> > I agree that this is a solution as well (requires more code), but
> > then sysfs will show the device as a different device type, which
> > I would think might be confusing.
> 
> Isn't there a volume manager type ... don't have access to the standards
> at the moment, but I vaguely remember this.  That is essentially what
> you're doing isn't it? discs that are part of an array?

I see a 0C "Storage array controller device", but no volume type in spc3.
> 
> > > The true solution to this issue looks to be more flexibility in the
> > > binding process.  We did discuss this previously, certainly in a SAN
> > > environment there are reasons for only actually binding (and allocating
> > > resources to) devices you're interested in.
> > 
> > Who generally has this knowledge in your example? The LLDD? Would a
> > LLDD host template function that gets called for each disk be more
> > palatable?
> 
> This is definitely a TBD in the future item.  The idea is that some user
> process does the binding, and would have a list of devices to identify
> and ignore (or to identify and bind ignoring everything else).
> 

I do not believe Patrick posted it, but he had a prototype of this
working using current infrastructure, a new sysfs attribute called
rebind(??), and some mucking with the device type. In the TBD future
this could be much cleaner.

> It would benefit us if we begin to trigger hotplug events on FC storage
> discovery.  Without zoning, we'd get may FC events that we simply

Since we a talking port ids these events would be less than all the
hotplug events that are triggered during discovery of the luns off these
port ids.

> weren't interested in.  We could simply log the ID in a database, and if
> the user says "I want that storage" then bring it in and bind it.  You
> would be able to use the same mechanism in ipr to say "don't bind
> here"..

With Greg's export of the hotplug call LLDDs could make these calls
today.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] Hidden scsi devices

[Mike Anderson]

James Bottomley [James.Bottomley@steeleye.com] wrote:
> On Thu, 2004-01-22 at 12:33, Brian King wrote:
> > I agree that this is a solution as well (requires more code), but
> > then sysfs will show the device as a different device type, which
> > I would think might be confusing.
> 
> Isn't there a volume manager type ... don't have access to the standards
> at the moment, but I vaguely remember this.  That is essentially what
> you're doing isn't it? discs that are part of an array?
> 

Trying to understand the scope of support for the LLDD. While just
changing the device_type would be a small change, intercepting future
inquiry commands to ensure all future device_types returned this new
value would be larger. 

Is your comment to change the device type to stop binding also include
this intercept capability.

It would seem that if in the future we would want some user space binding
control that adding this LLDD device_type modification would be more
code to clean out vs just not setting a no bind bit anymore.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] Hidden scsi devices

[James Bottomley]

On Thu, 2004-01-22 at 14:43, Mike Anderson wrote:
> Trying to understand the scope of support for the LLDD. While just
> changing the device_type would be a small change, intercepting future
> inquiry commands to ensure all future device_types returned this new
> value would be larger. 
> 
> Is your comment to change the device type to stop binding also include
> this intercept capability.

No, this was just thinking about a short term fix in the driver (without
having to propagate it through the mid layer).  Lying to the mid layer
always ends up being more trouble than it's worth.

> It would seem that if in the future we would want some user space binding
> control that adding this LLDD device_type modification would be more
> code to clean out vs just not setting a no bind bit anymore.

Yes, I think this is the correct future direction as well.

James

Re: [PATCH] Hidden scsi devices

[Brian King]

James Bottomley wrote:
> On Thu, 2004-01-22 at 14:43, Mike Anderson wrote:
> 
>>Trying to understand the scope of support for the LLDD. While just
>>changing the device_type would be a small change, intercepting future
>>inquiry commands to ensure all future device_types returned this new
>>value would be larger. 
>>
>>Is your comment to change the device type to stop binding also include
>>this intercept capability.
> 
> 
> No, this was just thinking about a short term fix in the driver (without
> having to propagate it through the mid layer).  Lying to the mid layer
> always ends up being more trouble than it's worth.
> 
> 
>>It would seem that if in the future we would want some user space binding
>>control that adding this LLDD device_type modification would be more
>>code to clean out vs just not setting a no bind bit anymore.
> 
> 
> Yes, I think this is the correct future direction as well.

Ok. Scratch this patch and I will override the SCSI device type in
the scsi_device struct in my slave_configure routine to 0x0C.
Actual inquiry commands to the device will return type 0x00 - disk.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center