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