I'm lost: the udev workflow

I'm lost: the udev workflow

[Gioele Barabucci]

Now I'm lost. I'm no longer sure about the way udev, the kernel and other 
device management apps work together.

I was thinking that the workflow was:

* something happens to a device (add, remove, power state change)
* the kernel calls /sbin/hotplug
* udev is called and does its work (modprobe, rmmod, device node 
creation/deletion)
* all the "interested listeners" (like HAL) are called and are told of what 
has changed.

Now I read of netlink, listening daemons, KEYs... Can someone draft a quick 
sketch of how kernel hotplug is going to work with the next udev releases?

--
Gioele <dev@gioelebarabucci.com>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
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: I'm lost: the udev workflow

[Kay Sievers]

On Fri, Jun 24, 2005 at 04:03:35AM +0200, Gioele Barabucci wrote:
> Now I'm lost. I'm no longer sure about the way udev, the kernel and other 
> device management apps work together.
> 
> I was thinking that the workflow was:
> 
> * something happens to a device (add, remove, power state change)
> * the kernel calls /sbin/hotplug
> * udev is called and does its work (modprobe, rmmod, device node 
> creation/deletion)
> * all the "interested listeners" (like HAL) are called and are told of what 
> has changed.
> 
> Now I read of netlink, listening daemons, KEYs... Can someone draft a quick 
> sketch of how kernel hotplug is going to work with the next udev releases?

udevd already keeps track of the event management as it does today. The
only difference is that it receives the kernel-events directly from a
netlink-socket instead of letting the kernel fork a notification process
that feeds udevd.

This saves us one process per event, makes the event-ordering
predictable and does not kill the box if thousends of events happen in
parallel (we have such boxes here and you can't control the kernel
forked events which are causing OOM in that case).

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
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: I'm lost: the udev workflow

[Gioele Barabucci]

On Friday 24 June 2005 12:23, Kay Sievers wrote:
> udevd already keeps track of the event management as it does today. The
> only difference is that it receives the kernel-events directly from a
> netlink-socket instead of letting the kernel fork a notification process
> that feeds udevd.
So, if I got it correctly, in the future the "Good Way Of Doing Things" is 
going to be:

* /sbin/hotplug is empty
* udevd listens to hotplug events via netlink
* when one event is catch, udevd does its work loading modules and managing 
device files
* udevd notifies other applications (HALd & Co.) that something happened to 
the device foo whose device file is "/dev/foobar"

Seems nice :)

--
Gioele <dev@gioelebarabucci.com>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
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: I'm lost: the udev workflow

[Kay Sievers]

On Fri, Jun 24, 2005 at 01:36:05PM +0200, Gioele Barabucci wrote:
> On Friday 24 June 2005 12:23, Kay Sievers wrote:
> > udevd already keeps track of the event management as it does today. The
> > only difference is that it receives the kernel-events directly from a
> > netlink-socket instead of letting the kernel fork a notification process
> > that feeds udevd.
> So, if I got it correctly, in the future the "Good Way Of Doing Things" is 
> going to be:
> 
> * /sbin/hotplug is empty
> * udevd listens to hotplug events via netlink
> * when one event is catch, udevd does its work loading modules and managing 
> device files
> * udevd notifies other applications (HALd & Co.) that something happened to 
> the device foo whose device file is "/dev/foobar"

Yes, but it's not udevd itself, it's the forked udev event-handler,
that matches against the udev-rules and decides what to do: managing
/dev or/and running programs, whatever program it is: loading modules
or notifying HAL or something else).

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
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