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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

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.

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]