(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) . . . 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