On 13.10.2016 00:46, John Ferlan wrote: [...] >>>> >>>> Despite fixing user strings in this version to show the word >>>> 'running' the enum value [1] is still changed for the new one. >>>> Since the actual value is used by programs and not humans that may >>>> break and I'm not comfortable allowing such change in semantics. > Hm, really? From an API perspective up to now it was perfectly OK to > accept any of "offline", "running" and "blocked". > I maintain that it is valid to extend the state enumeration and virsh > shows how to handle previously unknown states. > >> I think the objection is for the vcpuinfo command which shouldn't need >> to be CPU aware, but perhaps similar to how aware the hotplug code had >> to be made for the differences between arch's, maybe the info code needs >> that as well (as ugly as that could be). I'm just trying to throw some >> suggestions out there to see if anything sticks. > >> It's painful that the "halted" bit has multiple meanings, but I think >> it's handle-able - we just have to find the right way to do it... > I think it's not libvirt's task to interpret the meaning of halted as reported by QEMU. That's why I added the new state in the first place instead of reusing e.g. offline, which would have introduced architecture depend code which I'd like to avoid where possible. >> Another "thought" that strikes me is whether there's a "valid" scenario >> where someone can halt a CPU from the guest and how that gets propagated >> back - even on x86. OK it's a slight divergence... > >> While I did suggest some sort of running (halted) output, does seeing >> that on for a non x86 guest make sense for the state the CPU is in? In a >> former job, I think we called it "running (idle)" mainly because >> "halted" has a somewhat negative connotation. > >> So another option might be to allow a vcpuinfo user to pass a new flag >> that would allow that return of this more detailed state. Only if the >> flag was set would we check/return the new state. I think that's what >> we've done in the past for similar things where changing the "default" >> return/display value could cause "issues" for those programs that rely >> on the string being "running" without " (halted)" or " (idle)". Does >> this make sense? > In essence that would mean to implement a new API, which seems to be too heavy a hammer for this small nail. >> Then for the other (stats) output, returning the value of the "halted" >> field could be an "additional" set of output/data to be added rather >> than overloading the existing field. Does this make sense? > > That's what I'll do, expect a new series soon... [...] > And, if you find value in the virsh.pod update in 1/4, you can either > pick the parts you need or let me know and I can provide an abridged > version. > [...] > >> I do like the adjustments made to virsh.pod. > There you go... >> John > >> >> -- >> libvir-list mailing list >> libvir-list@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/libvir-list >> > -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list