From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 14 Aug 2005 19:33:49 +0000 Subject: Re: linux hotplug/hotplug-ng Message-Id: <20050814193349.GB15587@vrfy.org> List-Id: References: <1123747167.31868.11.camel@localhost> In-Reply-To: <1123747167.31868.11.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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: > > > > > 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