Re: udev PROGRAM key and the device chain walk

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

On Mon, Feb 14, 2005 at 05:07:33PM -0800, Greg KH wrote:
> On Tue, Feb 15, 2005 at 01:55:47AM +0100, Kay Sievers wrote:
> > On Mon, Feb 14, 2005 at 11:19:09AM -0800, Greg KH wrote:
> > > On Sun, Feb 13, 2005 at 03:15:25PM +0100, Kay Sievers wrote:
> > > > While we try to match rule keys against a devices sysfs representaion,
> > > > we need to follow the physical device and walk up the device chain up to
> > > > the root device and match our rule against every device found.
> > > > 
> > > > While this is necessary to match the SYSFS and BUS keys, it has the
> > > > _very_ bad side effect, that a PROGRAM may be executed several times. In
> > > > my test setup, I've seen five executions of a callout to match one single
> > > > rule.
> > > 
> > > Is this because the rule was written badly?
> > > 
> > > > The only reason to do this, is the match with a callout against a sysfs
> > > > attribute of one of the physical devices along the chain by using
> > > > the %s{<attr>} key.
> > > > I don't think that this is really needed and I want to change the namedev
> > > > logic to execute the PROGRAM key only once per rule. It will be still
> > > > possible to pass the %s{<attr>} to the callout, but it will only happen
> > > > at the device itself and not follow the chain to the root device. If
> > > > such a thing is ever needed, the callout can do it itself and not rely on
> > > > udev to execute it several times.
> > > > 
> > > > Any objections, or I will change that to speed things up.
> > > 
> > > Again, is this really needed, or do we just blame it on a badly written
> > > rule?
> > 
> > I wouldn't call it badly written. If the PROGRAM execution returns
> > nonzero, namedev may execute the program again for every device in /sys/devices.
> > That is pretty useless as the parameters for the execution are the same for
> > every call, except you pass %s{sysfsfile} to it.
> 
> Ok, I mean we shouldn't have a rule that is only PROGRAM.  It should
> have something else in it, like BUS, or SUBSYSTEM, or a sysfs file match
> to prevent this from happening, right?

Sure, and fortunately most of them are doing so. I just want to fix the behavior if
these keys are _not_ given. If one of these keys is present, nothing changes!

> > And yeah, a rule which passes a %s{sysfsfile} content from a device somewhere
> > in the physical device chain is a "badly" written rule. :)
> 
> You mean as a paramater?  Heh, that seems like a fun hack to make the
> external program logic simpler :)
> 
> I don't think we should break that, do you?

No, sure, this will still work as expected. But not for an arbitrary device
in the physical devices path which sounds crazy anyway. :)

To turn around the question: What functionality do you want to keep here?
A rule with only the PROGRAM key, which walks up the physical devices path
and executes the program multiple times and doesn't stop on nonzero exit?

Thanks,
Kay


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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