From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Kagan Date: Thu, 24 Feb 2005 17:51:41 +0000 Subject: Re: The Next Generation Message-Id: <20050224175140.GA2366@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 04:57:45PM +0000, Kay Sievers wrote: > Most of the new systems out there will never work without udev again, Right, but there may be reasons for people to stay with static /dev, and it would be a pity not have the new cool hotplug there. > 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}". > >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. > 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. > > (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*. 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