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

[John Snow <jsnow@redhat.com>]

On 08/26/2015 06:01 PM, Jeff Cody wrote:
> 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 <programmingkidx@gmail.com> 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.

At this point, why not specify a user-friendly ID yourself? If there is
some technical reason you cannot, maybe we should fix the interface to
allow you to do so.

Auto-generated IDs are not likely to be short, pretty, or easy to type
due to the constraints Jeff Cody laid out earlier.

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