class_device/udev support for tapes?

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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...

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

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?

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

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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.

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?).

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

No.

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_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel