udev autoruler for persistent device naming?

udev autoruler for persistent device naming?

[Kay Sievers]

I need to ask for your comment on an idea:

With udev, anybody capable reading documentation and execute commands in
a shell, should be able to uniquely name the connected devices.
But if you don't have a rule for every device, you stick with the old
problem, that the device name depends on the order of discover. To use
persistent names for udev, we may plug a small program as a udev callout
in udev.rules for devices not catched by any other rule:

  KERNEL="sd*[1-4]", PROGRAM="/sbin/udev_autoruler", NAME="%c", USER="$local"

this 'udev_autoruler' thing examines the device, guesses what it looks
like (like kudzu) and creates a rule with unique device attributes, like the
serial number and the unique NAME for the node.
The CALLOUT will place this rule in a file in /etc/udev/rules.d/ The same
name is returned to udev to actually name the node. If the device is reconnected
anytime later, this new rule will match it and assignes the same name forever.


Hmm, I don't know, if I really like the idea myself :)
But, what do you think?

thanks,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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 autoruler for persistent device naming?

[Martin Schwenke]

>>>>> "Kay" = Kay Sievers <kay.sievers@vrfy.org> writes:

    Kay> [...]  To use persistent names for udev, we may plug a small
    Kay> program as a udev callout in udev.rules for devices not
    Kay> catched by any other rule:

    Kay>   KERNEL="sd*[1-4]", PROGRAM="/sbin/udev_autoruler", NAME="%c", USER="$local"

    Kay> this 'udev_autoruler' thing examines the device, guesses what
    Kay> it looks like (like kudzu) and creates a rule with unique
    Kay> device attributes, like the serial number and the unique NAME
    Kay> for the node.

    Kay> The CALLOUT will place this rule in a file in
    Kay> /etc/udev/rules.d/   [...]

This is similar to my proposal (posted to the device_naming list a
week or so ago), but I don't advocate putting the mappings back into
udev's rule set.  OK, the above is a specific case of my proposal...
:-)

My reasoning for not generally wanting to put the mappings in as udev
rules is that a callout can base its naming on things that udev can't
easily see.  Therefore, in general, you can't guarantee that you can
express the mapping as a udev rule.  If you didn't see my proposal,
I'm advocating a callout that utilises its own mapping between
arbitrary VPD (Vital Product Data) elements (so you could go down to
firmware version if you had a reason :-) and names.  It doesn't have
to use its own mapping database - it could create udev rules
instead...

Using VPD-name mappings for persistence also means that you could
implement something similar to the chassis/location thing that someone
posted a while ago (sorry, didn't save it).  Reasonable names,
generated in sequential order (like "disk01") could be associated with
arbitrarily complex physical location information, and dished up next
time the disk reappears, even if the probe order changes... or, wait
for it...  even if the disk in question is physically exchanged for a
new one - that's what you'd want if you preferred slot-based naming.

What I'm advocating is a nice general framework for persistent naming.
It probably has more overheads than using specific callouts for
specific types of devices, but I think it is worth pursuing.

I'm not seeing much interest.  However, once I've got a convenient way
of accessing VPD elements in my VPD database, I can do various sample
implementations that will each be a few lines of shell script.  So it
is worth implementing and testing on some reasonable systems.

The obvious advantage of your proposal is that you save a callout when
the device has been seen before.  When it is applicable, I think it is
an excellent idea.  When I have the framework, I'll see if I can
implement your idea using mine...  :-)

peace & happiness,
martin



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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 autoruler for persistent device naming?

[Kay Sievers]

On Thu, Apr 15, 2004 at 04:43:56PM +1000, Martin Schwenke wrote:
> >>>>> "Kay" = Kay Sievers <kay.sievers@vrfy.org> writes:
> 
>     Kay> [...]  To use persistent names for udev, we may plug a small
>     Kay> program as a udev callout in udev.rules for devices not
>     Kay> catched by any other rule:
> 
>     Kay>   KERNEL="sd*[1-4]", PROGRAM="/sbin/udev_autoruler", NAME="%c", USER="$local"
> 
>     Kay> this 'udev_autoruler' thing examines the device, guesses what
>     Kay> it looks like (like kudzu) and creates a rule with unique
>     Kay> device attributes, like the serial number and the unique NAME
>     Kay> for the node.
> 
>     Kay> The CALLOUT will place this rule in a file in
>     Kay> /etc/udev/rules.d/   [...]
> 
> This is similar to my proposal (posted to the device_naming list a
> week or so ago), but I don't advocate putting the mappings back into
> udev's rule set.  OK, the above is a specific case of my proposal...
> :-)
> 
> My reasoning for not generally wanting to put the mappings in as udev
> rules is that a callout can base its naming on things that udev can't
> easily see.  Therefore, in general, you can't guarantee that you can
> express the mapping as a udev rule.  If you didn't see my proposal,
> I'm advocating a callout that utilises its own mapping between
> arbitrary VPD (Vital Product Data) elements (so you could go down to
> firmware version if you had a reason :-) and names.  It doesn't have
> to use its own mapping database - it could create udev rules
> instead...
> 
> Using VPD-name mappings for persistence also means that you could
> implement something similar to the chassis/location thing that someone
> posted a while ago (sorry, didn't save it).  Reasonable names,
> generated in sequential order (like "disk01") could be associated with
> arbitrarily complex physical location information, and dished up next
> time the disk reappears, even if the probe order changes... or, wait
> for it...  even if the disk in question is physically exchanged for a
> new one - that's what you'd want if you preferred slot-based naming.
> 
> What I'm advocating is a nice general framework for persistent naming.
> It probably has more overheads than using specific callouts for
> specific types of devices, but I think it is worth pursuing.
> 
> I'm not seeing much interest.  However, once I've got a convenient way
> of accessing VPD elements in my VPD database, I can do various sample
> implementations that will each be a few lines of shell script.  So it
> is worth implementing and testing on some reasonable systems.
> 
> The obvious advantage of your proposal is that you save a callout when
> the device has been seen before.  When it is applicable, I think it is
> an excellent idea.  When I have the framework, I'll see if I can
> implement your idea using mine...  :-)

Sounds interesting, is there anything publicly available about the VPD
framework?

thanks,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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 autoruler for persistent device naming?

[Martin Schwenke]

>>>>> "Kay" = Kay Sievers <kay.sievers@vrfy.org> writes:

    >> What I'm advocating is a nice general framework for persistent
    >> naming.  It probably has more overheads than using specific
    >> callouts for specific types of devices, but I think it is worth
    >> pursuing.

    Kay> Sounds interesting, is there anything publicly available
    Kay> about the VPD framework?

Not a lot, but that's not intentional...

The lsvpd package is part of the linux-diag SourceForge.net project.
It started off reasonably pSeries (IBM PowerPC) centric, but I've
generalised it a lot using sysfs.  The latest released version 0.11.5
isn't incredibly "hotplug/naming ready".  The main problem is that
this version depends on having a name before getting the VPD.  I've
spent the last 3 weeks making accesses and updates all bus-orientated
(which would make them usable from hotplug), and adding in a separate
name processing step.

I'm nearly at the point where I can:

1. Get VPD (sans name).
2. Get a name (from somewhere - the udev kernel name will do for
   starters :-).
3. Put the name in the VPD record (for diagnostic purposes).

I'll probably release 0.12.0 next week and try out some sample naming
stuff.  I still need to do reorganise the way I store VPD and come up
with an API for accessing individual fields... and do a bit of
testing.

At the moment lsvpd is mostly bash scripts, along with some helpers
written in C.  Using bash may kill it on large systems, but I'd like
to get this version working and then reconsider my options.

peace & happiness,
martin



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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