From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 15 Apr 2004 12:20:17 +0000 Subject: Re: udev autoruler for persistent device naming? Message-Id: <20040415122017.GA10891@vrfy.org> List-Id: References: <20040415002504.GB8818@vrfy.org> In-Reply-To: <20040415002504.GB8818@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Thu, Apr 15, 2004 at 04:43:56PM +1000, Martin Schwenke wrote: > >>>>> "Kay" = Kay Sievers 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_id70&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