From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 24 Feb 2005 19:37:26 +0000 Subject: Re: The Next Generation Message-Id: <1109273846.6894.117.camel@localhost.localdomain> 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, 2005-02-24 at 20:51 +0300, Roman Kagan wrote: >On Thu, Feb 24, 2005 at 04:57:45PM +0000, Kay Sievers wrote: >> As Marco already pointed out, it seems a bit confusing to stop the rule >> processing if a NAME key is found, so no later HOTPLUG, SYMLINK key is >> added to the list. > >Is anything wrong with having multiple NAME? Definitely not with device >nodes - you can have as many device nodes with the same major/minor >(e.g. pointing to the same physical device) as you wish, and that was >always so in Unix. There may be certain problems with net devices, but >this sort of rules is typically created manually by sysadmin, not by >postinstall scripts of various packages, so conflicting rules here would >be his sole responsibility. > >Just let me make my point clear: in a rule you have keys to match the >device against, and actions. Currently known actions are NAME, SYMLINK, >and the proposed HOTPLUG. On every hotplug event you go through the >list of rules in the order given in the configuration, and execute >actions in the rules whose keys match. I don't see why NAME should be >treated differently from HOTPLUG (except it'd be handled internally by >udev). Basically NAME=name is equivalent to HOTPLUG="udev_mknod name >SYSFS{dev}". 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. >> >2) the multiplexer shouldn't touch sysfs unless explicitly or implicitly >> > requested to. E.g. some of the keys in udev can be deduced from the >> > environment variables passed to hotplug by the kernel. >> >> The problem with the hotplug environment variables is backwards >> compatibility. If we require a specific kernel version at some time, we >> may do that - if it really helps. > >You're talking of the New Generation, aren't you :) ? Still certain >keys can be deduced from the variables you already rely upon, like >DEVPATH, etc. We already read DEVPATH from the env, we have no other option. :) 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. >> And with the new libsysfs no attribute which is not explicitly >> requested, will be openend. > >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. >> > (BTW a generic ENV{variable} key would be useful too.) >> >> Yes, this will be nice, if we handle /sys/devices with rules. > >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. 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 sure, it is useful if would handle /sys/devices, cause we may need to match against keys from the bus drivers. 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