From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 30 Jul 2005 00:07:43 +0000 Subject: Re: incomplete doc questions Message-Id: <20050730000743.GA18784@vrfy.org> List-Id: References: <200507291436.j6TEaTmA026927@wh58-307.st.uni-magdeburg.de> In-Reply-To: <200507291436.j6TEaTmA026927@wh58-307.st.uni-magdeburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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_id492&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