Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > On Mon, Aug 23, 2021 at 9:35 AM Markus Armbruster <armbru@xxxxxxxxxx> wrote: >> >> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: >> >> > On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth <thuth@xxxxxxxxxx> wrote: >> >> >> >> On 11/08/2021 15.40, Eduardo Habkost wrote: >> >> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth <thuth@xxxxxxxxxx> wrote: >> >> >> >> >> >> On 10/08/2021 20.56, Eduardo Habkost wrote: >> >> >>> On Sat, Aug 07, 2021 at 04:22:42PM +0200, Markus Armbruster wrote: >> >> >>>> Is this intended to be a stable interface? Interfaces intended just for >> >> >>>> debugging usually aren't. >> >> >>> >> >> >>> I don't think we need to make it a stable interface, but I won't >> >> >>> mind if we declare it stable. >> >> >> >> >> >> If we don't feel 100% certain yet, it's maybe better to introduce this with >> >> >> a "x-" prefix first, isn't it? I.e. "x-query-x86-cpuid" ... then it's clear >> >> >> that this is only experimental/debugging/not-stable yet. Just my 0.02 €. >> >> > >> >> > That would be my expectation. Is this a documented policy? >> >> > >> >> >> >> According to docs/interop/qmp-spec.txt : >> >> >> >> Any command or member name beginning with "x-" is deemed >> >> experimental, and may be withdrawn or changed in an incompatible >> >> manner in a future release. >> > >> > Thanks! I had looked at other QMP docs, but not qmp-spec.txt. >> > >> > In my reply above, please read "make it a stable interface" as >> > "declare it as supported by not using the 'x-' prefix". >> > >> > I don't think we have to make it stable, but I won't argue against it >> > if the current proposal is deemed acceptable by other maintainers. >> > >> > Personally, I'm still frustrated by the complexity of the current >> > proposal, but I don't want to block it just because of my frustration. >> >> Is this a case of "there must be a simpler way", or did you actually >> propose a simpler way? I don't remember... >> > > I did propose a simpler way at > https://lore.kernel.org/qemu-devel/20210810195053.6vsjadglrexf6jwy@xxxxxxxxxxx/ Valeriy, would the simpler way still work for you? If no, please explain why. If you already did, just provide a pointer. If yes, we need to choose between the complex solution we have and the simpler solution we still need to code up. The latter is extra work, but having to carry more complex code is going to be extra work, too.
