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

[Programmingkid]

On Aug 26, 2015, at 6:04 PM, John Snow wrote:

> 
> 
> 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 <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.
> 
> At this point, why not specify a user-friendly ID yourself?
Right now, if the user forgets to specifiy an ID, device_del can't work. That's 
not good enough.

> If there is
> some technical reason you cannot, maybe we should fix the interface to
> allow you to do so.
I can do it myself, but having QEMU do it for the user makes things better and 
easier for the user.

> 
> Auto-generated IDs are not likely to be short, pretty, or easy to type
> due to the constraints Jeff Cody laid out earlier.
I think we are going to have to agree to disagree on this point.