Looking for a clue in how udev, hal, hotplug and dbus work together

Looking for a clue in how udev, hal, hotplug and dbus work together

[Jim McQuillan]

Hey all,

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.

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.

Once the mini-cruizer is detected, where to I put my hooks in, to signal
the server that a new device is available?

If someone can just give me a shove in the right direction, i'm sure I
can get moving a whole lot faster than I am now.

Thanks,
Jim McQuillan
jam@Ltsp.org


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

Re: Looking for a clue in how udev, hal, hotplug and dbus work together

[Kay Sievers]

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?

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

Re: Looking for a clue in how udev, hal, hotplug and dbus work

[Jim McQuillan]

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.

Thanks,

Jim McQuillan
jam@Ltsp.org


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

Re: Looking for a clue in how udev, hal, hotplug and dbus work together

[Kay Sievers]

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