Re: udev autoruler for persistent device naming?

[Kay Sievers <kay.sievers@vrfy.org>]

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