udev - that famouse obsolete %e option

udev - that famouse obsolete %e option

[VMiklos]

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"?

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.

thanks for your help,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Alexander E. Patrakov]

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

Re: udev - that famouse obsolete %e option

[Marco d'Itri]

On Jul 31, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> 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.
There were many bugs about this, after fixing them I did not get any
more reports so I assume that all common drivers now work fine.

-- 
ciao,
Marco

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Alexander E. Patrakov]

Marco d'Itri wrote:
> On Jul 31, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:
> 
>> 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.
> There were many bugs about this, after fixing them I did not get any
> more reports so I assume that all common drivers now work fine.

Thanks for your work. Could you please tell me which example rules would 
now be generated for Atheros wireless cards?

-- 
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

Re: udev - that famouse obsolete %e option

[Marco d'Itri]

On Jul 31, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> Thanks for your work. Could you please tell me which example rules would 
> now be generated for Atheros wireless cards?
The same as for every other driver:

SUBSYSTEM="net", DRIVER="?*", SYSFS{address}="00:0c:6e:a6:e2:a5", NAME="eth0"


It's also important to notice interfaces for which no rule are
generated:

...

ENV{PHYSDEVDRIVER}!="?*", GOTO="persistent_net_generator_end"

KERNEL="eth*|ath*|wlan*|ra*|sta*", \
        IMPORT{program}="write_net_rules $sysfs{address}"

...

LABEL="persistent_net_generator_end"


-- 
ciao,
Marco

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Kay Sievers]

On Mon, 2006-07-31 at 14:24 +0200, 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"?
> 
> 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.

It just conceptually can't work, and only creates silly and useless
random numbers without any useful meaning. Udev will not provide the
infrastructure for such a silly thing. The days where hardware didn't
change during runtime, when you used this simple type of enumeration, is
long over. And these days will never come back.

Also see here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;fúQ#l48

Kay


-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/7/31, Alexander E. Patrakov <patrakov@ums.usu.ru>:
> 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.

thanks for the reply. ok, i'll have a look at them

thanks,
VMiklos

-- 
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/7/31, Kay Sievers <kay.sievers@vrfy.org>:
> Also see here:
>   http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;fúQ#l48

does this means that - in case the numbers won't depend on the device
probing order - such a small tool in "extras" would be welcome? i mean
currently various distros have custom (broken or not broken) scripts
for this problem and a see unnecessary fregmentation. if it would be
welcome, i would try to write one that is ok by the udev developers
then it could be used safely

or is this just a foolish idea from me? :)

thanks,
VMiklos

-- 
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> On Jul 31, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:
>
>> Thanks for your work. Could you please tell me which example rules would 
>> now be generated for Atheros wireless cards?
> The same as for every other driver:
>
> SUBSYSTEM="net", DRIVER="?*", SYSFS{address}="00:0c:6e:a6:e2:a5", NAME="eth0"

SYSFS{type}="1" will also be added for Atheros card rules.

-- 
Olivier Blin - Mandriva

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Kay Sievers]

On Tue, 2006-08-01 at 12:27 +0200, VMiklos wrote:
> 2006/7/31, Kay Sievers <kay.sievers@vrfy.org>:
> > Also see here:
> >   http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;fúQ#l48
> 
> does this means that - in case the numbers won't depend on the device
> probing order - such a small tool in "extras" would be welcome? i mean
> currently various distros have custom (broken or not broken) scripts
> for this problem and a see unnecessary fregmentation. if it would be
> welcome, i would try to write one that is ok by the udev developers
> then it could be used safely
> 
> or is this just a foolish idea from me? :)

How would you manage the numbers to stick with a particular device
across reboots and reconfiguration? I can't imagine a "small tool" doing
that job. It is entirely device class specific how to to that, and I
don't think it can be solved at a generic level.

Kay


-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> How would you manage the numbers to stick with a particular device
> across reboots and reconfiguration? I can't imagine a "small tool" doing
> that job. It is entirely device class specific how to to that, and I
> don't think it can be solved at a generic level.

i'm thinking of cd/dvd symlinks at the moment. an example: i have a
cdrw+dvd (hdc) drive and a dvdrw drive (sr0). using cdrom_id, it's
possible to create the following nodes: cdrom-hdc, cdrw-hdc, dvd-hdc,
(same for sr0) and dvdrw-sr0. then the "tool" would create
cdrom->cdrom-hdc, cdrom1->cdrom-sr0, ..., dvdrw->dvdrw-sr0 symlinks.
and yes, across the reboots hdc would _always_ become cdrom, and sr0
would _always_ become cdrom1

is this a bad idea?

thanks,
VMiklos

-- 
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 01 August 2006 20:17, VMiklos wrote:
> 2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> > How would you manage the numbers to stick with a particular device
> > across reboots and reconfiguration? I can't imagine a "small tool" doing
> > that job. It is entirely device class specific how to to that, and I
> > don't think it can be solved at a generic level.
>
> i'm thinking of cd/dvd symlinks at the moment. an example: i have a
> cdrw+dvd (hdc) drive and a dvdrw drive (sr0). using cdrom_id, it's
> possible to create the following nodes: cdrom-hdc, cdrw-hdc, dvd-hdc,
> (same for sr0) and dvdrw-sr0. then the "tool" would create
> cdrom->cdrom-hdc, cdrom1->cdrom-sr0, ..., dvdrw->dvdrw-sr0 symlinks.
> and yes, across the reboots hdc would _always_ become cdrom, and sr0
> would _always_ become cdrom1
>

Most distributions already have rules that do something similar - it is just 
that having support for this _inside_ of udev core does not make sense.

# udev persistent rules for block subsystem
# Generated by Mandriva udev rules
# See /etc/udev/rules.d/62-create_persistent.rules

SUBSYSTEM="block", ACTION="add", 
ENV{ID_PATH}="pci-0000:00:04.0-scsi-1:0:0:0", SYMLINK+="cdrom cdrom0 dvd 
dvd0", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM="block", ACTION="add", ENV{ID_PATH}="pci-0000:00:04.0-ide-1:0", 
SYMLINK+="cdrom1 dvd1", ENV{MDV_CONFIGURED}="yes"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD4DBQFEz4LuR6LMutpd94wRArglAJ9XjMNVwL6sL4wqnZGcmJhOcfShFwCYmjma
iXp1lRl2Gufs60lQbiBTBQ=
=O+R5
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 1770 bytes --]

On Tue, Aug 01, 2006 at 06:17:48PM +0200, VMiklos wrote:
> 2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> > How would you manage the numbers to stick with a particular device
> > across reboots and reconfiguration? I can't imagine a "small tool" doing
> > that job. It is entirely device class specific how to to that, and I
> > don't think it can be solved at a generic level.
> 
> i'm thinking of cd/dvd symlinks at the moment. an example: i have a
> cdrw+dvd (hdc) drive and a dvdrw drive (sr0). using cdrom_id, it's
> possible to create the following nodes: cdrom-hdc, cdrw-hdc, dvd-hdc,
> (same for sr0) and dvdrw-sr0. then the "tool" would create
> cdrom->cdrom-hdc, cdrom1->cdrom-sr0, ..., dvdrw->dvdrw-sr0 symlinks.
> and yes, across the reboots hdc would _always_ become cdrom, and sr0
> would _always_ become cdrom1

In your particular setup, yes, but how do you guarantee that sr0 is
always the same device?  If you add another SCSI "CD-class" device, or
you had two of them today, there'd be no guarantee that sr0 was always
the device that you think of as "first".  And since there's no guarantee,
the cdrom1 symlink *can* point to a different physical device from one
boot to the next, even if it always points at sr0.  (Or it always points
at cdrom-sr0, which in turn points at sr0.  Either way, same issue --
sr0 is not always the same physical device.)

Much better to come up with a way to uniquely identify each device, then
create a rule that uses that method and creates a symlink with a stable
name.  For CD-like devices, the method would probably be the device
path.  Then, whatever real node points at the physical device you're
interested in (sr0, sr1, etc.), you'll have a stable symlink pointing at
that node.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
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=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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

Re: udev - that famouse obsolete %e option

[Kay Sievers]

On Tue, 2006-08-01 at 18:17 +0200, VMiklos wrote:
> 2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> > How would you manage the numbers to stick with a particular device
> > across reboots and reconfiguration? I can't imagine a "small tool" doing
> > that job. It is entirely device class specific how to to that, and I
> > don't think it can be solved at a generic level.
> 
> i'm thinking of cd/dvd symlinks at the moment. an example: i have a
> cdrw+dvd (hdc) drive and a dvdrw drive (sr0). using cdrom_id, it's
> possible to create the following nodes: cdrom-hdc, cdrw-hdc, dvd-hdc,
> (same for sr0) and dvdrw-sr0. then the "tool" would create
> cdrom->cdrom-hdc, cdrom1->cdrom-sr0, ..., dvdrw->dvdrw-sr0 symlinks.
> and yes, across the reboots hdc would _always_ become cdrom, and sr0
> would _always_ become cdrom1
> 
> is this a bad idea?

Yes, very bad. The kernel names hdc and sr0 are not necessarily stable,
so this does not help anything. You need to use device owned unique
properties like serial numbers, vendor/product strings, and not care
about the kernel names at all, if you want stable names.

Kay


-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/1, Andrey Borzenkov <arvidjaar@mail.ru>:
> Most distributions already have rules that do something similar - it is just
> that having support for this _inside_ of udev core does not make sense.

yes, that's my problem: every distro creates custom solutions for the
same problem, while including them _inside_ of udev would prevent a
lot of unnecessary work

Bryan, Kay: i see your point, but my problem is that if you insert a
unique id to an udev rule then it'll be usable only on one computer

i began the thread with the %e option, the problem with that (as you
said) was that using it the symlinks changed after _every_ reboot. the
tool what i wanted to contribute would produce exactly the same
symlinks after every reboot as long as no devices are inserted or
removed

now i see that such a tool won't be ever included because:
1) if it contains no hardwired device ids then the symlinks will
change (which is not a problem for a normal user since normally nobody
inserts / removes _multiple_ cd/dvd drives to his computer)

2) if it contains then of course it's not generic enough to make sense
anybody else then one person

and you know the problem when something doesn't get upstreamed: all
the distros should fix the additions again and again when something is
changed. that's why in long-term nobody can maintain a proper
kernel-driver if it's not in the vanilla kernel, and that's why i
wanted to contribute something that is usable not only for one distro,
but others. but i can't because of 1) and 2) :-(

thank you for help,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Kay Sievers]

On Tue, 2006-08-01 at 20:16 +0200, VMiklos wrote:
> 2006/8/1, Andrey Borzenkov <arvidjaar@mail.ru>:
> > Most distributions already have rules that do something similar - it is just
> > that having support for this _inside_ of udev core does not make sense.
> 
> yes, that's my problem: every distro creates custom solutions for the
> same problem, while including them _inside_ of udev would prevent a
> lot of unnecessary work
> 
> Bryan, Kay: i see your point, but my problem is that if you insert a
> unique id to an udev rule then it'll be usable only on one computer

Sure that's the point. You have to create device-specific udev rules
on-the-fly with the first device-discovery. Everything else can't work
reliably and can not be included, cause it will just give the impression
to solve a problem, which it doesn't.

If you want to work on this, please start with one of the several
solutions to name optical drives persistently by writing udev rules. I'm
sure at some point we will include one of them in the udev tree.

Thanks,
Kay


-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> Sure that's the point. You have to create device-specific udev rules
> on-the-fly with the first device-discovery. Everything else can't work

hmm, that's sounds promising

> If you want to work on this, please start with one of the several
> solutions to name optical drives persistently by writing udev rules. I'm
> sure at some point we will include one of them in the udev tree.

good news, at least :)

thanks,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
> If you want to work on this, please start with one of the several
> solutions to name optical drives persistently by writing udev rules. I'm
> sure at some point we will include one of them in the udev tree.

here cames my first try:

http://frugalware.org/~vmiklos/patches/udev-096-optical_gen.diff

comments? :)

thanks,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[Alexander E. Patrakov]

VMiklos wrote:
> 2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
>> If you want to work on this, please start with one of the several
>> solutions to name optical drives persistently by writing udev rules. I'm
>> sure at some point we will include one of them in the udev tree.
> 
> here cames my first try:
> 
> http://frugalware.org/~vmiklos/patches/udev-096-optical_gen.diff
> 
> comments? :)

(I have not fully read that, but can still identify missing pieces)

The interaction with the boot scripts must be documented. The problem is
that udev rules that are needed to generate cdrom rules are triggered
when the root filesystem is read-only, and thus the generated rules
cannot be saved without additional efforts.

Debian works around this by saving the generated rules to /dev/shm and
copying them to /etc/udev/rules.d in a separate bootscript. LFS in the
past (until the Debian-based generator was completely dropped due to
cries of some people about too much automation, and because of mails
like
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057166.html) 

did the following:

# /etc/udev/rules.d/81-cdrom.rules: Set CD-ROM permissions and get
device capabilities
ACTION="add", SUBSYSTEM="block", ENV{ID_TYPE}="cd",
IMPORT{program}="cdrom_id --export $tempnode", GROUP="cdrom"

# /etc/udev/rules.d/82-persistent-cd.rules: generated file
ACTION="add", SUBSYSTEM="block", BUS="ide", ID="0.1",
ENV{ID_CDROM}="1", SYMLINK+="cdrom", ENV{GENERATED}="1"

# /etc/udev/rules.d/83-cdrom-symlinks.rules: Determine CD drive capability.

ACTION!="add",          GOTO="cd_aliases_generator_end"
SUBSYSTEM!="block",     GOTO="cd_aliases_generator_end"
ENV{GENERATED}="?*",   GOTO="cd_aliases_generator_end"

# Fail the uevent if the autogenerated rules cannot be saved
ENV{ID_CDROM}="?*", PROGRAM="/bin/grep -c ' / [^[:space:]]* rw'
/proc/mounts",
RESULT!="2", RUN+="/bin/false", GOTO="cd_aliases_generator_end"

ENV{ID_CDROM}="?*", PROGRAM="write_cd_aliases", SYMLINK+="%c"

LABEL="cd_aliases_generator_end"

The idea is that the rule with grep fails the entire uevent when the
root filesystem is read-only. Udev will then add a symlink to the
relevant directory in sysfs to /dev/.udev/failed, and a separate
bootscript will retrigger all failed uevents again after mounting all
filesystems.

-- 
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/2, Alexander E. Patrakov <patrakov@ums.usu.ru>:
> The interaction with the boot scripts must be documented. The problem is
> that udev rules that are needed to generate cdrom rules are triggered
> when the root filesystem is read-only, and thus the generated rules
> cannot be saved without additional efforts.
>
> (...)
>
> The idea is that the rule with grep fails the entire uevent when the
> root filesystem is read-only. Udev will then add a symlink to the
> relevant directory in sysfs to /dev/.udev/failed, and a separate
> bootscript will retrigger all failed uevents again after mounting all
> filesystems.

thanks for pointing out that problem. i've added a --writetest option
to optical_gen and updated its manpage on how to handle this problem,
basically it contains what you've suggested.

you can find the second try at:
http://frugalware.org/~vmiklos/patches/udev-096-optical_gen2.diff

thanks,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/2, VMiklos <vmiklos@gmail.com>:
> 2006/8/2, Alexander E. Patrakov <patrakov@ums.usu.ru>:
> > The interaction with the boot scripts must be documented. The problem is
> > that udev rules that are needed to generate cdrom rules are triggered
> > when the root filesystem is read-only, and thus the generated rules
> > cannot be saved without additional efforts.
> >
> > (...)
> >
> > The idea is that the rule with grep fails the entire uevent when the
> > root filesystem is read-only. Udev will then add a symlink to the
> > relevant directory in sysfs to /dev/.udev/failed, and a separate
> > bootscript will retrigger all failed uevents again after mounting all
> > filesystems.
>
> thanks for pointing out that problem. i've added a --writetest option
> to optical_gen and updated its manpage on how to handle this problem,
> basically it contains what you've suggested.
>
> you can find the second try at:
> http://frugalware.org/~vmiklos/patches/udev-096-optical_gen2.diff

any comments?

thanks,
VMiklos

-- 
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
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

Re: udev - that famouse obsolete %e option

[VMiklos]

2006/8/7, VMiklos <vmiklos@gmail.com>:
> 2006/8/2, VMiklos <vmiklos@gmail.com>:
> > thanks for pointing out that problem. i've added a --writetest option
> > to optical_gen and updated its manpage on how to handle this problem,
> > basically it contains what you've suggested.
> >
> > you can find the second try at:
> > http://frugalware.org/~vmiklos/patches/udev-096-optical_gen2.diff
>
> any comments?

hmmm, should i resend this with a [PATCH] in the subject?

thanks,
VMiklos

--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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