From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2Os-0004c5-Vn for qemu-devel@nongnu.org; Thu, 27 Aug 2015 14:59:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV2On-0007IQ-TJ for qemu-devel@nongnu.org; Thu, 27 Aug 2015 14:59:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2On-0007IJ-Gw for qemu-devel@nongnu.org; Thu, 27 Aug 2015 14:59:45 -0400 References: <29C62C49-06A5-4F99-8062-7269A28C29A3@gmail.com> <8737z7o85i.fsf@blackfin.pond.sub.org> <441C227A-2CF0-43AE-AC7F-B066708CEABD@gmail.com> <87fv36j9j6.fsf@blackfin.pond.sub.org> <20150826172550.GJ11016@localhost.localdomain> <20150826180815.GK11016@localhost.localdomain> <20150826220151.GA2669@localhost.localdomain> <2CB0CE30-A638-4933-A1D6-F65CA4910E61@gmail.com> <20150827123234.GB2669@localhost.localdomain> <55DF09DB.2000406@redhat.com> From: John Snow Message-ID: <55DF5E20.8080204@redhat.com> Date: Thu, 27 Aug 2015 14:59:44 -0400 MIME-Version: 1.0 In-Reply-To: <55DF09DB.2000406@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Jeff Cody , Programmingkid Cc: Kevin Wolf , Paolo Bonzini , Markus Armbruster , =?UTF-8?Q?Andreas_F=c3=a4rber?= , qemu-devel qemu-devel 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. >