On Sun, Feb 20, 2022 at 05:18:33PM +0000, Mark Cave-Ayland wrote:
On 08/02/2022 13:10, Daniel P. Berrangé wrote:
On Tue, Feb 08, 2022 at 01:06:59PM +0000, Mark Cave-Ayland wrote:
On 08/02/2022 12:49, Daniel P. Berrangé wrote:
I was under the impression that monitor_register_hmp_info_hrt() does all the
magic here i.e. it declares the underlying QMP command with an x- prefix and
effectively encapsulates the text field in a way that says "this is an
unreliable text opaque for humans"?
The monitor_register_hmp_info_hrt only does the HMP glue side, and
that's only needed if you must dynamically register the HMP command.
For statically registered commands set '.cmd_info_hrt' directly in
the hml-commands-info.hx for the HMP side.
If a qapi/ schema is needed could you explain what it should look like for
this example and where it should go? Looking at the existing .json files I
can't immediately see one which is the right place for this to live.
Take a look in qapi/machine.json for anyof the 'x-query-XXXX' commands
there. The QAPI bit is fairly simple.
if you want to see an illustration of what's different from a previous
pure HMP impl, look at:
commit dd98234c059e6bdb05a52998270df6d3d990332e
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Wed Sep 8 10:35:43 2021 +0100
qapi: introduce x-query-roms QMP command
I see, thanks for the reference. So qapi/machine.json would be the right
place to declare the QMP part even for a specific device?
Even this approach still wouldn't work in its current form though, since as
mentioned in my previous email it seems that only the target CONFIG_*
defines and not the device CONFIG_* defines are present when processing
hmp-commands-info.hx.
Yeah, that's where the pain comes in. While QAPI schema can be made
conditional on a few CONFIG_* parameters - basically those derived
from global configure time options, it is impossible for this to be
with with target specific options like the device CONFIG_* defines.
This is why I suggested in my othuer reply that it would need to be
done with a generic 'info dev-debug' / 'x-query-dev-debug' command
that can be registered unconditionally, and then individual devices
plug into it.
After some more experiments this afternoon I still seem to be falling
through the gaps on this one. This is based upon my understanding that all
new HMP commands should use a QMP HumanReadableText implementation and the
new command should be restricted according to target.
Currently I am working with this change to hmp-commands-info.hx and
qapi/misc-target.json:
[snip]
i.e. qmp_marshal_output_HumanReadableText() isn't protected by the #if
TARGET guards and since HumanReadableText is only used by the new
qmp_x_query_via() functionality then the compiler complains and aborts the
compilation.
Possibly this is an error in the QAPI generator for types hidden behind
commands using "if"? Otherwise I'm not sure what is the best way to proceed,
so I'd be grateful for some further pointers.
Yes, this is pretty much what I expect and exactly what I hit with
other target specific commands.
That's why I suggested something like a general 'x-device-debug' command
that is NOT conditionalized in QAPI, against which dev impls can register
a callback to provide detailed reporting, instead of a device type specific
command.