Re: udev - that famouse obsolete %e option

["Alexander E. Patrakov" <patrakov@ums.usu.ru>]

VMiklos wrote:
> hi,
> 
> %e option in udev is obsolete for a long time since, it's broken -
> correct me if i'm wrong. that sounds a bit weird to me: if something
> is broken then why not fixing it instead of marking it obsolete with
> the comment "don't use it"?

It can't be made to work, because uevents are processed by udev in 
parallel, and thus in essentially random order. So, after one boot, the 
uevent for /dev/hdb is processed before the one for /dev/hdd, and on the 
next boot the order is exactly the opposite. And users surely don't want 
to get /dev/cdrom pointing to their _random_ CD-ROM. On my system, I 
want /dev/cdrom to point always to my Samsung CD-ROM, and /dev/cdrom1 to 
a Philips model.

> so, my question is that if one should not use it, what are the
> alternatives? except the trivial "writing external an shell script
> that would do exactly the same as the current %e code does" one -
> which sounds a bit hackish to me, not a real solution.

There are scripts provided with Debian's udev package that do the 
following for CD-ROMS:

1) Use the existing ata_id, scsi_id and cdrom_id to detect whether each 
block device is a CD-ROM.

2) If a CD-ROM device is found for which there is no rule yet, write the 
rule of the following kind:

ACTION="add", BUS="ide", ID="0.1", SYMLINK+="cdrom", ENV{GENERATED}="1"
ACTION="add", BUS="ide", ID="1.1", SYMLINK+="cdrom1", ENV{GENERATED}="1"

The ENV{GENERATED}="1" part is there in order to be able to tell when a 
CD-ROM device is found for which there is no rule yet.

3) Rules generated at step (2) create CD-ROM symlinks.

A similar setup is used to generate persistent network interface names 
(because uevents are processed in parallel, network modules are loaded 
in random order, and without special steps one cannot determine which of 
the two network cards will become eth0).

However, take Debian scripts with a grain of salt. There are no known 
bugs about CD-ROMs in them, but there were some until very recently. 
Maybe there are more just hiding in the dark.

With network rules, one non-Debian user reported a bug when I tried to 
mimic them in LFS and use SYSFS{type} to distinguish between the to 
interfaces created by the madwifi driver: on both interfaces, 
SYSFS{type} is "1". There is no formal Debian bug report about that, 
because this report comes from a non-Debian user.

-- 
Alexander E. Patrakov

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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