From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 15 Feb 2005 01:47:43 +0000 Subject: Re: udev PROGRAM key and the device chain walk Message-Id: <20050215014743.GA29550@vrfy.org> List-Id: References: <20050213141525.GA22956@vrfy.org> In-Reply-To: <20050213141525.GA22956@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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{} 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{} 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_id396&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