From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUeST-0003J2-Pi for qemu-devel@nongnu.org; Wed, 26 Aug 2015 13:25:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUeSP-0005PT-Go for qemu-devel@nongnu.org; Wed, 26 Aug 2015 13:25:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUeSP-0005PJ-9j for qemu-devel@nongnu.org; Wed, 26 Aug 2015 13:25:53 -0400 Date: Wed, 26 Aug 2015 13:25:50 -0400 From: Jeff Cody Message-ID: <20150826172550.GJ11016@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fv36j9j6.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , qemu-devel qemu-devel , Programmingkid , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Wed, Aug 26, 2015 at 06:31:57PM +0200, Markus Armbruster wrote: > Did you drop cc's intentionally? I put them right back. > > Programmingkid writes: > > > On Aug 25, 2015, at 8:38 AM, Markus Armbruster wrote: > > > >> You're proposing to revise a qdev design decision, namely the purpose of > >> IDs. This has been discussed before, and IDs remained unchanged. > >> Perhaps it's time to revisit this issue. Cc'ing a few more people. > >> > >> Relevant prior threads: > >> * [PATCH] qdev: Reject duplicate and anti-social device IDs > >> http://thread.gmane.org/gmane.comp.emulators.qemu/71230/focus=72272 > >> * [PATCH 6/6] qdev: Generate IDs for anonymous devices > >> http://thread.gmane.org/gmane.comp.emulators.qemu/114853/focus=114858 > >> * [PATCH] qdev: Assign a default device ID when none is provided. > >> http://thread.gmane.org/gmane.comp.emulators.qemu/249702 > >> * IDs in QOM (was: [PATCH] util: Emancipate id_wellformed() from QemuOpt > >> http://thread.gmane.org/gmane.comp.emulators.qemu/299945/focus=300381 > >> > > > > After reading all the threads, I realize why all the attempts to > > accept a device ID patch failed. > > It is because it was assumed everyone would agree on one patch to > > accept. This is > > very unlikely. It would take someone in a leadership position to > > decide which patch > > should be accepted. From one of the threads above, I saw Anthony > > Liguori participate. > > He was in the perfect position to make the choice. The person who is > > in his position now > > is Peter Maydell. Maybe we should just ask him to look at all the > > candidate patches and > > have him pick one to use. > > Yes, when no consensus emerges, problems tend to go unsolved. > > Before we appeal to authority to break the deadlock, we should make > another attempt at finding consensus. > > I know that we've entertained the idea of automatically generated IDs > for block layer objects (that's why I cc'ed some block guys). Yeah, I was one of the ones that proposed some auto-generated IDs for the block layer, specifically for BlockDriverState, making use of the node-name field that Benoit introduced a while ago. Here is my patch (not sure if this is the latest version, but it is sufficient for this discussion): http://patchwork.ozlabs.org/patch/355990/ I'm not sure about the requirements needed by device ID names, and they may of course differ from what I was thinking for BDS entries. Here is what I was after with my patch for node-name auto-generation: * Identifiable as QEMU generated / reserved namespace * Guaranteed uniqueness * Non-predictable (don't want users trying to guess / assume generated node-names) My approach was overkill in some ways (24 characters!). But for better or worse, what I had was: __qemu##00000000IAIYNXXR ^^^^^^^^ QEMU namespace ----| ^^^^^^^^ | ^^^^^^^^^ Increment counter, unique | | | Random string, to spoil prediction | > > I definitely want to hear Andreas's and Paolo's opinion (also cc'ed), if > they have one.