Re: [Patch] udev: new dasd_id tool

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

On Tue, 2006-11-28 at 16:29 +0100, Volker Sameske wrote:
> > No that's not what I mean, /sys is even hard-coded in udev, only
> > overwritable for the test-suite. But /sys/block may live
> > in /sys/subsystem/block and all that stuff that is queued at the moment
> > for sysfs changes. There will be backwards compat-links in sysfs for
> > existing apps to work, but in the udev tree, nothing new is accepted,
> > that relies on the compat-links.
> 
> Okay, now I see your point. I can change that.

Fine.

> > Oh, then your tool probably doesn't want to hide in /lib/udev/ too,
> > right? 
> 
> Right

The current multipath already uses the current dasd_id in /lib/udev?

> > The udev tarball does not want to carry around generic or
> > generally useful tools, only things which are private to udev and can be
> > changed to our needs without really caring about possible other users.
>  
> > It may make sense, to remove the current tool from the udev tree, so
> > this udev version can just rely on the sysfs-value to be present.
> 
> No, since the uid sysfs attribute is new and not part of older 
> distributions. Without that uid attribute we have to open the 
> device to read the not really unique volume label. So dasd_id 
> still needs to be part of udev.

Well, we usually don't care about backwards compat in that direction. A
udev version can simply require a minimal kernel version, and this
should be fine.

But how do we handle people already using the current persistent links?
Your new tool creates different names for the same devices on recent
kernels, right?

> > Your new tool would go into its own package, from a distribution point
> > of view. Packagers can still use and integrate the new tool into
> > udev-rules, if they really feel the need for that kind of compatibility,
> > which I don't expect for udev's need.
> 
> Would be one approach. But if this tool goes into the multipath package 
> we had an udev dependency on the mp-tools package. Since every Linux user 
> uses udev and only a subset uses the multipath package we would force 
> some users to install mp-tool, even if they don't need it. The other
> way around would be better.
> 
> > Does that make sense?
> 
> I understand your point. But what you suggest is to have two different 
> tools for udev and mp-tools wich implement the same functionality. 
> That's something I would like to avoid.

Right, that's always good to avoid.

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