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: Jeff Cody
Subject: Re: [Qemu-devel] Should we auto-generate IDs?
Date: Thu, 27 Aug 2015 11:40:57 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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.





reply via email to

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