From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Kagan Date: Thu, 24 Feb 2005 20:39:50 +0000 Subject: Re: The Next Generation Message-Id: <20050224203950.GD2366@katya> List-Id: References: <20050217190941.GA1561@vrfy.org> In-Reply-To: <20050217190941.GA1561@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, Feb 24, 2005 at 08:37:26PM +0100, Kay Sievers wrote: > Hmm, I don't see the need for multiple device nodes now. We have > symlinks for that exact reason and it is much easier to manage the > permissions for a device if you have only one special file. I didn't mean anybody needed multiple device nodes per se. But AFAICS the only reason the rule processing stops on the first NAME action is the danger of enountering another NAME rule which would match; what I'm trying to say is that there's no particular problem with multiple NAME rules which can match the same device, and then all actions including NAME, SYMLINK and HOTPLUG can be handled uniformly. > We already read DEVPATH from the env, we have no other option. :) Right, but $DEVPATH already contains some information about topology, etc. $PHYS* contain even more. SUBSYSTEM is passed as an argument. For many HOTPLUG and NAME actions the information obtained from the environment would suffice. But that would mean that they could be run without waiting for the sysfs files to appear, and reading their contents. > We need to run in the udvstart case where no env is available and > possibly walk up the chain of devices in /sys/devices to find a match. I > don't expect any significant improvement here. The hotplug multiplexer should be as lightweight as possible. IMHO this means that it should be constrained to the rule-based multiplexer and optionally a component to execute NAME and SYMLINK actions. What's in udevstart now IMHO belongs in coldplug; the latter should reproduce exactly the environment provided to the hotplug callout by the kernel. > >I think it can make sense to internally reorder the keys in the rule, to > >make the keys which depend on sysfs be matched last (well, maybe still > >before PROGRAM keys), so that the most lightweight checks happen first, > >and the more heavyweight are skipped when the rule is already known not > >to match. > > The way the rule is parsed is independent of the order of match from the > first version of udev on. Well, if people depend on the order keys in the rule are matched (I don't see how, but still) then at least they can be recommended to put the more lightweight checks first. The match against an environment variable costs nothing; the match against the contents of a sysfs file costs a lot (waiting + file operations). > >I can even imagine most existing keys to be transformed into either > >ENV{} or SYSFS{}. E.g. PLACE, ID, DRIVER can be obtained from $PHYS*. > > I like the explicit keys much more. I meant using environment internally, if possible. E.g. if (getenv("PHYSDEVPATH")) if (match PLACE against PHYSDEVPATH) goto matched; if (match PLACE against sysfs) goto matched; > And no, some of them have a special > way to match and need to work on any device along the chain of devices > in /sys/devices. But some don't; I believe quite a few CPU cycles can be saved then. Cheers, Roman. ------------------------------------------------------- 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