[PATCH / RFC] osst, st, sg sysfs removes

[PATCH / RFC] osst, st, sg sysfs removes

[Mike Anderson]

This patch is against 2.5.55

This patch is in response to the mail I sent the other day on the use of
to_scsi_device with our sysfs bus/scsi/devices directory containing more
than struct scsi_device objects. A link to the thread is below.

http://marc.theaimsgroup.com/?l=linux-scsi&m=104198504307087&w=2

This patch is just a removal of osst, st, and sg's sysfs nodes in the
devices directory. Current I do not have a place to replicate this
capability. It was unclear if osst and st entries where being used. The
correct place for osst and st is to have a char tree like the block tree
and have a pointer from the scsi device to the char entry. I do not know
of the proper place for sg yet. While sg is a char device it cannot
follow the same model as it can be associated with a scsi device along
with another char device.

Doug, The removal of the sg :gen has broken lscsi -g I will work on an
option to get this working again.

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

 osst.c |   53 -----------------------------------------------------
 osst.h |    2 --
 sg.c   |   35 -----------------------------------
 st.c   |   53 -----------------------------------------------------
 st.h   |    2 --
 5 files changed, 145 deletions(-)
------

--- 1.37/drivers/scsi/osst.c	Thu Dec 26 16:25:32 2002
+++ edited/drivers/scsi/osst.c	Thu Jan  9 09:06:43 2003
@@ -5324,22 +5324,6 @@
 
 #endif
 
-/* Driverfs file support */
-static ssize_t osst_device_kdev_read(struct device *driverfs_dev, char *page, size_t count, loff_t off)
-{
-	kdev_t kdev; 
-	kdev.value=(int)(long)driverfs_dev->driver_data;
-	return off ? 0 : sprintf(page, "%x\n",kdev.value);
-}
-static DEVICE_ATTR(kdev,S_IRUGO,osst_device_kdev_read,NULL);
-
-static ssize_t osst_device_type_read(struct device *driverfs_dev, char *page, size_t count, loff_t off) 
-{
-	return off ? 0 : sprintf (page, "CHR\n");
-}
-static DEVICE_ATTR(type,S_IRUGO,osst_device_type_read,NULL);
-
-
 static struct file_operations osst_fops = {
 	.owner =        THIS_MODULE,
 	.read =         osst_read,
@@ -5529,18 +5513,6 @@
 		
 		/*  Rewind entry  */
 		sprintf (name, "ot%s", formats[mode]);
-		sprintf(tpnt->driverfs_dev_r[mode].bus_id, "%s:%s", 
-				SDp->sdev_driverfs_dev.bus_id, name);
-		sprintf(tpnt->driverfs_dev_r[mode].name, "%s%s", 
-				SDp->sdev_driverfs_dev.name, name);
-		tpnt->driverfs_dev_r[mode].parent = &SDp->sdev_driverfs_dev;
-		tpnt->driverfs_dev_r[mode].bus = SDp->sdev_driverfs_dev.bus;
-		tpnt->driverfs_dev_r[mode].driver_data =
-			(void *)(long)__mkdev(OSST_MAJOR, dev_num + (mode << 5));
-		device_register(&tpnt->driverfs_dev_r[mode]);
-		device_create_file(&tpnt->driverfs_dev_r[mode], 
-				&dev_attr_type);
-		device_create_file(&tpnt->driverfs_dev_r[mode], &dev_attr_kdev);
 		tpnt->de_r[mode] =
 			devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
 					OSST_MAJOR, dev_num + (mode << 5),
@@ -5548,19 +5520,6 @@
 					&osst_fops, NULL);
 		/*  No-rewind entry  */
 		sprintf (name, "ot%sn", formats[mode]);
-		sprintf(tpnt->driverfs_dev_n[mode].bus_id, "%s:%s", 
-				SDp->sdev_driverfs_dev.bus_id, name);
-		sprintf(tpnt->driverfs_dev_n[mode].name, "%s%s", 
-				SDp->sdev_driverfs_dev.name, name);
-		tpnt->driverfs_dev_n[mode].parent= &SDp->sdev_driverfs_dev;
-		tpnt->driverfs_dev_n[mode].bus = SDp->sdev_driverfs_dev.bus;
-		tpnt->driverfs_dev_n[mode].driver_data =
-			(void *)(long)__mkdev(OSST_MAJOR, dev_num + (mode << 5) + 128);
-		device_register(&tpnt->driverfs_dev_n[mode]);
-		device_create_file(&tpnt->driverfs_dev_n[mode], 
-				&dev_attr_type);
-		device_create_file(&tpnt->driverfs_dev_n[mode], 
-				&dev_attr_kdev);
 		tpnt->de_n[mode] =
 			devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
 					OSST_MAJOR, dev_num + (mode << 5) + 128,
@@ -5606,18 +5565,6 @@
 		scsi_slave_detach(SDp);
 		osst_nr_dev--;
 		write_unlock(&os_scsi_tapes_lock);
-		for (mode = 0; mode < ST_NBR_MODES; ++mode) {
-			device_remove_file(&tpnt->driverfs_dev_r[mode],
-					&dev_attr_type);
-			device_remove_file(&tpnt->driverfs_dev_r[mode],
-					&dev_attr_kdev);
-			device_unregister(&tpnt->driverfs_dev_r[mode]);
-			device_remove_file(&tpnt->driverfs_dev_n[mode],
-					&dev_attr_type);
-			device_remove_file(&tpnt->driverfs_dev_n[mode],
-					&dev_attr_kdev);
-			device_unregister(&tpnt->driverfs_dev_n[mode]);
-			}
 		if (tpnt->header_cache != NULL) vfree(tpnt->header_cache);
 		if (tpnt->buffer) {
 			normalize_buffer(tpnt->buffer);
--- 1.8/drivers/scsi/osst.h	Sat Nov 23 10:53:29 2002
+++ edited/drivers/scsi/osst.h	Thu Jan  9 09:06:43 2003
@@ -559,8 +559,6 @@
   int current_mode;
   devfs_handle_t de_r[ST_NBR_MODES];  /*  Rewind entries     */
   devfs_handle_t de_n[ST_NBR_MODES];  /*  No-rewind entries  */
-  struct device driverfs_dev_r[ST_NBR_MODES];
-  struct device driverfs_dev_n[ST_NBR_MODES];
 
   /* Status variables */
   int partition;
--- 1.44/drivers/scsi/sg.c	Fri Dec 20 18:00:00 2002
+++ edited/drivers/scsi/sg.c	Thu Jan  9 09:06:43 2003
@@ -187,7 +187,6 @@
 	volatile char detached;	/* 0->attached, 1->detached pending removal */
 	volatile char exclude;	/* opened for exclusive access */
 	char sgdebug;		/* 0->off, 1->sense, 9->dump dev, 10-> all devs */
-	struct device sg_driverfs_dev;
 	struct gendisk *disk;
 } Sg_device;
 
@@ -1348,26 +1347,6 @@
 __setup("sg_def_reserved_size=", sg_def_reserved_size_setup);
 #endif
 
-/* Driverfs file support */
-static ssize_t
-sg_device_kdev_read(struct device *driverfs_dev, char *page,
-		    size_t count, loff_t off)
-{
-	Sg_device *sdp = list_entry(driverfs_dev, Sg_device, sg_driverfs_dev);
-	return off ? 0 : sprintf(page, "%x\n", MKDEV(sdp->disk->major,
-						     sdp->disk->first_minor));
-}
-static DEVICE_ATTR(kdev,S_IRUGO,sg_device_kdev_read,NULL);
-
-static ssize_t
-sg_device_type_read(struct device *driverfs_dev, char *page,
-		    size_t count, loff_t off)
-{
-	return off ? 0 : sprintf(page, "CHR\n");
-}
-
-static DEVICE_ATTR(type,S_IRUGO,sg_device_type_read,NULL);
-
 static int
 sg_attach(Scsi_Device * scsidp)
 {
@@ -1456,21 +1435,10 @@
 	sdp->detached = 0;
 	sdp->sg_tablesize = scsidp->host ? scsidp->host->sg_tablesize : 0;
 
-	memset(&sdp->sg_driverfs_dev, 0, sizeof (struct device));
-	sprintf(sdp->sg_driverfs_dev.bus_id, "%s:gen",
-		scsidp->sdev_driverfs_dev.bus_id);
-	sprintf(sdp->sg_driverfs_dev.name, "%sgeneric",
-		scsidp->sdev_driverfs_dev.name);
-	sdp->sg_driverfs_dev.parent = &scsidp->sdev_driverfs_dev;
-	sdp->sg_driverfs_dev.bus = scsidp->sdev_driverfs_dev.bus;
-
 	sg_nr_dev++;
 	sg_dev_arr[k] = sdp;
 	write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
 
-	device_register(&sdp->sg_driverfs_dev);
-	device_create_file(&sdp->sg_driverfs_dev, &dev_attr_type);
-	device_create_file(&sdp->sg_driverfs_dev, &dev_attr_kdev);
 	sdp->de = devfs_register(scsidp->de, "generic", DEVFS_FL_DEFAULT,
 				 SCSI_GENERIC_MAJOR, k,
 				 S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP,
@@ -1553,9 +1521,6 @@
 	if (sdp) {
 		devfs_unregister(sdp->de);
 		sdp->de = NULL;
-		device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_type);
-		device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_kdev);
-		device_unregister(&sdp->sg_driverfs_dev);
 		put_disk(sdp->disk);
 		sdp->disk = NULL;
 		if (NULL == sdp->headfp)
--- 1.52/drivers/scsi/st.c	Sat Dec 21 08:53:05 2002
+++ edited/drivers/scsi/st.c	Thu Jan  9 09:06:43 2003
@@ -3614,24 +3614,6 @@
 
 #endif
 
-/* Driverfs file support */
-static ssize_t st_device_kdev_read(struct device *driverfs_dev, 
-				   char *page, size_t count, loff_t off)
-{
-	kdev_t kdev; 
-	kdev.value=(int)(long)driverfs_dev->driver_data;
-	return off ? 0 : sprintf(page, "%x\n",kdev.value);
-}
-static DEVICE_ATTR(kdev,S_IRUGO,st_device_kdev_read,NULL);
-
-static ssize_t st_device_type_read(struct device *driverfs_dev, 
-				   char *page, size_t count, loff_t off) 
-{
-	return off ? 0 : sprintf (page, "CHR\n");
-}
-static DEVICE_ATTR(type,S_IRUGO,st_device_type_read,NULL);
-
-
 static struct file_operations st_fops =
 {
 	.owner =	THIS_MODULE,
@@ -3810,18 +3792,6 @@
 
 	    /*  Rewind entry  */
 	    sprintf (name, "mt%s", formats[mode]);
-	    sprintf(tpnt->driverfs_dev_r[mode].bus_id, "%s:%s", 
-		    SDp->sdev_driverfs_dev.bus_id, name);
-	    sprintf(tpnt->driverfs_dev_r[mode].name, "%s%s", 
-		    SDp->sdev_driverfs_dev.name, name);
-	    tpnt->driverfs_dev_r[mode].parent = &SDp->sdev_driverfs_dev;
-	    tpnt->driverfs_dev_r[mode].bus = SDp->sdev_driverfs_dev.bus;
-	    tpnt->driverfs_dev_r[mode].driver_data =
-			(void *)(long)__mkdev(SCSI_TAPE_MAJOR, dev_num + (mode << 5));
-	    device_register(&tpnt->driverfs_dev_r[mode]);
-	    device_create_file(&tpnt->driverfs_dev_r[mode], 
-			       &dev_attr_type);
-	    device_create_file(&tpnt->driverfs_dev_r[mode], &dev_attr_kdev);
 	    tpnt->de_r[mode] =
 		devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
 				SCSI_TAPE_MAJOR, dev_num + (mode << 5),
@@ -3829,19 +3799,6 @@
 				&st_fops, NULL);
 	    /*  No-rewind entry  */
 	    sprintf (name, "mt%sn", formats[mode]);
-	    sprintf(tpnt->driverfs_dev_n[mode].bus_id, "%s:%s", 
-		    SDp->sdev_driverfs_dev.bus_id, name);
-	    sprintf(tpnt->driverfs_dev_n[mode].name, "%s%s", 
-		    SDp->sdev_driverfs_dev.name, name);
-	    tpnt->driverfs_dev_n[mode].parent= &SDp->sdev_driverfs_dev;
-	    tpnt->driverfs_dev_n[mode].bus = SDp->sdev_driverfs_dev.bus;
-	    tpnt->driverfs_dev_n[mode].driver_data =
-			(void *)(long)__mkdev(SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128);
-	    device_register(&tpnt->driverfs_dev_n[mode]);
-	    device_create_file(&tpnt->driverfs_dev_n[mode], 
-			       &dev_attr_type);
-	    device_create_file(&tpnt->driverfs_dev_n[mode], 
-			       &dev_attr_kdev);
 	    tpnt->de_n[mode] =
 		devfs_register (SDp->de, name, DEVFS_FL_DEFAULT,
 				SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128,
@@ -3885,16 +3842,6 @@
 				tpnt->de_r[mode] = NULL;
 				devfs_unregister (tpnt->de_n[mode]);
 				tpnt->de_n[mode] = NULL;
-				device_remove_file(&tpnt->driverfs_dev_r[mode],
-						   &dev_attr_type);
-				device_remove_file(&tpnt->driverfs_dev_r[mode],
-						   &dev_attr_kdev);
-				device_unregister(&tpnt->driverfs_dev_r[mode]);
-				device_remove_file(&tpnt->driverfs_dev_n[mode],
-						   &dev_attr_type);
-				device_remove_file(&tpnt->driverfs_dev_n[mode],
-						   &dev_attr_kdev);
-				device_unregister(&tpnt->driverfs_dev_n[mode]);
 			}
 			tpnt->device = NULL;
 
--- 1.11/drivers/scsi/st.h	Fri Nov  1 04:28:10 2002
+++ edited/drivers/scsi/st.h	Thu Jan  9 09:06:43 2003
@@ -107,8 +107,6 @@
 	int current_mode;
 	devfs_handle_t de_r[ST_NBR_MODES];  /*  Rewind entries     */
 	devfs_handle_t de_n[ST_NBR_MODES];  /*  No-rewind entries  */
-	struct device driverfs_dev_r[ST_NBR_MODES];
-	struct device driverfs_dev_n[ST_NBR_MODES];
 
 	/* Status variables */
 	int partition;

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Kai Makisara]

On Thu, 9 Jan 2003, Mike Anderson wrote:

> This patch is against 2.5.55
>
> This patch is in response to the mail I sent the other day on the use of
> to_scsi_device with our sysfs bus/scsi/devices directory containing more
> than struct scsi_device objects. A link to the thread is below.
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=104198504307087&w=2
>
> This patch is just a removal of osst, st, and sg's sysfs nodes in the
> devices directory. Current I do not have a place to replicate this
> capability. It was unclear if osst and st entries where being used. The
> correct place for osst and st is to have a char tree like the block tree
> and have a pointer from the scsi device to the char entry. I do not know

Looks OK to me (at least the st part). I have been planning to export some
settings in the directories this patch removes but it has to wait until
corresponding entries can be created into the (currently non-existent)
char tree.

While looking at the sysfs/bus/scsi tree after this patch, I noticed that
all devices currently get linked to the sd driver:

14:20:59> ll /devices/bus/scsi/drivers/sd
total 0
lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 0:0:0:0 ->
../../../../devices/pci0/00:0e.1/0:0:0:0/
lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 1:0:5:0 ->
../../../../devices/pci0/00:0e.0/1:0:5:0/
lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 1:0:5:1 ->
../../../../devices/pci0/00:0e.0/1:0:5:1/
lrwxrwxrwx    1 root     root           36 2003-01-11 00:14 2:0:0:0 ->
../../../../devices/ide-scsi/2:0:0:0/

(0:0:0:0 is a disk, 1:0:5:0 a tape, 1:0:5:1 a changer (not attached to any
high-level driver!), 2:0:0:0 a cdrom)

The entries for sr and st do exist but are empty. sg is populated.

-- 
Kai

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Willem Riede]

On 2003.01.11 07:25 Kai Makisara wrote:
> On Thu, 9 Jan 2003, Mike Anderson wrote:
> 
> > This patch is against 2.5.55
> >
> > This patch is in response to the mail I sent the other day on the use of
> > to_scsi_device with our sysfs bus/scsi/devices directory containing more
> > than struct scsi_device objects. A link to the thread is below.
> >
> > http://marc.theaimsgroup.com/?l=linux-scsi&m=104198504307087&w=2
> >
> > This patch is just a removal of osst, st, and sg's sysfs nodes in the
> > devices directory. Current I do not have a place to replicate this
> > capability. It was unclear if osst and st entries where being used. The
> > correct place for osst and st is to have a char tree like the block tree
> > and have a pointer from the scsi device to the char entry. I do not know
> 
> Looks OK to me (at least the st part). I have been planning to export some
> settings in the directories this patch removes but it has to wait until
> corresponding entries can be created into the (currently non-existent)
> char tree.
> 
> While looking at the sysfs/bus/scsi tree after this patch, I noticed that
> all devices currently get linked to the sd driver:
> 
> 14:20:59> ll /devices/bus/scsi/drivers/sd
> total 0
> lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 0:0:0:0 ->
> ../../../../devices/pci0/00:0e.1/0:0:0:0/
> lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 1:0:5:0 ->
> ../../../../devices/pci0/00:0e.0/1:0:5:0/
> lrwxrwxrwx    1 root     root           40 2003-01-11 00:14 1:0:5:1 ->
> ../../../../devices/pci0/00:0e.0/1:0:5:1/
> lrwxrwxrwx    1 root     root           36 2003-01-11 00:14 2:0:0:0 ->
> ../../../../devices/ide-scsi/2:0:0:0/
> 
> (0:0:0:0 is a disk, 1:0:5:0 a tape, 1:0:5:1 a changer (not attached to any
> high-level driver!), 2:0:0:0 a cdrom)
> 
> The entries for sr and st do exist but are empty. sg is populated.
> 
On my system -- osst testing -- I see the following files (before 
applying the above patch):

/sysfs/bus/scsi/drivers/sd/2:0:1:0:ota
/sysfs/bus/scsi/drivers/sd/0:0:3:0:ota
/sysfs/bus/scsi/devices/2:0:1:0:ota
/sysfs/bus/scsi/devices/0:0:3:0:ota
/sysfs/devices/ide-scsi/2:0:1:0/2:0:1:0:ota
/sysfs/devices/pci0/00:0e.0/0:0:3:0/0:0:3:0:ota

I have two osst devices active, one scsi = 0:0:3:0, one ide = 2:0:1:0.
USB and Ieee1394 drives exist, but weren't active.

Actually each line above exists for {ot|ota|otl|otm|otn|otan|otln|otmn},
four modes, rewinding and non-rewinding.

The entries under bus/scsi/drivers/sd and bus/scsi/devices are symlinks,
the devices/ide-scsi and devices/pci0 are directories.

Now that Kai mentions it, why should drivers/sd have an entry for tapes at 
all? Shouldn't that be in drivers/st in his case, drivers/osst for me, and 
drivers/sg for Doug? drivers/osst does exist on my system.

Now, if I understand Mike correctly, the entires under /devices should
move to /char -- which doesn't exist, but should be modeled after /block.

That directory contains on my system: fd[01] hda loop[0-7] ram[0-15] sda sdb
where hda is a cdrom and sd[ab] hard disks.

So from that analogy, I take it, that /char should contain st[0-N], osst[0-M]
and sg[0-L], with the mode and {non}rewind variants for tapes as appropriate,
agreed?

Each directory should then have the old files kdev, name, power and type that
existed before? Plus whatever extra files Kai, Doug and I feel the user might
be interested in and that in 2.4 one might find in /proc somewehere?

Thanks for your guidance. Willem Riede.

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Mike Anderson]

Kai Makisara [Kai.Makisara@kolumbus.fi] wrote:
> Looks OK to me (at least the st part). I have been planning to export some
> settings in the directories this patch removes but it has to wait until
> corresponding entries can be created into the (currently non-existent)
> char tree.
> 
> While looking at the sysfs/bus/scsi tree after this patch, I noticed that
> all devices currently get linked to the sd driver:

This is a bug. The problem is that the drivers in bus/scsi/drivers are
not full enabled for sysfs. They are not using sysfs driver probe
routines. This means the scsi bus_match routine controls the binding of
the device to the driver. I need to change the scsi bus_match routine,
but it might involve a hack as it will need to do a test similar to the old
detect routines that we just removed.

The scsi cleans up that have happen make support of sysfs driver probe
routines close to implementing once we come up with a solution for sg
binding ( sysfs does not support multiple driver bindings per device).

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

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Mike Anderson]

Willem Riede [wrlk@riede.org] wrote:
> > Looks OK to me (at least the st part). I have been planning to export some
> > settings in the directories this patch removes but it has to wait until
> > corresponding entries can be created into the (currently non-existent)
> > char tree.
> > 
> > While looking at the sysfs/bus/scsi tree after this patch, I noticed that
> > all devices currently get linked to the sd driver:
> > 

This is a bug see previous response to Kai / this thread.

> So from that analogy, I take it, that /char should contain st[0-N], osst[0-M]
> and sg[0-L], with the mode and {non}rewind variants for tapes as appropriate,
> agreed?
> 
> Each directory should then have the old files kdev, name, power and type that
> existed before? Plus whatever extra files Kai, Doug and I feel the user might
> be interested in and that in 2.4 one might find in /proc somewehere?

Yes, I would believe that /char would be modeled after block and
contained that special nodes that tape devices need as you describe.

If /char follows the model of block by creating a back link to the char
device like (/sysfs/bus/scsi/devices/0:0:0:0/char) than there will be
a issue with sg and other char devices registering on the same device.

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

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Patrick Mochel]

> > So from that analogy, I take it, that /char should contain st[0-N], osst[0-M]
> > and sg[0-L], with the mode and {non}rewind variants for tapes as appropriate,
> > agreed?
> > 
> > Each directory should then have the old files kdev, name, power and type that
> > existed before? Plus whatever extra files Kai, Doug and I feel the user might
> > be interested in and that in 2.4 one might find in /proc somewehere?
> 
> Yes, I would believe that /char would be modeled after block and
> contained that special nodes that tape devices need as you describe.

I have reservations about blindly adding a 'char' subsystem. However, I 
think it would be useful, and encourage someone to do the leg work..

	-pat

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Mike Anderson]

Patrick Mochel [mochel@osdl.org] wrote:
> 
> I have reservations about blindly adding a 'char' subsystem. However, I 
> think it would be useful, and encourage someone to do the leg work..

That was not my intention. A char subsystem would need to have leg work
similar to what others did for block. We do not want to create a char
directory in sysfs and start populating it quickly to solve point
problems.

One point I was trying to make in previous mail was that if a char tree
follows the semantics of a block tree and creates a back link from the
device we need to consider the issue of "sg" (i.e. possible multiple
registers with the char subsystem per device) along with other devices up
front. 

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

Re: [PATCH / RFC] osst, st, sg sysfs removes

[Andries Brouwer]

On Tue, Jan 14, 2003 at 10:33:14AM -0800, Mike Anderson wrote:
> Patrick Mochel [mochel@osdl.org] wrote:

> > I have reservations about blindly adding a 'char' subsystem. However, I 
> > think it would be useful, and encourage someone to do the leg work..

> One point I was trying to make in previous mail was that if a char tree
> follows the semantics of a block tree and creates a back link from the
> device we need to consider the issue of "sg" (i.e. possible multiple
> registers with the char subsystem per device) along with other devices up
> front. 

One question is: do char devices exist?
A possible point of view is that there is the wide class of devices,
and that there are several subclasses. (Like: block devices, network devices,
USB devices.)

Andries