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. > 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. > > I do think your idea virtually eliminates the problem of ID collisions.
