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

[Jeff Cody]

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.


Jeff