[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Should we auto-generate IDs?
From: |
Programmingkid |
Subject: |
Re: [Qemu-devel] Should we auto-generate IDs? |
Date: |
Thu, 27 Aug 2015 09:33:42 -0400 |
On Aug 27, 2015, at 8:32 AM, Jeff Cody wrote:
> (Added Eric back in to the CC list. Looks like he got dropped
> somewhere along the way)
>
> On Wed, Aug 26, 2015 at 11:22:08PM -0400, Programmingkid wrote:
>>
>> On Aug 26, 2015, at 6: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.
>>
>> Sure it is. Just set device id's like this: 0, 1, 2, 3, 4, 5, 6....
>
> I'm not married to the ID generation scheme I proposed.
>
> What I am trying to do, however, is have a technical discussion on
> generating an ID in a well-formed manner. And hopefully, in a way
> that is useful to all interested subsystems, if possible.
>
> Do you disagree with the requirements I listed above? If so, it would
> be useful to begin the discussion around that. For ease of
> discussion, I'll list them again:
>
> * Reserved namespaces
> * Uniqueness
> * Non-predictable (to avoid inadvertently creating a de facto ABI)
Uniqueness is a must. Reserve namespaces? Why do we need to do this?
What is wrong with having a predictable ID?
Maybe we need to discuss where this ID is going to be used. I know I
need it for the device_del monitor command. Any other places you or
anyone else knows it is used?
> . .
>
> On the generation scheme proposed above:
>
> I understand that something you desire is an ID that is easier to
> type.
>
> If we wanted to make it shorter, perhaps we could have the number
> counter be variable length:
>
> qemu#ss#D#XY
> | | | |
> qemu reserved - | | |
> | | |
> subsystem name ---| | |
> | |
> counter --------| |
> |
> 2-digit random ---|
>
>
> The counter would just grow to however many digits are needed. There
> is another benefit to growing that number as well - we can use
> whatever integer size we think is adequate in the code, without
> affecting the generation scheme.
>
> -Jeff
This system does seem easy to type. Do we need the "qemu" part?
It seems unnecessary. Maybe we could do this:
<subsystem name><counter>
Examples:
For the third block device it would look like this: bl3
For the seventh USB device it would look like this: ub7
Each subsystem would receive a two character code.
- Re: [Qemu-devel] Should we auto-generate IDs?, (continued)
- Re: [Qemu-devel] Should we auto-generate IDs?, Jeff Cody, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Eric Blake, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Daniel P. Berrange, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Eric Blake, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Jeff Cody, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, John Snow, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Eric Blake, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?,
Programmingkid <=
- Re: [Qemu-devel] Should we auto-generate IDs?, Daniel P. Berrange, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Eric Blake, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Daniel P. Berrange, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Jeff Cody, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Daniel P. Berrange, 2015/08/27
- Re: [Qemu-devel] Should we auto-generate IDs?, Programmingkid, 2015/08/27