From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alexander E. Patrakov" Date: Mon, 31 Jul 2006 12:45:14 +0000 Subject: Re: udev - that famouse obsolete %e option Message-Id: <44CDFB5A.7030302@ums.usu.ru> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org VMiklos wrote: > hi, >=20 > %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=20 parallel, and thus in essentially random order. So, after one boot, the=20 uevent for /dev/hdb is processed before the one for /dev/hdd, and on the=20 next boot the order is exactly the opposite. And users surely don't want=20 to get /dev/cdrom pointing to their _random_ CD-ROM. On my system, I=20 want /dev/cdrom to point always to my Samsung CD-ROM, and /dev/cdrom1 to=20 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=20 following for CD-ROMS: 1) Use the existing ata_id, scsi_id and cdrom_id to detect whether each=20 block device is a CD-ROM. 2) If a CD-ROM device is found for which there is no rule yet, write the=20 rule of the following kind: ACTION=3D"add", BUS=3D"ide", ID=3D"0.1", SYMLINK+=3D"cdrom", ENV{GENERATED}= =3D"1" ACTION=3D"add", BUS=3D"ide", ID=3D"1.1", SYMLINK+=3D"cdrom1", ENV{GENERATED= }=3D"1" The ENV{GENERATED}=3D"1" part is there in order to be able to tell when a=20 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=20 (because uevents are processed in parallel, network modules are loaded=20 in random order, and without special steps one cannot determine which of=20 the two network cards will become eth0). However, take Debian scripts with a grain of salt. There are no known=20 bugs about CD-ROMs in them, but there were some until very recently.=20 Maybe there are more just hiding in the dark. With network rules, one non-Debian user reported a bug when I tried to=20 mimic them in LFS and use SYSFS{type} to distinguish between the to=20 interfaces created by the madwifi driver: on both interfaces,=20 SYSFS{type} is "1". There is no formal Debian bug report about that,=20 because this report comes from a non-Debian user. --=20 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=3Djoin.php&p=3Dsourceforge&CID=DEVD= EV _______________________________________________ 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