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

[Jeff Cody]

On Wed, Aug 26, 2015 at 02:17:17PM -0400, Programmingkid wrote:
> 
> On Aug 26, 2015, at 2:08 PM, Jeff Cody wrote:
> 
> > On Wed, Aug 26, 2015 at 01:29:04PM -0400, Programmingkid wrote:
> >> 
> >> On Aug 26, 2015, at 1:25 PM, Jeff Cody wrote:
> >> 
> >>> 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 <address@hidden> 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  |
> >> 
> >> Yikes! 24 characters long. That is a bit much to type. Thank you very much
> >> for your effort.
> > 
> > IMO, the number of characters to type is pretty low on the list of
> > requirements, although it can still be addressed secondary to other
> > concerns.
> > 
> > I should have made this in reply to Markus' other email, because the
> > important part of this is try and address his point #2:
> > 
> > (from Markus' other email):
> >> 2. The ID must be well-formed.
> > 
> > To have a well-formed ID, we need to have know requirements of the ID
> > structure (i.e. the why and what of it all)
> > 
> > I don't know if the three requirements I had above apply to all areas
> > in QEMU, but I expect they do, in varying degrees of importance.  The
> > length itself can be tweaked.
> > 
> > Talking with John Snow over IRC (added to the CC), one thing he
> > suggested was adding in sub-domain spaces; e.g.:
> > 
> > __qemu#bn#00000000#IAIYNXXR
> > 
> > Where the 'bn' in this case would be for Block Nodes, etc..
> > 
> > This may make the scheme extensible through QEMU, where auto-generated
> > IDs are desired.
> > 
> > (sorry to say, this lengthens things, rather than shortening them!)
> > 
> > We can, of course, make the string shorter - if the random characters
> > are just there for spoiling predictability, then 2-3 should be
> > sufficient. We could then end up with something like this:
> > 
> > __qemu#bn#00000000#XR
> > 
> > The "__qemu" part of the namespace could be shortened as well, but it
> > would be nice if it was easy recognizable as being from QEMU.
> 
> If this ID format was supported, I'm thinking being able to copy and paste 
> from
> the monitor is a necessary feature. 
> 
> Any way it could be shorted? I was hoping no more than three characters long. 
>

Likely could be shorter, but something in the realm of three
characters doesn't seem very realistic.

> If this were the format of the ID, maybe we could put the value in a table 
> that
> would translate this long ID to a shorter version. Or maybe a mathematical 
> function
> could be applied to the value to give it some user-friendly value.

I'm afraid this would discard pretty much all the benefits of the ID
generation scheme.

> 
> I do think your idea virtually eliminates the problem of ID collisions.