class_device/udev support for tapes?

class_device/udev support for tapes?

[Arnd Bergmann]

Has anyone come up with a solution for using udev for tape devices?

What is obviously needed is a device class for tapes that can be
used from (at least) the atapi, scsi and s390 tape drivers. Porting
the class driver from the tty code to tape is rather trivial but
might not be the right solution because tapes tend to have multiple
interfaces (e.g. for opening a device in rewinding and non-rewinding
mode):

ATAPI:
crw-rw----    1 root     disk      37,   0 Apr 11  2002 /dev/ht0
crw-rw----    1 root     disk      37, 128 Apr 11  2002 /dev/nht0

SCSI:
crw-rw----    1 root     disk       9,   0 Apr 11  2002 /dev/st0
crw-rw----    1 root     disk       9,  96 Apr 11  2002 /dev/st0a
crw-rw----    1 root     disk       9,  32 Apr 11  2002 /dev/st0l
crw-rw----    1 root     disk       9,  64 Apr 11  2002 /dev/st0m
crw-rw----    1 root     disk       9, 128 Apr 11  2002 /dev/nst0
crw-rw----    1 root     disk       9, 224 Apr 11  2002 /dev/nst0a
crw-rw----    1 root     disk       9, 160 Apr 11  2002 /dev/nst0l
crw-rw----    1 root     disk       9, 192 Apr 11  2002 /dev/nst0m

osst:
crw-rw----    1 root     disk     206,   0 Apr 11  2002 /dev/osst0
crw-rw----    1 root     disk     206,  32 Apr 11  2002 /dev/osst0l
crw-rw----    1 root     disk     206,  96 Apr 11  2002 /dev/osst0a
crw-rw----    1 root     disk     206,  64 Apr 11  2002 /dev/osst0m

s/390 (dynamic major):
crw-rw----    1 root     disk     254,   0 Apr 11  2002 /dev/ntibm0
crw-rw----    1 root     disk     254,   1 Apr 11  2002 /dev/rtibm0

ftape:
crw-rw----    1 root     disk      27,   0 Apr 11  2002 /dev/qft0
crw-rw----    1 root     disk      27,   0 Apr 11  2002 /dev/rft0
crw-rw----    1 root     disk      27,   4 Apr 11  2002 /dev/nqft0
crw-rw----    1 root     disk      27,   4 Apr 11  2002 /dev/nrft0
crw-rw----    1 root     disk      27,  16 Apr 11  2002 /dev/zqft0
crw-rw----    1 root     disk      27,  20 Apr 11  2002 /dev/nzqft0
crw-rw----    1 root     disk      27,  32 Apr 11  2002 /dev/rawqft0
crw-rw----    1 root     disk      27,  32 Apr 11  2002 /dev/rawrft0
crw-rw----    1 root     disk      27,  36 Apr 11  2002 /dev/nrawqft0

Unlike block devices, there is no master device with anything
similar to partitions, but all the interfaces are equal. One way
to represent them would be to create a class device without a 
dev entry and have the chardev interfaces as child kobjects of that:

/sys/class/tape/st0/st0/dev
/sys/class/tape/st0/st0a/dev
/sys/class/tape/st0/nst0/dev
/sys/class/tape/st0/device -> ../../...
/sys/class/tape/rtibm0/ntibm0/dev

This would of course be inconsistant with all the other classes.
The second option I see is naming the 'dev' attribute differently:

/sys/class/tape/st0/dev-st
/sys/class/tape/st0/dev-sta
/sys/class/tape/st0/dev-nst
/sys/class/tape/st0/device -> ../../...
/sys/class/tape/rtibm0/dev-ntibm

This is also somewhat inconsistant from udev's point of view, but not
so much from the kernel.
The third option is to simply register one class device for each logical
device:

/sys/class/tape/st0/dev
/sys/class/tape/st0/device -> ../../...
/sys/class/tape/st0a/dev
/sys/class/tape/st0a/device -> ../../...
/sys/class/tape/nst0/dev
/sys/class/tape/nst0/device -> ../../...
/sys/class/tape/rtibm0/dev

This is at least possible with the least number of changes to udev
and the view of class devices, but not as intuitive for the user.

I am totally unsure which option should be used or if there is maybe
a better way that I  failed to see.

The other question is how to best design the kernel interface for 
registering a tape class device with a variable number of chardev nodes.

	Arnd <><



-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: class_device/udev support for tapes?

[Greg KH]

On Tue, Dec 02, 2003 at 06:35:18PM +0100, Arnd Bergmann wrote:
> Has anyone come up with a solution for using udev for tape devices?

The scsi people need to add support for this into the st driver.  They
also need to add it to their sg driver for scsi generic devices.  They
know about this, and hopefully are working on it...

> Unlike block devices, there is no master device with anything
> similar to partitions, but all the interfaces are equal. One way
> to represent them would be to create a class device without a 
> dev entry and have the chardev interfaces as child kobjects of that:
> 
> /sys/class/tape/st0/st0/dev
> /sys/class/tape/st0/st0a/dev
> /sys/class/tape/st0/nst0/dev
> /sys/class/tape/st0/device -> ../../...
> /sys/class/tape/rtibm0/ntibm0/dev

What is "st0" here?  Why not just:

/sys/class/scsi_tape/st0/dev
/sys/class/scsi_tape/st0a/dev
/sys/class/scsi_tape/nst0/dev
/sys/class/scsi_tape/ntibm0/dev

> This would of course be inconsistant with all the other classes.
> The second option I see is naming the 'dev' attribute differently:
> 
> /sys/class/tape/st0/dev-st
> /sys/class/tape/st0/dev-sta
> /sys/class/tape/st0/dev-nst

Hm, I probably don't understand tapes.  What's the difference between
st, sta, and nst?  Are they all different char devices for the same tape
device?  Doing different things?

> This is also somewhat inconsistant from udev's point of view, but not
> so much from the kernel.

True, but we can always work around that in udev, if it's necessary.

> The third option is to simply register one class device for each logical
> device:
> 
> /sys/class/tape/st0/dev
> /sys/class/tape/st0/device -> ../../...
> /sys/class/tape/st0a/dev
> /sys/class/tape/st0a/device -> ../../...
> /sys/class/tape/nst0/dev
> /sys/class/tape/nst0/device -> ../../...
> /sys/class/tape/rtibm0/dev
> 
> This is at least possible with the least number of changes to udev
> and the view of class devices, but not as intuitive for the user.
> 
> I am totally unsure which option should be used or if there is maybe
> a better way that I  failed to see.
> 
> The other question is how to best design the kernel interface for 
> registering a tape class device with a variable number of chardev nodes.

You might want to take this to the linux-scsi list, as the people there
should know how to do this.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: class_device/udev support for tapes?

[Arnd Bergmann]

On Tuesday 02 December 2003 19:00, Greg KH wrote:
> On Tue, Dec 02, 2003 at 06:35:18PM +0100, Arnd Bergmann wrote:
> > Has anyone come up with a solution for using udev for tape devices?
>
> The scsi people need to add support for this into the st driver.  They
> also need to add it to their sg driver for scsi generic devices.  They
> know about this, and hopefully are working on it...

Do you mean using the same device class for both the tape and sg chardevs?
Maybe I have misunderstood the current relationship between 'class'
and 'class_interface'. I thought that both sg and tape need to be 
classes, with a scsi tape belonging to both classes and having multiple
tape interfaces. However, scsi currently has a scsi_device class and
registers an sg interface for that.

> > Unlike block devices, there is no master device with anything
> > similar to partitions, but all the interfaces are equal. One way
> > to represent them would be to create a class device without a
> > dev entry and have the chardev interfaces as child kobjects of that:
> >
> > /sys/class/tape/st0/st0/dev
> > /sys/class/tape/st0/st0a/dev
> > /sys/class/tape/st0/nst0/dev
> > /sys/class/tape/st0/device -> ../../...
> > /sys/class/tape/rtibm0/ntibm0/dev
>
> What is "st0" here?  Why not just:
>
> /sys/class/scsi_tape/st0/dev
> /sys/class/scsi_tape/st0a/dev
> /sys/class/scsi_tape/nst0/dev
> /sys/class/scsi_tape/ntibm0/dev

Well, the first three are different representations of the same physical
scsi tape, while the ntibm0 tape is a different non-scsi tape and
also has other chardev representations that I skipped in the example.
They have different drivers (bus types, major numbers, available
chardevs...) but use the same ioctl interface and should therefore be
in the same class (or have the same interface?).

> > This would of course be inconsistant with all the other classes.
> > The second option I see is naming the 'dev' attribute differently:
> >
> > /sys/class/tape/st0/dev-st
> > /sys/class/tape/st0/dev-sta
> > /sys/class/tape/st0/dev-nst
>
> Hm, I probably don't understand tapes.  What's the difference between
> st, sta, and nst?  Are they all different char devices for the same tape
> device?  Doing different things?

Yes. AFAIK, they are almost identical but have minor interface differences.
For s390 and ATAPI, there are only two variants: the default rewinding
devices (/dev/rtibm0, /dev/rtibm1, /dev/ht0, ...) rewind the medium upon
close, the non-rewinding devices (/dev/ntibm0, /dev/ntibm1, /dev/nt0, ...)
don't. Other drivers (scsi, ftape, ...) have up to eight device nodes
per physical device, but I don't know the exact differences. It's a
silly design, but too late to change.
To make things worse, some drivers (well, at least s390 tape) have a block
device interface in addition to the character devices.

	Arnd <><



-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: class_device/udev support for tapes?

[Greg KH]

On Tue, Dec 02, 2003 at 09:09:15PM +0100, Arnd Bergmann wrote:
> On Tuesday 02 December 2003 19:00, Greg KH wrote:
> > On Tue, Dec 02, 2003 at 06:35:18PM +0100, Arnd Bergmann wrote:
> > > Has anyone come up with a solution for using udev for tape devices?
> >
> > The scsi people need to add support for this into the st driver.  They
> > also need to add it to their sg driver for scsi generic devices.  They
> > know about this, and hopefully are working on it...
> 
> Do you mean using the same device class for both the tape and sg chardevs?

No.

> Maybe I have misunderstood the current relationship between 'class'
> and 'class_interface'. I thought that both sg and tape need to be 
> classes, with a scsi tape belonging to both classes and having multiple
> tape interfaces. However, scsi currently has a scsi_device class and
> registers an sg interface for that.

That's right.  I mean add another class interface for scsi tapes.  I
think the scsi people are working on this.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel