qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Should we auto-generate IDs?


From: Programmingkid
Subject: Re: [Qemu-devel] Should we auto-generate IDs?
Date: Thu, 27 Aug 2015 11:20:20 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]