Linux Hotplug development

Clemens Ladisch | 30 Jun 2012 19:15

udev: getting attributes from subdevice?

Hi,

I thought it would be useful to have persistent names for FireWire
devices:

########################################################################
ACTION=="remove", GOTO="persistent_firewire_end"
SUBSYSTEM!="firewire", GOTO="persistent_firewire_end"

TEST=="guid", SYMLINK+="firewire/by-id/guid-$attr{guid}"

TEST=="vendor_name", TEST=="model_name", \
	OPTIONS="string_escape=replace", \
	SYMLINK+="firewire/by-name/$attr{vendor_name} $attr{model_name}"

LABEL="persistent_firewire_end"
########################################################################

And these rules appear to work:

$ cat /sys/bus/firewire/devices/fw0/{vendor_name,model_name}
Linux Firewire
Juju
$ ls -l /dev/firewire/by-name/
lrwxrwxrwx 1 root root 9 2012-06-30 18:13 Linux_Firewire_Juju -> ../../fw0

However, there are devices where, due to some strange rules in the
FireWire specifications, some attributes end up belonging to a subdevice:

$ cat /sys/bus/firewire/devices/fw2/{vendor_name,model_name}

(Continue reading)

headers

Kay Sievers | 2 Jul 2012 19:03

Re: udev: getting attributes from subdevice?

On Sat, Jun 30, 2012 at 7:15 PM, Clemens Ladisch <clemens <at> ladisch.de> wrote:

> TEST=="vendor_name", TEST!="model_name", WAIT_FOR="$kernel.0/model_name"
> TEST=="vendor_name", TEST!="model_name", TEST=="$kernel.0/model_name", \
>         OPTIONS="string_escape=replace", \
>         SYMLINK+="firewire/by-name/$attr{vendor_name} $attr{$kernel.0/model_name}"
>
> But this doesn't work, probably because $kernel is not substituted
> before $attr:
>
> $ ls -l /dev/firewire/by-name/
> lrwxrwxrwx 1 root root 9 2012-06-30 18:13 LaCie_ -> ../../fw2
>
> (It works if I use $attr{fw2.0/model_name}, but that isn't generic enough.)
>
> Do I have to write a separate tool for extracting the name?

There is no direct support for accessing child devices, because it is
too racy and the child devices usually do not even exist at the time
the event for the parent device is handled.

Special care in the kernel need to be taken to make all that possible,
like we do for example for disks and partitions.

Aside from that, why this usually does not work well, the format char
replacement is just one pass from the left to the right, so that order
would not work.

Kay
--

(Continue reading)