From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7tB7-0008Qe-6b for qemu-devel@nongnu.org; Sun, 15 Jun 2008 10:25:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7tB4-0008QH-FO for qemu-devel@nongnu.org; Sun, 15 Jun 2008 10:25:55 -0400 Received: from [199.232.76.173] (port=56113 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7tB4-0008QE-7Y for qemu-devel@nongnu.org; Sun, 15 Jun 2008 10:25:54 -0400 Received: from ag-out-0708.google.com ([72.14.246.244]:28287) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K7tB3-0007J3-Tc for qemu-devel@nongnu.org; Sun, 15 Jun 2008 10:25:54 -0400 Received: by ag-out-0708.google.com with SMTP id 31so8715972agc.5 for ; Sun, 15 Jun 2008 07:25:52 -0700 (PDT) Message-ID: <4855265F.9070409@codemonkey.ws> Date: Sun, 15 Jun 2008 09:25:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Merge NBD client/server int qemu-nbd References: <1213370134.4833.29.camel@frecb07144> <4852B339.5090307@codemonkey.ws> <1213382394.3803.9.camel@frecb07144> <4853FD68.9000308@qumranet.com> <1213470224.3843.11.camel@frecb07144> <485416D2.9050900@qumranet.com> <1213471298.3843.20.camel@frecb07144> <48541D73.7000001@qumranet.com> <1213473262.15674.6.camel@frecb07144> In-Reply-To: <1213473262.15674.6.camel@frecb07144> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Laurent Vivier wrote: > Le samedi 14 juin 2008 à 12:35 -0700, Avi Kivity a écrit : > >> Laurent Vivier wrote: >> >> >> >> >>>> It is udev that creates the devices, based on events it receives from >>>> the kernel. Calling udevsettle after the kernel instructs udev to >>>> create the device files will wait until they are actually created. >>>> >>>> >>> Yes, I agree but the kernel events are generated by the open(), so I >>> think I can't use this to know if I can use open(). >>> >>> I've used udevmonitor to see what happen: >>> - without open() -> no events >>> - whith open() whithout sleep() -> no events >>> -> open() + sleep() -> events generated by the partition creation. >>> >>> So, what do I miss ? >>> >>> >> For this, it seems like sleep() generates the events, which is a little >> unlikely. I suggest re-checking this. >> > > re-checked, no events with sleep() only. > > events generated with sleep() + open() are: > I imagine the sleep() is causing another task to be scheduled (probably the server) which is what ends up generating the event. Regards, Anthony Liguori