incomplete doc questions

incomplete doc questions

[elkner]

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 ?

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). 
   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).
   
   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 ?

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... Another example, where this would be important
   is:
   KERNEL="hdc", SYMLINK+="cdrom0"
   KERNEL="hdc", SYMLINK:="cdrom"

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" ?

Regards,
jens.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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

Re: incomplete doc questions

[Kay Sievers]

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

Re: incomplete doc questions

[Jens Elkner]

'Kay Sievers wrote:'
> 
> On Fri, Jul 29, 2005 at 04:36:28PM +0200, elkner@linofee.org wrote:
> > 
> > 1) Setup:
> >    How should udev be activated (via /proc/sys/kernel/hotplug)?
> 
> I completely depends on your requirements and how your distro layouts

Well, since there is at the moment none, I can define, what I want and
this means, I do not want to bother with the old stuff / compat issues ...
;-)

> hotplug handling. The usual setup is /sbin/udevsend. Latest versions of
> udev can use netlink and the forked helper can be disabled completely,

Can you elaborate ?

> but the input-layer is broken and you need a kernel patch for it to work
> if you depend on input module-loading.

Hmm, since I prefer "all or nothing" - is there a dedicated place, where
one can download the required patch for recent kernels ?
  
> 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. :)

As far as I can ;-) - actually the "udev rule-based hotplug" hints 
in http://lwn.net/Articles/123932/ made me start to deal with udev ...
  
> 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? :)

OK.
  
> > 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}.

Hmm, ok and probably assume, that if the subsystem is not "block", it is
a char node... My idea is, to put the name rules in a separate file and
adjust them so, that the names are LANANA compliant. Than I can make
a contract, that nobody assigns/re-assigns other NAMES to the node and
can leave the permission.rules completely in the security officers' domain.

BTW:
Is there a list, what KERNEL values are used for which devices and perhaps
which BUS or SUBSYSTEM values are associated to them ? IMHO the SUBSYSTEM
values are no where explained in the docs, i.e. how its value is related
to sysfs... So I see the only way, one is able to assign a 99% reliable
LANANA NAME and SYMLINKS is to inspect the SYSFS{dev} ...
But this is implies a lot of work, since one would have to write a rule
for each {type,major,minor}, because NAME=".../%k" cannot be used since
(at least as I've seen) the kernel name is not always the same as the
basename(LANANA_NAME) ... :(((

Any hints ?

Regards,
jens.
-- 
+---[ Jens Elkner ]--------------------------------------------------------+
| Walther-Rathenau-Str. 58                 elkner@linofee.org              |
| 39104 Magdeburg   GERMANY           http://www.linofee.org/~jel/         |
+--------------------------------------------------------------------------+


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