From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 13 Sep 2005 17:27:16 +0000 Subject: Re: Looking for a clue in how udev, hal, hotplug and dbus work together Message-Id: <20050913172716.GA29716@vrfy.org> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Tue, Sep 13, 2005 at 01:12:36PM -0400, Jim McQuillan wrote: > > > On Tue, 13 Sep 2005, Kay Sievers wrote: > > > On Tue, Sep 13, 2005 at 12:50:24AM -0400, Jim McQuillan wrote: > > > I'm trying to get a grasp on how udev, hal, hotplug and dbus play > > > together in detecting devices. > > > > > > I'm doing this for LTSP (Linux Terminal Server Project). This is > > > Thin-clients in Linux. We currently have the ability to plug a usb > > > device in, such as a mini-cruizer USB memory stick. When the device is > > > inserted, we have a hotplug script written in perl, that gets the event > > > from the kernel, figures out what kind of device it is, loads the > > > appropriate kernel modules, mounts the filesystem on the device, and > > > then signals the server that a new device is available. This is all > > > under a 2.4.26 kernel. > > > > > > Now, I'm moving up to a 2.6.13 kernel, and I'd like to do things the > > > "right way". That is, I'm dropping devfs, and using udev. I'm thinking > > > that to use udev, then I also should be using hal and dbus. But so far, > > > i've not been able to wrap my head around how it all works together. > > > > > > from what I've read, it seems that I should be setting > > > /proc/sys/kernel/hotplug to "", and that "netlink" is now used for the > > > kernel to send messages to udev. Then, udev sends messages to hald. > > > > udevd listens to kernel uevents over netlink and the event gets matched > > against the udev rules, a node created if needed and all postprocessing > > hooks (RUN=) in matching udev rules are executed. > > > > /proc/sys/kernel/hotplug should be disabled, but the "input" layer lacks > > sysfs support so you need /sbin/udevsend here until that is fixed. > > > > > So, my question is, when a new USB device is plugged in, take the > > > 'mini-cruizer' memory stick for example, at what point is the kernel > > > module loaded? Does 'hald' handle that? or do I still need "hotplug" > > > scripts. > > > > The kernel offers a modalias file in sysfs that signifies that a driver > > needs to be loaded. You can do this with a simple generic udev rule or > > any other facility. Just running modprobe with the content of the > > modlias file should be able to replace almost all old hotplug stuff. > > > > > Once the mini-cruizer is detected, where to I put my hooks in, to signal > > > the server that a new device is available? > > > > What kind of server? > > The LTSP server (as in big computer, not a daemon). I have a socket > open between the LTSP client and the LTSP server, where I can send > messages between the two. In the case of a memory-stick insertion, I > need to send a message to tell the server to put an icon on the users > desktop. The desktop session is running on the server, displaying its > output to the client, via X. Just look at a recent udev version and run "udevmonitor --env" while adding removing hardware. udevmonitor gets the information from udev with: RUN+="socket:/org/kernel/udev/monitor" You can listen the same way with you managing application. The format is the same as the kernel sends to userspace, but the payload also contains the data udev has added, like the device node name. Another higher level option is using DBUS and HAL which can do much more and is more flexible but also more complicated. 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