From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyxh-000174-A1 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:19:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUyxd-00023k-KY for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:19:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyxd-00023a-FN for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:19:29 -0400 Date: Thu, 27 Aug 2015 16:19:24 +0100 From: "Daniel P. Berrange" Message-ID: <20150827151924.GY24486@redhat.com> References: <20150826172550.GJ11016@localhost.localdomain> <20150826180815.GK11016@localhost.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E7FD2A3-C967-4D30-A657-548D27BCC84B@gmail.com> 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 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. 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 :|