Hi,
I have found one more problem with the tape detection. The event for the
btibm is completely different then for ntibm, rtibm. That is absolutely
understandable, since it is block device in completely different
subsystem. But there is no way how to connect this event:
KERNEL=="btibm", ACTION=="add"
to the virtual address of the device it represents.
The ntibm, rtibm can be bound to it by virtual address in KERNELS:
looking at device '/devices/css0/0.0.0004/0.0.0181/tape390/ntibm0':
KERNEL=="ntibm0"
SUBSYSTEM=="tape390"
DRIVER==""
looking at parent device '/devices/css0/0.0.0004/0.0.0181':
KERNELS=="0.0.0181"
SUBSYSTEMS=="ccw"
DRIVERS=="tape_34xx"
ATTRS{devtype}=="3480/22"
ATTRS{cutype}=="3480/22"
ATTRS{modalias}=="ccw:t3480m22dt3480dm22"
ATTRS{online}=="1"
ATTRS{cmb_enable}=="0"
ATTRS{availability}=="good"
ATTRS{medium_state}=="1"
ATTRS{first_minor}=="0"
ATTRS{state}=="UNUSED"
ATTRS{operation}=="---"
ATTRS{blocksize}=="0"
But the btibm event doesn't have that. It has only this:
looking at device '/devices/virtual/block/btibm0':
KERNEL=="btibm0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="1"
ATTR{removable}=="0"
ATTR{ro}=="0"
ATTR{size}=="8"
ATTR{capability}=="10"
ATTR{stat}==" 0 0 0 0 0 0
0 0 0 0
or this when udevadm monitor --env is used
UDEV [1284549523.426448] add /devices/virtual/block/btibm0 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/block/btibm0
SUBSYSTEM=block
MAJOR=252
MINOR=0
DEVTYPE=disk
SEQNUM=882
UDEVD_EVENT=1
DEVNAME=/dev/btibm0
UDEV [1284549523.575402] add /devices/virtual/bdi/252:0 (bdi)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/bdi/252:0
SUBSYSTEM=bdi
SEQNUM=883
UDEVD_EVENT=1
This problem can be solved for ACTION=="remove" when logical link
between device number in /dev and virtual address is already known from
ntibm, rtibm devices. Then removal of the btibm device can be tracked by
that number and assigned to correct virtual address through that logical
link. However, this link can't be used for ACTION=="add", because btibm
event can occur before (depends on scheduling) ntibm, rtibm events,
which means this link is not yet known.
This implies that when trying to wait till all device nodes in /dev are
ready for the tape on specific virtual address you can use uevents for
ntibm, rtibm but then you have to poll for btibm node in /dev anyway.
There is just no other (easy) way.
Or is there another way that I just don't see?
Radek Vlacil
-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of
Martin Schwidefsky
Sent: Tuesday, September 07, 2010 09:56
To: [email protected]
Subject: Re: Tapes 34xx detection
On Mon, 6 Sep 2010 12:52:39 +0100
"Vlacil, Radek" <[email protected]> wrote:
> Wouldn't it be possible to implement an enhancement that would
generate
> an uevent with ACTION="change" for this "tape loaded" kind of events?
If
> there is a massage for that generated in the system log, it shouldn't
be
> that hard :-).
That should be rather straightforward. Like this:
diff -urpN linux-2.6/drivers/s390/char/tape_core.c
linux-2.6-patched/drivers/s390/char/tape_core.c
--- linux-2.6/drivers/s390/char/tape_core.c 2010-08-02
00:11:14.000000000 +0200
+++ linux-2.6-patched/drivers/s390/char/tape_core.c 2010-09-07
09:53:05.000000000 +0200
@@ -217,15 +217,19 @@ tape_med_state_set(struct tape_device *d
switch(newstate){
case MS_UNLOADED:
device->tape_generic_status |= GMT_DR_OPEN(~0);
- if (device->medium_state == MS_LOADED)
+ if (device->medium_state == MS_LOADED) {
pr_info("%s: The tape cartridge has been
successfully "
"unloaded\n",
dev_name(&device->cdev->dev));
+ kobject_uevent(&device->cdev->dev.kobj,
KOBJ_CHANGE);
+ }
break;
case MS_LOADED:
device->tape_generic_status &= ~GMT_DR_OPEN(~0);
- if (device->medium_state == MS_UNLOADED)
+ if (device->medium_state == MS_UNLOADED) {
pr_info("%s: A tape cartridge has been
mounted\n",
dev_name(&device->cdev->dev));
+ kobject_uevent(&device->cdev->dev.kobj,
KOBJ_CHANGE);
+ }
break;
default:
// print nothing
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
