Discussion:
"udevadm info --attribute-walk --path=/block/sda" doesn't show parents
Chris Friesen
2012-04-18 22:13:08 UTC
Permalink
I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.
Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
around in the udevadm code now.
Looking at the udevadm code led me to the following:

On the problematic 2.6.34 machine:

***@typhoon-base-unit0:/root> ls -l /sys/dev/block/
<snip>
lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda



On my 2.6.35 machine:

[***@blah udev-173]$ ls -l /sys/dev/block/
<snip>
lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda



So where do I go from here? Is there a simple kernel change to make my 2.6.34
kernel behave more like the more recent one? Would an older version of udev be
able to parse my 2.6.34 /sys directory properly, or do I need to figure out a
way to parse /sys manually?

Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
***@genband.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kay Sievers
2012-04-18 22:41:03 UTC
Permalink
Post by Chris Friesen
I have a 2.6.34.10-based kernel with udev-161 (also tested with udev=
adm from udev-173).
Post by Chris Friesen
When I run "udevadm info --attribute-walk --path=3D/block/sda" it ju=
st shows the device
Post by Chris Friesen
itself, and doesn't walk the whole chain showing the parents.
Is there anything I can do, or am I caught with a kernel that isn't =
properly supported?
Post by Chris Friesen
I'm not subscribed to the hotplug list, so cc'ing me would be apprec=
iated.
Post by Chris Friesen
I don't know what's causing the problem, but I find it suspicious th=
at /sys/block/sda
Post by Chris Friesen
is a directory rather than a symlink like it is on my 2.6.35.14 lapt=
op. =C2=A0I'm poking
Post by Chris Friesen
around in the udevadm code now.
<snip>
lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda
<snip>
lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:0=
0/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
Post by Chris Friesen
So where do I go from here? =C2=A0Is there a simple kernel change to =
make my 2.6.34
Post by Chris Friesen
kernel behave more like the more recent one? =C2=A0Would an older ver=
sion of udev be
Post by Chris Friesen
able to parse my 2.6.34 /sys directory properly, or do I need to figu=
re out a
Post by Chris Friesen
way to parse /sys manually?
On old kernels, the chain of parent devices was not always properly
exported, because the "struct class_device" created all device
directories and spread spread them all over the the /sys/class tree.
There was a "device" link created at these disconnected device
directories, which udev tried to follow to find the parents.

We cleaned that up that mess, by having a single and unified tree in
/sys/devices, and /sys/class and /sys/bus just have symlinks pointing
into that tree. "Hierarchy" vs. "classification" are properly
separated that way.

=46or a while the CONFIG_SYSFS_DEPRECATED controlled the behaviour, you
might check if that is available in your kernel and can be turned off
to switch to the unified hierarchy. I kind of lost track which kernel
versions did what here.

In general, if you need the more recent udev tools to work regarding
the chain of parents, which "udevadm info --attribute-walk" uses, you
need a newer kernel, which exports that natively. There is no support
for the "device" link in newer versions of udev. We only really
supports it the other way around, which is new kernels on older
userspace. So you either use a newer kernel for a new udev, or also
stick with the old udev if you are stuck with that old kernel.

Or alternatively, you patch-in the support for the old "struct
class_device" stuff into the curent udev, to support older kernels; it
should be fairly simple. If that's what you look for, I can look up
the stuff you need to add, just let me know.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Friesen
2012-04-18 21:42:59 UTC
Permalink
I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).

When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.

Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.


I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
around in the udevadm code now.


Some possibly-useful information:


***@typhoon-base-unit0:/root> udevadm info --attribute-walk --path=/block/sda

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/block/sda':
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="16"
ATTR{ext_range}=="256"
ATTR{removable}=="0"
ATTR{ro}=="0"
ATTR{size}=="586072368"
ATTR{alignment_offset}=="0"
ATTR{discard_alignment}=="0"
ATTR{capability}=="50"
ATTR{stat}==" 12 3 80 50 0 0 0 0 0 50 50"
ATTR{inflight}==" 0 0"


***@typhoon-base-unit0:/root> udevadm info -p /block/sda -q all
P: /block/sda
N: sda
S: scsi/host/bus/target/lun/disc
S: discs/disc0/disc
S: block/8:0
S: disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: UDEV_LOG=3
E: DEVPATH=/block/sda
E: SUBSYSTEM=block
E: DEVNAME=sda
E: ID_SCSI=1
E: ID_VENDOR=ATA
E: ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
E: ID_MODEL=WDC_WD3000BLHX-0
E: ID_MODEL_ENC=WDC\x20WD3000BLHX-0
E: ID_REVISION=04.0
E: ID_TYPE=disk
E: ID_SERIAL=1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: ID_SERIAL_SHORT=ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: ID_SCSI_SERIAL=WD-WX61E41PY599
E: ID_BUS=scsi
E: MAJOR=8
E: MINOR=0
E: DEVTYPE=disk
E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
E: PHYSDEVBUS=scsi
E: PHYSDEVDRIVER=sd
E: DEVLINKS=/dev/scsi/host/bus/target/lun/disc /dev/discs/disc0/disc /dev/block/8:0 /dev/disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599

***@typhoon-base-unit0:/root> ls -l /sys/block/sda
total 0
-r--r--r-- 1 root root 4096 Apr 18 14:16 alignment_offset
lrwxrwxrwx 1 root root 0 Apr 18 14:16 bdi -> ../../class/bdi/8:0
-r--r--r-- 1 root root 4096 Apr 18 14:16 capability
-r--r--r-- 1 root root 4096 Apr 18 14:16 dev
lrwxrwxrwx 1 root root 0 Apr 18 14:16 device -> ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
-r--r--r-- 1 root root 4096 Apr 18 14:16 discard_alignment
-r--r--r-- 1 root root 4096 Apr 18 14:16 ext_range
drwxr-xr-x 2 root root 0 Apr 18 14:16 holders
-r--r--r-- 1 root root 4096 Apr 18 14:16 inflight
drwxr-xr-x 2 root root 0 Apr 18 14:16 power
drwxr-xr-x 3 root root 0 Apr 18 14:16 queue
-r--r--r-- 1 root root 4096 Apr 18 14:16 range
-r--r--r-- 1 root root 4096 Apr 18 14:16 removable
-r--r--r-- 1 root root 4096 Apr 18 14:16 ro
drwxr-xr-x 4 root root 0 Apr 18 14:16 sda1
drwxr-xr-x 4 root root 0 Apr 18 14:16 sda2
-r--r--r-- 1 root root 4096 Apr 18 14:16 size
drwxr-xr-x 2 root root 0 Apr 18 14:16 slaves
-r--r--r-- 1 root root 4096 Apr 18 14:16 stat
lrwxrwxrwx 1 root root 0 Apr 18 14:16 subsystem -> ../../block
-rw-r--r-- 1 root root 4096 Apr 18 14:16 uevent


Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
***@genband.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Friesen
2012-04-18 21:46:00 UTC
Permalink
I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.
Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
around in the udevadm code now.
I forgot to include this....this might be useful as well:

***@typhoon-base-unit0:/root> udevadm info -q path -n /dev/sda
/block/sda



For comparison, on my 2.6.35.14 laptop I get:


[***@blah log]$ udevadm info -q path -n /dev/sda
/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
--
Chris Friesen
Software Developer
GENBAND
***@genband.com
www.genband.com
Loading...