From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7uae-0003Tv-VC for qemu-devel@nongnu.org; Sun, 15 Jun 2008 11:56:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7uae-0003Sg-22 for qemu-devel@nongnu.org; Sun, 15 Jun 2008 11:56:24 -0400 Received: from [199.232.76.173] (port=54038 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7uad-0003SZ-Vh for qemu-devel@nongnu.org; Sun, 15 Jun 2008 11:56:24 -0400 Received: from ecfrec.frec.bull.fr ([129.183.4.8]:47916) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K7uad-0005fz-Dh for qemu-devel@nongnu.org; Sun, 15 Jun 2008 11:56:23 -0400 Subject: Re: [Qemu-devel] [PATCH] Merge NBD client/server int qemu-nbd From: Laurent Vivier In-Reply-To: <4855265F.9070409@codemonkey.ws> 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> <4855265F.9070409@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Date: Sun, 15 Jun 2008 17:56:18 +0200 Message-Id: <1213545378.3806.10.camel@frecb07144> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Le dimanche 15 juin 2008 =C3=A0 09:25 -0500, Anthony Liguori a =C3=A9crit= : > Laurent Vivier wrote: > > Le samedi 14 juin 2008 =C3=A0 12:35 -0700, Avi Kivity a =C3=A9crit : > > =20 > >> Laurent Vivier wrote: > >> > >> =20 > >> > >> =20 > >>>> It is udev that creates the devices, based on events it receives f= rom=20 > >>>> the kernel. Calling udevsettle after the kernel instructs udev to= =20 > >>>> create the device files will wait until they are actually created. > >>>> =20 > >>>> =20 > >>> 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().=20 > >>> > >>> 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 ? > >>> =20 > >>> =20 > >> For this, it seems like sleep() generates the events, which is a lit= tle=20 > >> unlikely. I suggest re-checking this. > >> =20 > > > > re-checked, no events with sleep() only. > > > > events generated with sleep() + open() are: > > =20 >=20 > I imagine the sleep() is causing another task to be scheduled (probably= =20 > the server) which is what ends up generating the event. No, for me, the open() generates the events: open() -> blkdev_open() -> do_open() -> rescan_partitions() -> add_partitions() -> device_add() -> kobject_uevent() If you remove show_parts() from the main(), the partitions appear only on the first open on the device, for instance you can run manually "cmp /dev/nbd0 /dev/zero" after "qemu-nbd --connect=3D/dev/nbd0 ...". Laurent --=20 ------------- Laurent.Vivier@bull.net --------------- "The best way to predict the future is to invent it." - Alan Kay