udev PROGRAM key and the device chain walk

udev PROGRAM key and the device chain walk

[Kay Sievers]

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.

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.

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

Re: udev PROGRAM key and the device chain walk

[Greg KH]

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?

thanks,

greg k-h


-------------------------------------------------------
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

Re: udev PROGRAM key and the device chain walk

[Kay Sievers]

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.

And yeah, a rule which passes a %s{sysfsfile} content from a device somewhere
in the physical device chain is a "badly" written rule. :)

I think we should fix that.

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

Re: udev PROGRAM key and the device chain walk

[Greg KH]

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?

> 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?

thanks,

greg k-h


-------------------------------------------------------
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

Re: udev PROGRAM key and the device chain walk

[Kay Sievers]

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

Re: udev PROGRAM key and the device chain walk

[Greg KH]

On Tue, Feb 15, 2005 at 02:47:43AM +0100, Kay Sievers wrote:
> 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?

I guess I don't see a real problem here that needs to be fixed.  If a
rule is dumb enough to want to run a program on every device in the
chain, let it :)

thanks,

greg k-h


-------------------------------------------------------
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