Re: The Next Generation

[Kay Sievers <kay.sievers@vrfy.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_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