From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzhC-00054Y-PY for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:06:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUzh6-000727-PM for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:06:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzh6-000720-Hx for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:06:28 -0400 Date: Thu, 27 Aug 2015 17:06:23 +0100 From: "Daniel P. Berrange" Message-ID: <20150827160623.GB24486@redhat.com> References: <20150826220151.GA2669@localhost.localdomain> <2CB0CE30-A638-4933-A1D6-F65CA4910E61@gmail.com> <20150827123234.GB2669@localhost.localdomain> <56530C98-D6B3-417E-BB58-E29412283BF1@gmail.com> <20150827140707.GD2669@localhost.localdomain> <4E7FD2A3-C967-4D30-A657-548D27BCC84B@gmail.com> <20150827151924.GY24486@redhat.com> <96F6061A-2DEB-440D-BB80-B300CA27BDEE@gmail.com> <20150827155527.GZ24486@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Should we auto-generate IDs? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Kevin Wolf , Jeff Cody , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , jsnow@redhat.com, Andreas =?utf-8?Q?F=C3=A4rber?= On Thu, Aug 27, 2015 at 12:03:38PM -0400, Programmingkid wrote: > > On Aug 27, 2015, at 11:55 AM, Daniel P. Berrange wrote: > > > On Thu, Aug 27, 2015 at 11:22:58AM -0400, Programmingkid wrote: > >> > >> On Aug 27, 2015, at 11:19 AM, Daniel P. Berrange wrote: > >> > >>> On Thu, Aug 27, 2015 at 11:13:25AM -0400, Programmingkid wrote: > >>>>> > >>>>>> What is wrong with having a predictable ID? > >>>>>> > >>>>> > >>>>> As Daniel and Eric have noted, it could be nice to have a predictable > >>>>> ID. My concern with a predictable ID is that it creates, across > >>>>> multiple sub-systems, an ABI that we will then need to make sure > >>>>> always works. > >>>>> > >>>>> For instance, I don't want management software or a user to rely on us > >>>>> parsing devices, or image filenames / block driver states in a certain > >>>>> order, and then anticipate the ID name. I am concerned about creating > >>>>> an interface that may inadvertently "break" later on, and imposing a > >>>>> burden on QEMU that isn't reasonable. Perhaps it is enough to just > >>>>> rely on documentation for this, without enforcing it in the scheme. > >>>> > >>>> If we do nothing, QEMU stays broken. The monitor command device_del > >>>> and others that need an ID will not work still. Hopefully any changes we > >>>> make to QEMU will be robust enough stand the test of time. > >>> > >>> That is not correct. It is possible for us to fix object_del / device_del > >>> to accept the QOM object path. It isn't pretty but it is a solution that > >>> gives everything a stable unique path ID to use for deletion even if the > >>> user forgets to give a pretty path-less ID. > >> > >> This QOM path might be better than nothing. Hopefully someone will make this > >> patch and share it with us. > > > > I sent a patch to support that, since it turned out to be pretty > > trivial to implement. So that at least solves the immediate blocking > > issue of deleting devices with an ID. The question of usability and > > auto-generated IDs can continue in parallel.... > > > > Regards, > > Daniel > > I applied your patch, but saw this error message when I tried to 'make' QEMU: > > GEN qmp-commands.txt > line 344: syntax error: expected EQMP, found SQMP > make: *** [qmp-commands.txt] Error 1 > make: *** Deleting file `qmp-commands.txt' > > Know what it means? It means I should have run 'make' again after adding the documentation to detect the bug :-) I'll send another patch.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|