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

[John Snow]

On 08/27/2015 09:00 AM, Eric Blake wrote:
> On 08/27/2015 06:32 AM, Jeff Cody wrote:
>> (Added Eric back in to the CC list.  Looks like he got dropped 
>> somewhere along the way)
> 
> No thanks to mailman's inept behavior that thinks that it is okay
> to rewrite cc's to drop anyone that doesn't want duplicate email.
> But don't worry about it; I have my local mail setup to flag any
> message in-reply-to an earlier one where I was in cc, precisely to
> work around mailman stupidly dropping me from cc. [Ideally, I'd
> filter the duplicate messages on my side, and turn off the broken
> mailman setting server-side, but I haven't yet figured out how to
> get filters working on my side that do that correctly.]  I'm hoping
> that mailman3 is not so inept, and that this list archives can
> migrate to hyperkitty/mailman3 in the not-too-distant future.
> 
> 
>> 
>> Do you disagree with the requirements I listed above?  If so, it
>> would be useful to begin the discussion around that.  For ease
>> of discussion, I'll list them again:
>> 
>> * Reserved namespaces * Uniqueness * Non-predictable (to avoid
>> inadvertently creating a de facto ABI)
> 
> Dan made the point that if a name is unpredictable, then we have
> to query to learn what name was assigned.  But if you add two or
> more devices before querying, then you don't know which device has
> which name.  Predictable might actually be better than
> non-predictable.
> 

Can we add the information into the QMP response?

> Better still might be fixing things to where we add a global
> command line option that outright fails any attempt to create an
> unnamed object. The option would be off by default for back-compat.
> But management apps like libvirt can turn it on once they are
> prepared to name every object they create (which in turn may imply
> fixing any remaining interfaces that cannot name an object to add
> in that ability for management to pass in a name).  Then there
> would be no unnamed objects, no ambiguity, and no need to generate
> names.
>