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 <programmingk...@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. >> >> 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.
