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.
