Re: The Next Generation

[Roman Kagan <rkagan@mail.ru>]

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_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