Re: devices with more than one node

Re: devices with more than one node

[Patrick Mansfield]

On Tue, Jan 13, 2004 at 01:20:58PM -0800, Greg KH wrote:
> On Tue, Jan 13, 2004 at 10:11:22PM +0100, Olaf Hering wrote:
> >  On Tue, Jan 13, Greg KH wrote:
> > > On Tue, Jan 13, 2004 at 08:38:42PM +0100, Olaf Hering wrote:
> > > > inputdevices have also an event node attached.
> > > 
> > > Yes, and you get two different hotplug events, and udev just works,
> > > right?  (this is with the kernel patches I sent out last week...)
> > 
> > I tried the -mm tree, and /proc/bus/input/devices differs indeed. Havent
> > tried to feed udev with the data.
> 
> Look at /sys/class/input in the -mm kernel.  I didn't do anything with
> the /proc/bus/input stuff.
> 
> > > > Maybe I miss the obvious, but how do I match scsi as example? Not that
> > > > sg provides a sg 'dev' entry today, but an external PROGRAM could not
> > > > provide an relative symlink to sgN.
> > > 
> > > scsi needs to create a scsi_generic class (or some such name) and have
> > > it contain the sg information.  It should not be in the cdev directory
> > > like it currently is (that's badly broken and should have never made it
> > > in...)  That sg class can contain the symlink back to the device that it
> > > is associated with.
> > > 
> > > Does this help?
> > 
> > Yes. Do you have a patch for that? Or should the scsi people do it?
> 
> The scsi people should do it :)
> 
> But if pushed hard enough, I guess I could do it...
> I do need to make cdev disappear from the sysfs tree entirely anyway...
> 
> If only I had more time.  Anyone else want to do this?
> 
> thanks,
> 
> greg k-h

Don't forget to let the scsi people know ;-) cc-ing linux-scsi

st also needs changes.

Did anyone figure out how udev should handle the one tape device requiring
multiple minors (for open/close with/without rewind)? It really is a
single device requiring multiple dev entries.

For scsi_id support with udev, st needs to support SG_IO, AFAIUI it can
use similiar code as found in sd.c and sr.c.

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: devices with more than one node

[Greg KH]

On Tue, Jan 13, 2004 at 03:01:47PM -0800, Patrick Mansfield wrote:
> Don't forget to let the scsi people know ;-) cc-ing linux-scsi

Ok, here goes:

linux-scsi, DO NOT USE THE cdev sysfs directory.  It will be going away
as soon as I get around to writing the patch for it.  Putting the sg
symlink in there is not the proper place.

For scsi generic you should create a scsi generic class (scsi_generic?)
and create the individual sg devices in that directory (feel free to use
the simple_class.c code that is currently in the -mm tree if you want,
it makes it much simpler)

> st also needs changes.

I agree.

> Did anyone figure out how udev should handle the one tape device requiring
> multiple minors (for open/close with/without rewind)? It really is a
> single device requiring multiple dev entries.

Create multiple class_device items for every tape device and have the
device symlink point to the same scsi device.  The simple_class code
should make life a lot easier for you.

> For scsi_id support with udev, st needs to support SG_IO, AFAIUI it can
> use similiar code as found in sd.c and sr.c.

That's a scsi core issue, not a udev issue :)

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: devices with more than one node

[dougg]

Quoting Greg KH <greg@kroah.com>:

> On Tue, Jan 13, 2004 at 03:01:47PM -0800, Patrick Mansfield wrote:
> > Don't forget to let the scsi people know ;-) cc-ing linux-scsi
> 
> Ok, here goes:
> 
> linux-scsi, DO NOT USE THE cdev sysfs directory.  It will be going away
> as soon as I get around to writing the patch for it.  Putting the sg
> symlink in there is not the proper place.

Greg,
Is the register_chrdev_region() call which according to
J. Corbet's documentation allows support for more than 256 
devices, going away? Or is it simply going to lose its
sysfs visibility (in the /sys/cdev/major directory)?
 
> For scsi generic you should create a scsi generic class (scsi_generic?)
> and create the individual sg devices in that directory (feel free to use
> the simple_class.c code that is currently in the -mm tree if you want,
> it makes it much simpler)

Does any device use the simple_class.c code yet?
 
> > st also needs changes.

and osst.

Kai changed the st naming scheme in /sys/cdev/major/st*
in a way that seems to allow for more than 8 variants
of each device.
 
> I agree.
> 
> > Did anyone figure out how udev should handle the one tape device requiring
> > multiple minors (for open/close with/without rewind)? It really is a
> > single device requiring multiple dev entries.
> 
> Create multiple class_device items for every tape device and have the
> device symlink point to the same scsi device.  The simple_class code
> should make life a lot easier for you.
> 
> > For scsi_id support with udev, st needs to support SG_IO, AFAIUI it can
> > use similiar code as found in sd.c and sr.c.
> 
> That's a scsi core issue, not a udev issue :)

Well, before cdev gets ripped out, following two symlinks
(i.e. tape -> device -> generic) solves the long standing
ULD to sg (and vice versa) mapping problem.

It shouldn't be too hard putting (another) implementation
of the SG_IO in scsi/scsi_ioctl.c next to the
implementation of the SCSI_IOCTL_SEND_COMMAND ioctl.

Doug Gilbert






-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: devices with more than one node

[Greg KH]

On Tue, Jan 13, 2004 at 08:12:56PM -0500, dougg@torque.net wrote:
> Quoting Greg KH <greg@kroah.com>:
> 
> > On Tue, Jan 13, 2004 at 03:01:47PM -0800, Patrick Mansfield wrote:
> > > Don't forget to let the scsi people know ;-) cc-ing linux-scsi
> > 
> > Ok, here goes:
> > 
> > linux-scsi, DO NOT USE THE cdev sysfs directory.  It will be going away
> > as soon as I get around to writing the patch for it.  Putting the sg
> > symlink in there is not the proper place.
> 
> Greg,
> Is the register_chrdev_region() call which according to
> J. Corbet's documentation allows support for more than 256 
> devices, going away? Or is it simply going to lose its
> sysfs visibility (in the /sys/cdev/major directory)?

Just the sysfs visibility is going to go away.

> > For scsi generic you should create a scsi generic class (scsi_generic?)
> > and create the individual sg devices in that directory (feel free to use
> > the simple_class.c code that is currently in the -mm tree if you want,
> > it makes it much simpler)
> 
> Does any device use the simple_class.c code yet?

I've posted patches that provide the following device support using the
simple_class.c code:
	- tty devices
	- sound devices
	- frame buffer devices
	- input devices
	- memory devices
	- misc devices
	- virtual console devices

All of those patches are in the -mm tree (well the vc device patch is
currently commented out due to some wierd bugs...)

I'll probably be spinning another set of those patches tomorrow, as I've
fixed some race conditions in the simple_class.c code now.

> > > st also needs changes.
> 
> and osst.
> 
> Kai changed the st naming scheme in /sys/cdev/major/st*
> in a way that seems to allow for more than 8 variants
> of each device.

Great.

> > I agree.
> > 
> > > Did anyone figure out how udev should handle the one tape device requiring
> > > multiple minors (for open/close with/without rewind)? It really is a
> > > single device requiring multiple dev entries.
> > 
> > Create multiple class_device items for every tape device and have the
> > device symlink point to the same scsi device.  The simple_class code
> > should make life a lot easier for you.
> > 
> > > For scsi_id support with udev, st needs to support SG_IO, AFAIUI it can
> > > use similiar code as found in sd.c and sr.c.
> > 
> > That's a scsi core issue, not a udev issue :)
> 
> Well, before cdev gets ripped out, following two symlinks
> (i.e. tape -> device -> generic) solves the long standing
> ULD to sg (and vice versa) mapping problem.

But they do not provide a "dev" file, and the hotplug event, which is
what userspace tools like udev require.  They also are the only types of
devices that use the cdev tree :)

If you make a class device, it will provide a symlink that you can use
to point to the device that sg is bound to.

Hope this helps,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: devices with more than one node

[Willem Riede]

On 2004.01.13 20:12, dougg@torque.net wrote:
> Quoting Greg KH <greg@kroah.com>:
> 
> > For scsi generic you should create a scsi generic class (scsi_generic?)
> > and create the individual sg devices in that directory (feel free to use
> > the simple_class.c code that is currently in the -mm tree if you want,
> > it makes it much simpler)
> 
> Does any device use the simple_class.c code yet?

I did in osst, see 
http://marc.theaimsgroup.com/?l=linux-kernel&m=107275923222124&w=2
  
> > > st also needs changes.
> 
> and osst.

Right. So I'm following this thread for guidance.

Regards, Willem Riede.

Re: devices with more than one node

[Douglas Gilbert]

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

Willem Riede wrote:
> On 2004.01.13 20:12, dougg@torque.net wrote:
> 
>>Quoting Greg KH <greg@kroah.com>:
>>
>>
>>>For scsi generic you should create a scsi generic class (scsi_generic?)
>>>and create the individual sg devices in that directory (feel free to use
>>>the simple_class.c code that is currently in the -mm tree if you want,
>>>it makes it much simpler)
>>
>>Does any device use the simple_class.c code yet?
> 
> 
> I did in osst, see 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107275923222124&w=2

Here is an sg patch against lk 2.6.1-mm2 that uses
simple_add_class_device() as suggested by Greg and
demonstrated by Willem in osst. The patch will apply
clean against the sg driver in lk 2.6.1 but will not
compile as the mm series defines simple_add_class_device().

So this patch is not meant to be placed in the mainline
kernel yet. It is for Kai and Willem to consider and
for others to critique.

The cdev stuff is still in place (and I assume Greg
will soon be removing its sysfs visibility). The symlinks
that Greg objected to (in /sys/cdev/major/sg* directories)
have been dropped. A reverse symlink called "generic" has
been redirected from the scsi device to the corresponding
/sys/class/scsi_generic/sg<n> directory.

To test it I modded scsi_debug to fake OnStream tape
drives and ran a 2.6.1-mm2 kernel. The attached
output of "cd /sys/class; tree scsi* osst" is instructive.
Two peculiar entries are:
     scsi_generic/sg0/driver -> ../../../bus/scsi/drivers/osst
     scsi_generic/sg1/driver -> ../../../bus/scsi/drivers/osst

This symlink only appears if the osst driver is loaded
_before_ the sg driver! It is also left dangling by
"rmmod osst". It seems that sysfs is still not happy
with multiple drivers controlling the one device. The scsi
subsystem solution to this is to relegate sg to be a
sysfs "non" driver. Hence sg has no entry under
/sys/bus/scsi/drivers and thus no obvious place to
put its driver parameters. Sg driver parameters could be
placed in the /sys/class/scsi_generic directory (with
class_create_file() ). Suggestions?

Doug Gilbert

[-- Attachment #2: sg_261mm2_simp.diff --]
[-- Type: text/plain, Size: 4313 bytes --]

--- linux/drivers/scsi/sg.c	2004-01-10 15:53:59.000000000 +1000
+++ linux/drivers/scsi/sg.c261mm2_simp	2004-01-15 16:53:02.156514584 +1000
@@ -58,10 +58,6 @@
 #include <linux/cdev.h>
 #include <linux/seq_file.h>
 
-#include <asm/io.h>
-#include <asm/uaccess.h>
-#include <asm/system.h>
-
 #include <linux/blkdev.h>
 #include "scsi.h"
 #include "hosts.h"
@@ -73,7 +69,7 @@
 
 #ifdef CONFIG_SCSI_PROC_FS
 #include <linux/proc_fs.h>
-static char *sg_version_str = "3.5.30 [20031010]";
+static char *sg_version_str = "3.5.30 [20040115]";
 
 static int sg_proc_init(void);
 static void sg_proc_cleanup(void);
@@ -1333,6 +1329,14 @@
 	.fasync = sg_fasync,
 };
 
+static struct class sg_sysfs_class = {
+        .name           = "scsi_generic",
+//      .hotplug        = tbd,
+//      .release        = tbd,
+};
+
+static int sg_sysfs_valid = 0;
+
 static int
 sg_add(struct class_device *cl_dev)
 {
@@ -1360,7 +1364,7 @@
 				tmp_dev_max * sizeof(Sg_device *));
 		if (NULL == tmp_da) {
 			printk(KERN_ERR
-			       "sg_attach: device array cannot be resized\n");
+			       "sg_add: device array cannot be resized\n");
 			error = -ENOMEM;
 			goto out;
 		}
@@ -1401,12 +1405,12 @@
 		sdp = NULL;
 	if (NULL == sdp) {
 		write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
-		printk(KERN_ERR "sg_attach: Sg_device cannot be allocated\n");
+		printk(KERN_ERR "sg_add: Sg_device cannot be allocated\n");
 		error = -ENOMEM;
 		goto out;
 	}
 
-	SCSI_LOG_TIMEOUT(3, printk("sg_attach: dev=%d \n", k));
+	SCSI_LOG_TIMEOUT(3, printk("sg_add: dev=%d \n", k));
 	memset(sdp, 0, sizeof(*sdp));
 	sprintf(disk->disk_name, "sg%d", k);
 	strncpy(cdev->kobj.name, disk->disk_name, KOBJ_NAME_LEN);
@@ -1432,16 +1436,24 @@
 		goto out;
 	}
 	sdp->cdev = cdev;
-	error = sysfs_create_link(&cdev->kobj, &scsidp->sdev_gendev.kobj, 
-				  "device");
-	if (error)
-		printk(KERN_ERR "sg_attach: unable to make symlink 'device'"
-		       " for sg%d\n", k);
-	error = sysfs_create_link(&scsidp->sdev_gendev.kobj, &cdev->kobj, 
-				  "generic");
-	if (error)
-		printk(KERN_ERR "sg_attach: unable to make symlink 'generic'"
-		       " back to sg%d\n", k);
+	if (sg_sysfs_valid) {
+		struct class_device * sg_class_member;
+
+		sg_class_member = simple_add_class_device(&sg_sysfs_class, 
+				MKDEV(SCSI_GENERIC_MAJOR, k), 
+				cl_dev->dev, "%s", 
+				disk->disk_name);
+		if (NULL == sg_class_member)
+			printk(KERN_WARNING "sg_add: "
+				"simple_add_class_devive failed\n");
+		class_set_devdata(sg_class_member, sdp);
+		error = sysfs_create_link(&scsidp->sdev_gendev.kobj, 
+					  &sg_class_member->kobj, "generic");
+		if (error)
+			printk(KERN_ERR "sg_add: unable to make symlink "
+					"'generic' back to sg%d\n", k);
+	} else
+		printk(KERN_WARNING "sg_add: sg_sys INvalid\n");
 
 	printk(KERN_NOTICE
 	       "Attached scsi generic sg%d at scsi%d, channel"
@@ -1512,7 +1524,7 @@
 
 	if (sdp) {
 		sysfs_remove_link(&scsidp->sdev_gendev.kobj, "generic");
-		sysfs_remove_link(&sdp->cdev->kobj, "device");
+		simple_remove_class_device(MKDEV(SCSI_GENERIC_MAJOR, k));
 		cdev_del(sdp->cdev);
 		sdp->cdev = NULL;
 		devfs_remove("%s/generic", scsidp->devfs_name);
@@ -1538,6 +1550,7 @@
 MODULE_LICENSE("GPL");
 
 MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+MODULE_PARM_DESC(allow_dio, "allow direct I/O (default: 0 (disallow))");
 
 static int __init
 init_sg(void)
@@ -1551,16 +1564,21 @@
 				    SG_MAX_DEVS, "sg");
 	if (rc)
 		return rc;
+	rc = class_register(&sg_sysfs_class);
+	if (rc)
+		goto err_out;
+	sg_sysfs_valid = 1;
 	rc = scsi_register_interface(&sg_interface);
-	if (rc) {
-		unregister_chrdev_region(MKDEV(SCSI_GENERIC_MAJOR, 0),
-				         SG_MAX_DEVS);
-		return rc;
-	}
+	if (0 == rc) {
 #ifdef CONFIG_SCSI_PROC_FS
-	sg_proc_init();
+		sg_proc_init();
 #endif				/* CONFIG_SCSI_PROC_FS */
-	return 0;
+		return 0;
+	}
+	class_unregister(&sg_sysfs_class);
+err_out:
+	unregister_chrdev_region(MKDEV(SCSI_GENERIC_MAJOR, 0), SG_MAX_DEVS);
+	return rc;
 }
 
 static void __exit
@@ -1570,6 +1588,8 @@
 	sg_proc_cleanup();
 #endif				/* CONFIG_SCSI_PROC_FS */
 	scsi_unregister_interface(&sg_interface);
+	class_unregister(&sg_sysfs_class);
+	sg_sysfs_valid = 0;
 	unregister_chrdev_region(MKDEV(SCSI_GENERIC_MAJOR, 0),
 				 SG_MAX_DEVS);
 	if (sg_dev_arr != NULL) {

[-- Attachment #3: scsi_tree.txt --]
[-- Type: text/plain, Size: 1275 bytes --]

scsi_device
|-- 2:0:0:0
|   |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:0:0
|   `-- driver -> ../../../bus/scsi/drivers/osst
`-- 2:0:1:0
    |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:1:0
    `-- driver -> ../../../bus/scsi/drivers/osst
scsi_generic
|-- sg0
|   |-- dev
|   |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:0:0
|   `-- driver -> ../../../bus/scsi/drivers/osst
`-- sg1
    |-- dev
    |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:1:0
    `-- driver -> ../../../bus/scsi/drivers/osst
scsi_host
`-- host2
    |-- cmd_per_lun
    |-- device -> ../../../devices/pseudo_0/adapter0/host2
    |-- host_busy
    |-- scan
    |-- sg_tablesize
    |-- unchecked_isa_dma
    `-- unique_id
osst
|-- osst0
|   |-- ADR_rev
|   |-- BOT_frame
|   |-- EOD_frame
|   |-- capacity
|   |-- dev
|   |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:0:0
|   |-- driver -> ../../../bus/scsi/drivers/osst
|   |-- file_count
|   `-- media_version
`-- osst1
    |-- ADR_rev
    |-- BOT_frame
    |-- EOD_frame
    |-- capacity
    |-- dev
    |-- device -> ../../../devices/pseudo_0/adapter0/host2/2:0:1:0
    |-- driver -> ../../../bus/scsi/drivers/osst
    |-- file_count
    `-- media_version

20 directories, 22 files

Re: devices with more than one node

[Greg KH]

On Thu, Jan 15, 2004 at 06:04:42PM +1000, Douglas Gilbert wrote:
> Willem Riede wrote:
> >On 2004.01.13 20:12, dougg@torque.net wrote:
> >
> >>Quoting Greg KH <greg@kroah.com>:
> >>
> >>
> >>>For scsi generic you should create a scsi generic class (scsi_generic?)
> >>>and create the individual sg devices in that directory (feel free to use
> >>>the simple_class.c code that is currently in the -mm tree if you want,
> >>>it makes it much simpler)
> >>
> >>Does any device use the simple_class.c code yet?
> >
> >
> >I did in osst, see 
> >http://marc.theaimsgroup.com/?l=linux-kernel&m=107275923222124&w=2
> 
> Here is an sg patch against lk 2.6.1-mm2 that uses
> simple_add_class_device() as suggested by Greg and
> demonstrated by Willem in osst. The patch will apply
> clean against the sg driver in lk 2.6.1 but will not
> compile as the mm series defines simple_add_class_device().

Nice, this looks much better, thanks.

> So this patch is not meant to be placed in the mainline
> kernel yet. It is for Kai and Willem to consider and
> for others to critique.
> 
> The cdev stuff is still in place (and I assume Greg
> will soon be removing its sysfs visibility).

I will.

> The symlinks
> that Greg objected to (in /sys/cdev/major/sg* directories)
> have been dropped. A reverse symlink called "generic" has
> been redirected from the scsi device to the corresponding
> /sys/class/scsi_generic/sg<n> directory.

That's nice.

> To test it I modded scsi_debug to fake OnStream tape
> drives and ran a 2.6.1-mm2 kernel. The attached
> output of "cd /sys/class; tree scsi* osst" is instructive.
> Two peculiar entries are:
>     scsi_generic/sg0/driver -> ../../../bus/scsi/drivers/osst
>     scsi_generic/sg1/driver -> ../../../bus/scsi/drivers/osst
> 
> This symlink only appears if the osst driver is loaded
> _before_ the sg driver! It is also left dangling by
> "rmmod osst". It seems that sysfs is still not happy
> with multiple drivers controlling the one device.

The driver model does not allow this, and probably will not in the
future.

Just keep sg as a "class", like this patch does.  That should fix your
issues, right?

> The scsi subsystem solution to this is to relegate sg to be a sysfs
> "non" driver. Hence sg has no entry under
> /sys/bus/scsi/drivers and thus no obvious place to
> put its driver parameters. Sg driver parameters could be
> placed in the /sys/class/scsi_generic directory (with
> class_create_file() ). Suggestions?

That's a good place for them.  Unfortunatly the changes I made to the
class_simple.c code does not provide you the ability to do this.  If you
want to do this (and I think it is a good idea) you will have to write
your own class code (like the usb_host class code).

Hope this helps,

greg k-h

Re: devices with more than one node

[Mike Anderson]

Greg KH [greg@kroah.com] wrote:
> > To test it I modded scsi_debug to fake OnStream tape
> > drives and ran a 2.6.1-mm2 kernel. The attached
> > output of "cd /sys/class; tree scsi* osst" is instructive.
> > Two peculiar entries are:
> >     scsi_generic/sg0/driver -> ../../../bus/scsi/drivers/osst
> >     scsi_generic/sg1/driver -> ../../../bus/scsi/drivers/osst
> > 
> > This symlink only appears if the osst driver is loaded
> > _before_ the sg driver! It is also left dangling by
> > "rmmod osst". It seems that sysfs is still not happy
> > with multiple drivers controlling the one device.
> 
> The driver model does not allow this, and probably will not in the
> future.
> 
> Just keep sg as a "class", like this patch does.  That should fix your
> issues, right?
> 

Greg a clarification check. There is a scsi_device class already that sg
registers an interface with. The interface of scsi_device class is used
to add / remove the scsi_generic simple class devices and this is ok to
keep doing (not that there is another easy way to do this since sg does not
bind).

> > The scsi subsystem solution to this is to relegate sg to be a sysfs
> > "non" driver. Hence sg has no entry under
> > /sys/bus/scsi/drivers and thus no obvious place to
> > put its driver parameters. Sg driver parameters could be
> > placed in the /sys/class/scsi_generic directory (with
> > class_create_file() ). Suggestions?
> 
> That's a good place for them.  Unfortunatly the changes I made to the
> class_simple.c code does not provide you the ability to do this.  If you
> want to do this (and I think it is a good idea) you will have to write
> your own class code (like the usb_host class code).
> 

Another option that should work is that sg could register as a
scsi_driver and use bus_match to ensure it never binds. The only
difference between the other upper level drivers would be the links to
the devices in bus/scsi/driver/sg would not exist like other upper level
drivers. You would have a place though for driver attributes.

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

Re: devices with more than one node

[Willem Riede]

On 2004.01.15 03:04, Douglas Gilbert wrote:
> 
> To test it I modded scsi_debug to fake OnStream tape
> drives and ran a 2.6.1-mm2 kernel. The attached
> output of "cd /sys/class; tree scsi* osst" is instructive.
> Two peculiar entries are:
>      scsi_generic/sg0/driver -> ../../../bus/scsi/drivers/osst
>      scsi_generic/sg1/driver -> ../../../bus/scsi/drivers/osst
> 
> This symlink only appears if the osst driver is loaded
> _before_ the sg driver! It is also left dangling by
> "rmmod osst". 

I see the same with real OnStream tape drives.
It appears that when an upper level driver like osst is
(un)loaded, your (sg) attach doesn't get a chance to
reconsider...

By the way, I notice that st produces links in scsi_device
that osst doesn't - 0:0:3:0 and 3:0:0:0 are OnStream drives:

scsi_device
|-- 0:0:3:0
|   `-- device -> ../../../devices/pci0000:00/0000:00:0e.0/host0/0:0:3:0
|-- 0:0:6:0
|   `-- device -> ../../../devices/pci0000:00/0000:00:0e.0/host0/0:0:6:0
|-- 1:0:0:0
|   |-- device -> ../../../devices/pci0000:00/0000:00:0e.1/host1/1:0:0:0
|   `-- driver -> ../../../bus/scsi/drivers/sd
|-- 1:0:1:0
|   |-- device -> ../../../devices/pci0000:00/0000:00:0e.1/host1/1:0:1:0
|   `-- driver -> ../../../bus/scsi/drivers/sd
|-- 2:0:0:0
|   |-- device -> ../../../devices/pci0000:00/0000:00:07.1/ide0/0.1/host2/2:0:0:0
|   `-- driver -> ../../../bus/scsi/drivers/st
|-- 3:0:0:0
|   `-- device -> ../../../devices/pci0000:00/0000:00:07.1/ide1/1.0/host3/3:0:0:0
`-- 4:0:0:0
    |-- device -> ../../../devices/pci0000:00/0000:00:07.1/ide1/1.1/host4/4:0:0:0
    `-- driver -> ../../../bus/scsi/drivers/st

Should I emulate what st does to create these entries?

Thanks, Willem Riede.