On Aug 27, 2015, at 11:40 AM, Jeff Cody wrote: > On Thu, Aug 27, 2015 at 11:20:20AM -0400, Programmingkid wrote: >> >> On Aug 27, 2015, at 10:42 AM, Daniel P. Berrange wrote: >> >>> On Thu, Aug 27, 2015 at 10:34:05AM -0400, Programmingkid wrote: >>>> >>>> On Aug 27, 2015, at 10:02 AM, Eric Blake wrote: >>>> >>>>> On 08/27/2015 07:56 AM, Programmingkid wrote: >>>>> >>>>>>> If we did have auto-generated names, we would need to come up with a >>>>>>> scheme that is not going to clash with any existing naming that users >>>>>>> of QEMU may already be doing, otherwise we risk causing a regression. >>>>>>> Something as simple as what you suggest has non-trivial chance of >>>>>>> clashing. >>>>>> >>>>>> Actually there is a way to prevent clashing. When QEMU auto-generates a >>>>>> name, it could scan all the ID's to see if there is a clash. If the ID >>>>>> is already >>>>>> taken, just increment the ID until it is detected to be unique. The >>>>>> previous >>>>>> threads on this subject has patches that did just that. This means that a >>>>>> ID scheme that is just a single number would work without clashes. >>>>> >>>>> No, because you cannot predict what FUTURE names the user will request. >>>>> The name generated by qemu must be IMPOSSIBLE to request manually, and >>>>> not just one that happens not to clash at the current moment. >>>> >>>> If I add a device with an ID that is taken, QEMU can just say sorry that >>>> ID is already >>>> taken. I could just increment the ID myself until I find one that is >>>> unique. It is a >>>> simple algorithm. Maybe you are talking about some program that has hard >>>> coded >>>> ID's it depends on. If that is the case, perhaps this management program >>>> could be >>>> made to be a little flexible. Or use a 160-bit SHA-1 generated ID that is >>>> virtually >>>> guaranteed to always be unique. >>> >>> If breaking existing apps was OK, we would just mandate that users always >>> provide an ID which trivially avoids the problem of not having an ID to >>> use when deleting the object. We want to /avoid/ breaking existing apps >>> though, so saying an app should change the way it works in order to cope >>> with QEMU's ID generation is not appropriate. Hence any use of >>> auto-generated >>> IDs, must use a separate namespace to avoid such clashes. >> >> This is making the assumption that an auto-generated ID system would break >> any existing >> application. We don't know this. In fact, I predict a future patch would >> allow existing >> applications to continue running without modification. The patch would be a >> win-win >> for both users and any management application. >> > > Daniel's assumption is spot on. The idea of "QEMU can just say sorry > that ID is already taken" will break existing applications. > > But we are all striving to make your prediction true, with this very > conversation.
Ok, it sounds like some are concerned that Libvirt would not be able to work with this feature. Let me ask you this: does Libvirt interact with QEMU before the user has a chance to do so? If the answer is yes, then that means Libvirt will have finished creating all its devices with their ID's long before the user has a chance to enter his own devices.
