Re: incomplete doc questions

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, Jul 29, 2005 at 04:36:28PM +0200, elkner@linofee.org wrote:
> Hi,
> 
> I#m just starting to get into touch with udev - sounds amazing (at least
> from the docs I've read ;-)). So I installed the 12.6.3 vanilla kernel as
> well as udev-064 on a (in general slackware like) machine. Since I never
> used hotplug stuff, there is no hotplug stuff at all on any of the machines
> in my admin territory (but since more and more usb and firewire stuff comes
> in, I think, udev should/will do the job ...).
> 
> But unfortunately I miss some tiny details in the docs (incl. manpages),
> which are essential to be able to get udev work as I expect it.
> 
> 1) Setup:
>    How should udev be activated (via /proc/sys/kernel/hotplug)?
>    As /sbin/udev (as the README, LinuxHelp_UDEVPrimer says) or
>    as /sbin/udevsend ? From reading the man pages, the latter would 
>    make more sense to me, since udevsend uses udevd for ordering
>    the events, and than udevd invokes udev (If I understood this right).
>    Hmmm, but wait, can you show/construct a scenario, why/where it is
>    important to have the events ordered ?

I completely depends on your requirements and how your distro layouts
hotplug handling. The usual setup is /sbin/udevsend. Latest versions of
udev can use netlink and the forked helper can be disabled completely,
but the input-layer is broken and you need a kernel patch for it to work
if you depend on input module-loading.

There is no general rule ath the meoment how to do it. You may just look how
other distros are doing it. We are in the middle of a transition from
agent/directory-layout/shell-script based hotplug to udev rule-based hotplug,
so you will need to find out yourself how far you want to go. :)

Event order matters if you have add/remove events for the same device and
"add" is higher in the sequence but "remove" is the last one that runs. See the
problem? :)

> 2) Rule Matching - who wins:
>    writing_udev_rules says "udev will stop processing rules as soon as it
>    finds a matching rule in a file for the new item of hardware that has
>    been detected" (i.e. first match wins).
>    The manpage (actually man page is the source I consider to have the last
>    word) says "If all keys are matching, the rule will be  applied and the
>    name is used to name the device file or the network interface." (i.e.
>    every match wins). 

NAME is only applied with the first matching rule.

>    But in the RELEASE-NOTES I found "All rules are applied now, but only
>    the first matching rule with a NAME-key will be applied. All later rules
>    with NAME-key are completely ignored." (i.e. only the first matching
>    rule wins, which has a NAME="..." part).

All later rules will get applied too, but only if they don't have NAME.

>    Looking at the examples in etc/* none of the statements above can be
>    true (otherwise the example have at least a lot of useless rules). So
>    I guess:
> 
>    Every matching rule, which does not assign a value to the NAME key or
>    removes the value from the NAME key wins as well as the first matching
>    rule, which assigns a value to the NAME key. And thus, all later
>    matching rules, which want to assign a second time a value to the NAME
>    key, are completely ignored. E.g.:
>    KERNEL="hdc",      NAME="%k", GROUP="disk"
>    KERNEL="hdc",      NAME="%k", SYMLINK+="cdrom0"
>    would create something like
>    "brw-r-----  1 root disk 22, 0 May  8  1995 /dev/hdc"
>    but NOT a symlink from /dev/cdrom0 to /dev/hdc .
> 
>    Is this right ?

Correct!

> 3) Matching rules - when applied:
>    At least for me, it is not really clear, when the rules will be applied.
>    As soon as a rules matches or at the end of the rule parsing "process"?
>    E.g.
>    KERNEL="hdc", GROUP="disk"
>    KERNEL="hdc", GROUP="sys"
>    in the first case, chmod would be called twice, in the latter case I
>    would assume only once...

The data is collected from the rules before the node is created. Only the last value
gets applied.

> Another example, where this would be important
>    is:
>    KERNEL="hdc", SYMLINK+="cdrom0"
>    KERNEL="hdc", SYMLINK:="cdrom"

The second rule clears out all previous assignments and prevents all
later changes to that value.

> And last but not least, is it planned, to have matching rules for major/minor
> numbers. E.g. MAJOR="b2" , GROUP="floppy" or MAJOR="c9|c27", GROUP="tape" ?

You can look at the content of the "dev" file with SYSFS{dev}.

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&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