Re: linux hotplug/hotplug-ng

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

On Sun, Aug 14, 2005 at 04:12:10PM +0200, Kasper Sandberg wrote:
> On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
> <snip>
> > 
> > Yes, as I said above, hotplug-ng is obsolete, you can do everything it
> > did with just one udev rule :)
> > 
> > Anyway, here's how things are shaking themselves out:
> > 
> > udev will replace hotplug and hotplug-ng entirely.  It almost does this
> > already today in the Gentoo tree, but I need to spend a bit more time to
> > tweak things properly to get it completly there.  To do that we will
> > just rely on the hotplug netlink messages coming out of the kernel and
> > set /proc/sys/kernel/hotplug to NULL.  udev will handle all of these
> > messages, and shuttle them off to their proper places if needed.
> > Combine udev with HAL and you pretty much have the full functionality of
> > the old hotplug package, with lots of extra goodies added (speed,
> > persistant naming, desktop notification, etc.)
> > 
> > An example of a distro that does all of this today is SuSE 10, you can
> > take a look at it in the opensuse download.  Kay is the one who got this
> > all working properly, not me.
> > 
> > Does this help out any?  
> > 
> yes, allthough i dont understand fully how udev can do this, except if
> it catches the hotplug messages from the kernel..
> 
> your idea seems very good, and i would like to help.. if you are
> interrested in me helping, you are welcome to msg me on irc(redeeman) or
> mail me..

udev is basically a replacement for the kernel forked /sbin/hotplug
helper and the directory multiplexing in /etc/hotplug.d/.

The udev daemon receives the event from the kernel and creates an event
handler that collects all nedded information about the specific device
from sysfs and by calling small external tools, mostly from the extras/ folder
of the udev tree. These tools have special knowledge about specific devices
and provide udev with that information to match rules, create specific
device names or run specific notification hooks.

The udev rules engine gives you fine grained control which tools are run and
which notifications are hooked into an specific event for a specific
device that the kernel sends an event for.
We already have had all the needed infrastructure to determine device
names with udev, that it was a easy to take over the complete hotplug
event handling. :)

udev does not replace the agent scripts or specific knowledge about a
subsystem. But sure, most of the current hotplug agents and shell scripts
have been or can be easily replaced by a bunch of rules for udev.

(A good example how much more efficient is the handling of a serial
devices. With the old hotplug, you catched the device by hooking into
the "tty" subsytem folder and your script got called for every tty
device that was found. Then your script started to look at the event
environment and just exited when it wasn't your "GPS device" that
called you. :)
The bad side-effect is that on bootup your hook got called 600 times for
all the /dev/tty* mess the kernel provides.
With udev you just create a rule that matches against a specific device
property, like USB product/vendor, physical path, add a RUN key to that
rule and you will get called only for that device!)

The second part of the big hotplug revamp is the MODALIAS string in
sysfs and the hotplug environment. Using modutils directly to resolve
a vendor/product id to a module name to load was the reason for
hotplug-ng. hotplug-ng composed with the device id's from the individual
buses a modalias string which is accepted from modprobe to resolve
it to module name(s) to load.
After a while we played around with hotplug-ng, it was decided, that the
kernel could compose that string directly and we can just pass that directly
to modprobe. :)

That combined with the udev device match and fine grained tool execution
based on device/event properties makes most of the old hotplug stuff
obsolete and a lot of things very easy to switch over without any shell
script involved.

A good starting point may to look at the copies of the distro rules in the
udev tree and play a bit around with it. And if your system still uses stuff
from /etc/dev.d/ or /etc/hotplug.d/ move that away and implement it as
udev rules or small tools to get rid of it. :)

Good luck,
Kay


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