udev user specified or human readable /dev names

udev user specified or human readable /dev names

[Patrick Mansfield]

Hi -

Per posts and an accepted patch on dm-devel about dm multipath user
friendly names:

https://www.redhat.com/archives/dm-devel/2005-October/msg00004.html
https://www.redhat.com/archives/dm-devel/2005-October/msg00067.html

But the above is a dm multipath only solution.

It's a good idea to allow user specified names on top of the
/dev/disk/by-* device names. Though dm likely needs a dm_id in order to
support the method outlined here.

If we could set and compare environment variables, or compare SYMLINK, a
separate rules file (doesn't have to be separate, just seems like a good
idea) could be used to add symlinks to user specified names.

i.e. move udev_rules.c:apply_format() into udev_utils.c, and call it
before comparison as well as before (AFAIUI) generating names, though I
somehow doubt the change is that simple.

Then, we could have rules like:

KERNEL="sd*[!0-9]|sr*|dasd*[!0-9]", ENV{ID_SERIAL}="?*", ENV{ID_FULL_PATH}="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
ENV{ID_FULL_PATH}="?*", SYMLINK+="$env{ID_FULL_PATH}"

And for each device that we want to give a user specified name, use (would
also need partition specific rules):

ENV{ID_FULL_PATH}="disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849" SYMLINK+="media-files"

And similar for the other disk/by-* methods.

Any comments on the above? 

Is my rule just wrong, or is there a better method?

Running with udev 069 on FC rawhide, with these rules:

SYMLINK="*foo*" SYMLINK+="user/bar"

KERNEL="sdm" ENV{VAL1}="somevalue"
KERNEL="sdm" ENV{VAL2}="$env{VAL1}"

KERNEL="sdm" SYMLINK+="user/show-val1-$env{VAL1}"
KERNEL="sdm" SYMLINK+="user/show-val2-$env{VAL2}"

ENV{VAL1}="somevalue" SYMLINK+="user/val1"
ENV{VAL2}="somevalue" SYMLINK+="user/val2"

Do not work as might be expected: since the env values are not expanded,
the last rule never matches, and user/val2 link is never created. The
above generated (sdaz is the last device found):

[elm3a49 ~]$ ls -l /dev/user
total 0
lrwxrwxrwx  1 root root 7 Nov  1 14:18 bar -> ../sdaz
lrwxrwxrwx  1 root root 6 Nov  1 14:18 show-val1-somevalue -> ../sdm
lrwxrwxrwx  1 root root 6 Nov  1 14:18 show-val2-somevalue -> ../sdm
lrwxrwxrwx  1 root root 6 Nov  1 14:18 val1 -> ../sdm

-- Patrick Mansfield


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Kay Sievers]

On Tue, Nov 01, 2005 at 02:53:57PM -0800, Patrick Mansfield wrote:
> Per posts and an accepted patch on dm-devel about dm multipath user
> friendly names:
> 
> https://www.redhat.com/archives/dm-devel/2005-October/msg00004.html
> https://www.redhat.com/archives/dm-devel/2005-October/msg00067.html
> 
> But the above is a dm multipath only solution.
> 
> It's a good idea to allow user specified names on top of the
> /dev/disk/by-* device names. Though dm likely needs a dm_id in order to
> support the method outlined here.
> 
> If we could set and compare environment variables

Sure we can do that with ENV. '=' sets, '=' compares.

> or compare SYMLINK,

How would we compare the list of sysmlinks?
True, if on of them matches?

> separate rules file (doesn't have to be separate, just seems like a good
> idea) could be used to add symlinks to user specified names.

All the persistent symlinks are composed from variables still available
to match anytime later to add more links.

> i.e. move udev_rules.c:apply_format() into udev_utils.c, and call it
> before comparison as well as before (AFAIUI) generating names, though I
> somehow doubt the change is that simple.
> 
> Then, we could have rules like:
> 
> KERNEL="sd*[!0-9]|sr*|dasd*[!0-9]", ENV{ID_SERIAL}="?*", ENV{ID_FULL_PATH}="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
> ENV{ID_FULL_PATH}="?*", SYMLINK+="$env{ID_FULL_PATH}"

Hmm, why this indirection? Can't you just use ID_SERIAL and ID_BUS in
the second rule again?

> And for each device that we want to give a user specified name, use (would
> also need partition specific rules):
> 
> ENV{ID_FULL_PATH}="disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849" SYMLINK+="media-files"
> 
> And similar for the other disk/by-* methods.
>
> Any comments on the above? 
>
> Is my rule just wrong, or is there a better method?
> 
> Running with udev 069 on FC rawhide, with these rules:
> 
> SYMLINK="*foo*" SYMLINK+="user/bar"

SYMLINK lists can't be matched until now.

> KERNEL="sdm" ENV{VAL1}="somevalue"
> KERNEL="sdm" ENV{VAL2}="$env{VAL1}"

The value does not get expanded at the time you assign it, so the later compare
will look like:
  'somevalue' = '$env{VAL1}'

which does not match.

> KERNEL="sdm" SYMLINK+="user/show-val1-$env{VAL1}"
> KERNEL="sdm" SYMLINK+="user/show-val2-$env{VAL2}"
> 
> ENV{VAL1}="somevalue" SYMLINK+="user/val1"
> ENV{VAL2}="somevalue" SYMLINK+="user/val2"
> 
> Do not work as might be expected: since the env values are not expanded,
> the last rule never matches, and user/val2 link is never created. The
> above generated (sdaz is the last device found):
> 
> [elm3a49 ~]$ ls -l /dev/user
> total 0
> lrwxrwxrwx  1 root root 7 Nov  1 14:18 bar -> ../sdaz
> lrwxrwxrwx  1 root root 6 Nov  1 14:18 show-val1-somevalue -> ../sdm
> lrwxrwxrwx  1 root root 6 Nov  1 14:18 show-val2-somevalue -> ../sdm
> lrwxrwxrwx  1 root root 6 Nov  1 14:18 val1 -> ../sdm

Thanks,
Kay


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Patrick Mansfield]

On Wed, Nov 02, 2005 at 01:05:31AM +0100, Kay Sievers wrote:
> On Tue, Nov 01, 2005 at 02:53:57PM -0800, Patrick Mansfield wrote:

> > If we could set and compare environment variables
> 
> Sure we can do that with ENV. '=' sets, '=' compares.
> 
> > or compare SYMLINK,
> 
> How would we compare the list of sysmlinks?
> True, if on of them matches?

Yes, perhaps:

SYMLINK = "* disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849 *" SYMLINK+="user/name"

I like the above better than using other env variables, it is easier to
read.

> > separate rules file (doesn't have to be separate, just seems like a good
> > idea) could be used to add symlinks to user specified names.
> 
> All the persistent symlinks are composed from variables still available
> to match anytime later to add more links.
> 
> > i.e. move udev_rules.c:apply_format() into udev_utils.c, and call it
> > before comparison as well as before (AFAIUI) generating names, though I
> > somehow doubt the change is that simple.
> > 
> > Then, we could have rules like:
> > 
> > KERNEL="sd*[!0-9]|sr*|dasd*[!0-9]", ENV{ID_SERIAL}="?*", ENV{ID_FULL_PATH}="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
> > ENV{ID_FULL_PATH}="?*", SYMLINK+="$env{ID_FULL_PATH}"
> 
> Hmm, why this indirection? Can't you just use ID_SERIAL and ID_BUS in
> the second rule again?

Yes, but it is simpler to use one variable, for this and in the by-id
partitions, rather than use "disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}" in
multiple places (it is used in two places today, my scheme would mean two
more references).

But it still would not match, per the issue below, right?

> > Running with udev 069 on FC rawhide, with these rules:
> > 
> > SYMLINK="*foo*" SYMLINK+="user/bar"
> 
> SYMLINK lists can't be matched until now.

You mean it is possible with current udev?

> > KERNEL="sdm" ENV{VAL1}="somevalue"
> > KERNEL="sdm" ENV{VAL2}="$env{VAL1}"
> 
> The value does not get expanded at the time you assign it, so the later compare
> will look like:
>   'somevalue' = '$env{VAL1}'
> 
> which does not match.

Right ... so should udev be changed to avoid that problem?

-- Patrick Mansfield


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Kay Sievers]

On Tue, Nov 01, 2005 at 04:35:31PM -0800, Patrick Mansfield wrote:
> On Wed, Nov 02, 2005 at 01:05:31AM +0100, Kay Sievers wrote:
> > On Tue, Nov 01, 2005 at 02:53:57PM -0800, Patrick Mansfield wrote:
> 
> > > If we could set and compare environment variables
> > 
> > Sure we can do that with ENV. '=' sets, '=' compares.
> > 
> > > or compare SYMLINK,
> > 
> > How would we compare the list of sysmlinks?
> > True, if on of them matches?
> 
> Yes, perhaps:
> 
> SYMLINK = "* disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849 *" SYMLINK+="user/name"
> 
> I like the above better than using other env variables, it is easier to
> read.
> 
> > > separate rules file (doesn't have to be separate, just seems like a good
> > > idea) could be used to add symlinks to user specified names.
> > 
> > All the persistent symlinks are composed from variables still available
> > to match anytime later to add more links.
> > 
> > > i.e. move udev_rules.c:apply_format() into udev_utils.c, and call it
> > > before comparison as well as before (AFAIUI) generating names, though I
> > > somehow doubt the change is that simple.
> > > 
> > > Then, we could have rules like:
> > > 
> > > KERNEL="sd*[!0-9]|sr*|dasd*[!0-9]", ENV{ID_SERIAL}="?*", ENV{ID_FULL_PATH}="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
> > > ENV{ID_FULL_PATH}="?*", SYMLINK+="$env{ID_FULL_PATH}"
> > 
> > Hmm, why this indirection? Can't you just use ID_SERIAL and ID_BUS in
> > the second rule again?
> 
> Yes, but it is simpler to use one variable, for this and in the by-id
> partitions, rather than use "disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}" in
> multiple places (it is used in two places today, my scheme would mean two
> more references).

Why do you want to match on the whole string which is a result from another
rule hidden in a symlink array? The whole idea of IMPORT the ID_* keys is to
have these variables in the environment to compose device names. Think
of them as a "poor mans product database".

The only interesting parts of the symlink string you want to match are the
two values which are conveniently available in the environment for exactly
that reason. :)

> But it still would not match, per the issue below, right?

Right, it wouldn't work.

You want this:
  ENV{ID_FULL_PATH}="disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849" SYMLINK+="media-files"

but why don't you just do:
  ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="media-files"

The second already works, is independent from all other rules and I think
is simpler.

> > > Running with udev 069 on FC rawhide, with these rules:
> > > 
> > > SYMLINK="*foo*" SYMLINK+="user/bar"
> > 
> > SYMLINK lists can't be matched until now.
> 
> You mean it is possible with current udev?

No, there is no change in the current udev.

> > > KERNEL="sdm" ENV{VAL1}="somevalue"
> > > KERNEL="sdm" ENV{VAL2}="$env{VAL1}"
> > 
> > The value does not get expanded at the time you assign it, so the later compare
> > will look like:
> >   'somevalue' = '$env{VAL1}'
> > 
> > which does not match.
> 
> Right ... so should udev be changed to avoid that problem?

Sure, we can, but I fear that this will end in something like a shell. :)
And I've seen people storing REMOVE hooks in the database that get
expanded at remove time and not before they are stored...

Kay


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Patrick Mansfield]

On Wed, Nov 02, 2005 at 02:06:15AM +0100, Kay Sievers wrote:
> On Tue, Nov 01, 2005 at 04:35:31PM -0800, Patrick Mansfield wrote:

> > But it still would not match, per the issue below, right?
> 
> Right, it wouldn't work.
> 
> You want this:
>   ENV{ID_FULL_PATH}="disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849" SYMLINK+="media-files"
> 
> but why don't you just do:
>   ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="media-files"
> 
> The second already works, is independent from all other rules and I think
> is simpler.

Yes, I just disagree with it being simpler for all busses/devices.

I was thinking of the sys admin or a tool looking at the current
/dev/disk/by-* and adding rule(s) based on those values to a udev rule
file.

And is there a way to rename or add /dev entries without removing and
adding back a device?


Using ID_BUS and ID_SERIAL via the following lines like this works:

KERNEL="sd*[!0-9]", ENV{ID_BUS}="scsi" ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="user/databaseA"
KERNEL="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="user/databaseA-part%n"

KERNEL="sd*[!0-9]", ENV{ID_BUS}="scsi" ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f55", SYMLINK+="user/databaseB"
KERNEL="sd*[0-9]", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f55", SYMLINK+="user/databaseB-part%n"

Adding the devices then creates:

[root@elm3a49 rules.d]# ls -l /dev/user
total 0
lrwxrwxrwx  1 root root 6 Nov  1 17:46 databaseA -> ../sdm
lrwxrwxrwx  1 root root 7 Nov  1 17:47 databaseA-part1 -> ../sdm1
lrwxrwxrwx  1 root root 6 Nov  1 17:46 databaseB -> ../sdi
lrwxrwxrwx  1 root root 7 Nov  1 17:46 databaseB-part1 -> ../sdi1
lrwxrwxrwx  1 root root 7 Nov  1 17:46 databaseB-part2 -> ../sdi2

-- Patrick Mansfield


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Kay Sievers]

On Tue, Nov 01, 2005 at 06:01:56PM -0800, Patrick Mansfield wrote:
> On Wed, Nov 02, 2005 at 02:06:15AM +0100, Kay Sievers wrote:
> > On Tue, Nov 01, 2005 at 04:35:31PM -0800, Patrick Mansfield wrote:
> 
> > > But it still would not match, per the issue below, right?
> > 
> > Right, it wouldn't work.
> > 
> > You want this:
> >   ENV{ID_FULL_PATH}="disk/by-id/scsi-360a98000686f68656c6e7a416f4b6849" SYMLINK+="media-files"
> > 
> > but why don't you just do:
> >   ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="media-files"
> > 
> > The second already works, is independent from all other rules and I think
> > is simpler.
> 
> Yes, I just disagree with it being simpler for all busses/devices.
> 
> I was thinking of the sys admin or a tool looking at the current
> /dev/disk/by-* and adding rule(s) based on those values to a udev rule
> file.

Sure, that may be easier.
But such a tool is only useful if the devices are already present on the
system, right? Then you can read all current available ID_* variables from
the udev database and compose a nice rule from it. :)

> And is there a way to rename or add /dev entries without removing and
> adding back a device?

You can run udevstart again, if its not configured to do some weird
stuff.

The current devel kernel has a "uevent" file, which triggers the
hotplug event again, this could be used to create additional configured
links.

Also:
  ACTION­d DEVPATH=/block/sdm /sbin/udev block
would do it.

Or do you mean adding a link temporarily, so that it get tracked and
removed when the device goes away?

> Using ID_BUS and ID_SERIAL via the following lines like this works:
> 
> KERNEL="sd*[!0-9]", ENV{ID_BUS}="scsi" ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="user/databaseA"
> KERNEL="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b6849", SYMLINK+="user/databaseA-part%n"
> 
> KERNEL="sd*[!0-9]", ENV{ID_BUS}="scsi" ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f55", SYMLINK+="user/databaseB"
> KERNEL="sd*[0-9]", ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f55", SYMLINK+="user/databaseB-part%n"
> 
> Adding the devices then creates:
> 
> [root@elm3a49 rules.d]# ls -l /dev/user
> total 0
> lrwxrwxrwx  1 root root 6 Nov  1 17:46 databaseA -> ../sdm
> lrwxrwxrwx  1 root root 7 Nov  1 17:47 databaseA-part1 -> ../sdm1
> lrwxrwxrwx  1 root root 6 Nov  1 17:46 databaseB -> ../sdi
> lrwxrwxrwx  1 root root 7 Nov  1 17:46 databaseB-part1 -> ../sdi1
> lrwxrwxrwx  1 root root 7 Nov  1 17:46 databaseB-part2 -> ../sdi2

If you get a buch of these rules, it may be easier to enclose them like this:

  KERNEL!="sd*[!0-9]|dasd*[0-9]", GOTO="custom_end"
  ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f55", SYMLINK+="user/databaseA-part%n"
  ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f56", SYMLINK+="user/databaseB-part%n"
  ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f57", SYMLINK+="user/databaseC-part%n"
  ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f58", SYMLINK+="user/databaseE-part%n"
  ENV{ID_SERIAL}="360a98000686f68656c6e7a416f4b2f59", SYMLINK+="user/databaseF-part%n"
  LABEL="custom_end"

Kay


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Patrick Mansfield]

On Wed, Nov 02, 2005 at 03:53:45AM +0100, Kay Sievers wrote:

> Sure, that may be easier.
> But such a tool is only useful if the devices are already present on the
> system, right? Then you can read all current available ID_* variables from
> the udev database and compose a nice rule from it. :)

Yes looks like that can work (again I *was* thinking symlinks, and not
env variables) .

> > And is there a way to rename or add /dev entries without removing and
> > adding back a device?
> 
> You can run udevstart again, if its not configured to do some weird
> stuff.

That is rather slow, and didn't removing links (like a rename would want).

> The current devel kernel has a "uevent" file, which triggers the
> hotplug event again, this could be used to create additional configured
> links.
> 
> Also:
>   ACTION­d DEVPATH=/block/sdm /sbin/udev block
> would do it.

Those don't remove links either.

> Or do you mean adding a link temporarily, so that it get tracked and
> removed when the device goes away?

No.

Thanks,

-- Patrick Mansfield


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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 user specified or human readable /dev names

[Kay Sievers]

On Wed, Nov 02, 2005 at 07:30:18AM -0800, Patrick Mansfield wrote:
> On Wed, Nov 02, 2005 at 03:53:45AM +0100, Kay Sievers wrote:
> 
> > Sure, that may be easier.
> > But such a tool is only useful if the devices are already present on the
> > system, right? Then you can read all current available ID_* variables from
> > the udev database and compose a nice rule from it. :)
> 
> Yes looks like that can work (again I *was* thinking symlinks, and not
> env variables) .

If that does not work well, let me know and we can make the needed changes.

> > > And is there a way to rename or add /dev entries without removing and
> > > adding back a device?
> > 
> > You can run udevstart again, if its not configured to do some weird
> > stuff.
> 
> That is rather slow, and didn't removing links (like a rename would want).

Sure.

> > The current devel kernel has a "uevent" file, which triggers the
> > hotplug event again, this could be used to create additional configured
> > links.
> > 
> > Also:
> >   ACTION­d DEVPATH=/block/sdm /sbin/udev block
> > would do it.
> 
> Those don't remove links either.

  ACTION=remove DEVPATH=/block/sdm /sbin/udev block
  ACTION­d DEVPATH=/block/sdm /sbin/udev block

But sure, we may want to add something smarter than this, cause the
node will disappear for a short time and the inode number of the node
will change which isn't nice if you want to recreate symlinks only.

We will need something like this anyway, cause if you change a volume label
of a filesystem, you have a similar problem.

> > Or do you mean adding a link temporarily, so that it get tracked and
> > removed when the device goes away?
> 
> No.

Ah bad, that's what I like to have for a pam_console/udev solution. :)

Kay


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
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