Re: linux hotplug/hotplug-ng

[Kasper Sandberg <postmaster@metanurb.dk>]

On Sun, 2005-08-14 at 21:33 +0200, Kay Sievers wrote:
<snip>
> 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.
that is fine too.. all i want is to get rid of those bash scripts.

> (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 seems nice :)
> 
> 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. :)
i will try install opensuse and look at their udev setup, and also try
see all the udev configurations in the tarball.. and perhaps try do what
i can figure out on my testsystem, to get my system working with
hotplug, completely without those scripts. :)


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