From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXaDL-0007Ob-0p for qemu-devel@nongnu.org; Mon, 25 Aug 2008 07:26:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXaDI-0007Mf-Lq for qemu-devel@nongnu.org; Mon, 25 Aug 2008 07:26:26 -0400 Received: from [199.232.76.173] (port=50100 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXaDI-0007MZ-E7 for qemu-devel@nongnu.org; Mon, 25 Aug 2008 07:26:24 -0400 Received: from il.qumranet.com ([212.179.150.194]:37534) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXaDH-0007YL-Rv for qemu-devel@nongnu.org; Mon, 25 Aug 2008 07:26:24 -0400 Date: Mon, 25 Aug 2008 14:26:21 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v2 4/6] Use libuuid if available. Message-ID: <20080825112621.GL6192@minantech.com> References: <20080825095800.18703.30602.stgit@gleb-debian.qumranet.com.qumranet.com> <20080825095820.18703.69963.stgit@gleb-debian.qumranet.com.qumranet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: qemu-devel@nongnu.org On Mon, Aug 25, 2008 at 01:08:50PM +0200, Andreas F=C3=A4rber wrote: > > Am 25.08.2008 um 11:58 schrieb Gleb Natapov: > >> If libuuid is available use it for UUID generation in case a user does= =20 >> not >> provide one. >> >> Signed-off-by: Gleb Natapov >> --- > > I don't remember hearing an answer on why this is necessary. For which = =20 > use case can't you just either use -uuid `uuidgen` or a hardcoded =20 > default value like the Slirp IPv4 subnet? It can be used for UUID generation when VM is started for the first time. Management application can retrieve UUID using monitor and use it for consequent runs. But the same result can be achieved in a different way too. So no, I really don't have a strong use case for this feature, but the patch set is organised in such way that it is possible to ignore this particular patch. -- Gleb.