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 :|