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. > >> >> What about this scenario. There are 1 million devices added to QEMU, and I >> need to >> add a device with an ID. Each of the 1 million devices already have an ID. >> If I don't want >> to try to find a unique ID myself, having QEMU do it for me would make >> things much easier. >> How would I find this device's ID? I could issue some kind of monitor >> command that gives me >> the ID. This feature doesn't appear to be implemented yet. This will change. >> A future >> ' info all-devices ' command would probably do it. > > If you're working at that kind of scale, then honestly apps are already > just going to be specifying an ID explicitly so we have no problem. It > is orders of magnitude simpler todo that than to try to parse any > 'info all-devices' output in order to determine QEMU's auto-generated > ID value. > > 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 :|
