From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Jenkins Date: Wed, 03 Jun 2009 20:46:01 +0000 Subject: Re: [GIT] Experimental threaded udev Message-Id: <4A26E109.7010703@tuffmail.co.uk> List-Id: References: <4A1EA138.10400@tuffmail.co.uk> In-Reply-To: <4A1EA138.10400@tuffmail.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Kay Sievers wrote: > On Tue, Jun 2, 2009 at 16:05, Kay Sievers wrote: > > >> Version 5. I guess we should go for the signalfd stuff, it looks prett >> nice. The socketpair instead of the rtsignal is also nice, it allows >> us to pass back arbitrary data from finished events to the main >> daemon. >> > > Version 7. We need to handle the netlink unicast addresses, they are > not neccessarily the process pid, so we need to remember the netlink > address. > > We also keep 2 workers around, and don't kill them, to handle incoming > events without forking. > > Thanks, > Kay > Ok. I think the patch breaks the settle control message. It now sends the signal back to udevadm immediately, instead of postponing it until after handle_inotify(), which was apparently the point. " Now udevadm settle will send a control message to udevd, which will respond by sending SIGUSR1 back to the waiting udevadm settle once it has completed the main loop iteration in which it received the control message. If there were no pending inotify events, this will simply wake up the udev daemon and allow settle to continue. *If there are pending inotify events, they are handled first in the main loop* so when settle is continued they will have been turned into uevents and the kernel sequence number will have been incremented. " Perhaps it would be simplest to reorder the main loop so that handle_ctrl() comes after handle_inotify(). If I'm right, it could benefit from a comment pointing out that this order is significant and should be preserved. That said, I don't completely understand the settle control message. I don't get why udevadm-settle only sends it once at the start, instead of incorporating it as part of the delay loop. Thanks Alan