From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 24 Jun 2005 11:50:03 +0000 Subject: Re: I'm lost: the udev workflow Message-Id: <20050624115003.GA22555@vrfy.org> List-Id: References: <200506240403.35408.ml@gioelebarabucci.com> In-Reply-To: <200506240403.35408.ml@gioelebarabucci.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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_id492&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