aboutsummaryrefslogtreecommitdiff
path: root/docs/devel/writing-monitor-commands.rst
AgeCommit message (Collapse)Author
2022-12-13qapi: Start to elide redundant has_FOO in generated CMarkus Armbruster
In QAPI, absent optional members are distinct from any present value. We thus represent an optional schema member FOO as two C members: a FOO with the member's type, and a bool has_FOO. Likewise for function arguments. However, has_FOO is actually redundant for a pointer-valued FOO, which can be null only when has_FOO is false, i.e. has_FOO == !!FOO. Except for arrays, where we a null FOO can also be a present empty array. The redundant has_FOO are a nuisance to work with. Improve the generator to elide them. Uses of has_FOO need to be replaced as follows. Tests of has_FOO become the equivalent comparison of FOO with null. For brevity, this is commonly done by implicit conversion to bool. Assignments to has_FOO get dropped. Likewise for arguments to has_FOO parameters. Beware: code may violate the invariant has_FOO == !!FOO before the transformation, and get away with it. The above transformation can then break things. Two cases: * Absent: if code ignores FOO entirely when !has_FOO (except for freeing it if necessary), even non-null / uninitialized FOO works. Such code is known to exist. * Present: if code ignores FOO entirely when has_FOO, even null FOO works. Such code should not exist. In both cases, replacing tests of has_FOO by FOO reverts their sense. We have to fix the value of FOO then. To facilitate review of the necessary updates to handwritten code, add means to opt out of this change, and opt out for all QAPI schema modules where the change requires updates to handwritten code. The next few commits will remove these opt-outs in reviewable chunks, then drop the means to opt out. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221104160712.3005652-5-armbru@redhat.com>
2022-10-06monitor: expose monitor_puts to rest of codeAlex Bennée
This helps us construct strings elsewhere before echoing to the monitor. It avoids having to jump through hoops like: monitor_printf(mon, "%s", s->str); It will be useful in following patches but for now convert all existing plain "%s" printfs to use the _puts api. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220929114231.583801-33-alex.bennee@linaro.org>
2022-05-09docs/devel/writing-monitor-commands: Replace obsolete STEXI/ETEXI tagsThomas Huth
STEXI and ETEXI is not used anymore since we switched to Sphinx. Replace them in the example with SRST and ERST, too. Message-Id: <20220506150146.564244-1-thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-11-22Fix some typos in documentation (found by codespell)Stefan Weil
Signed-off-by: Stefan Weil <sw@weilnetz.de> Message-Id: <20211117210702.1393570-1-sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [thuth: "what's" --> "what is" as suggested by philmd] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-11-02docs/devel: document expectations for HMP commands in the futureDaniel P. Berrangé
We no longer wish to have commands implemented in HMP only. All commands should start with a QMP implementation and the HMP merely be a shim around this. To reduce the burden of implementing QMP commands where there is low expectation of machine usage, requirements for QAPI modelling are relaxed provided the command is under the "x-" name prefix. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-02docs/devel: add example of command returning unstructured textDaniel P. Berrangé
This illustrates how to add a QMP command returning unstructured text, following the guidelines added in the previous patch. The example uses a simplified version of 'info roms'. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-02docs/devel: document expectations for QAPI data modelling for QMPDaniel P. Berrangé
Traditionally we have required that newly added QMP commands will model any returned data using fine grained QAPI types. This is good for commands that are intended to be consumed by machines, where clear data representation is very important. Commands that don't satisfy this have generally been added to HMP only. In effect the decision of whether to add a new command to QMP vs HMP has been used as a proxy for the decision of whether the cost of designing a fine grained QAPI type is justified by the potential benefits. As a result the commands present in QMP and HMP are non-overlapping sets, although HMP comamnds can be accessed indirectly via the QMP command 'human-monitor-command'. One of the downsides of 'human-monitor-command' is that the QEMU monitor APIs remain tied into various internal parts of the QEMU code. For example any exclusively HMP command will need to use 'monitor_printf' to get data out. It would be desirable to be able to fully isolate the monitor implementation from QEMU internals, however, this is only possible if all commands are exclusively based on QAPI with direct QMP exposure. The way to achieve this desired end goal is to finese the requirements for QMP command design. For cases where the output of a command is only intended for human consumption, it is reasonable to want to simplify the implementation by returning a plain string containing formatted data instead of designing a fine grained QAPI data type. This can be permitted if-and-only-if the command is exposed under the 'x-' name prefix. This indicates that the command data format is liable to future change and that it is not following QAPI design best practice. The poster child example for this would be the 'info registers' HMP command which returns printf formatted data representing CPU state. This information varies enourmously across target architectures and changes relatively frequently as new CPU features are implemented. It is there as debugging data for human operators, and any machine usage would treat it as an opaque blob. It is thus reasonable to expose this in QMP as 'x-query-registers' returning a 'str' field. Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-02docs/devel: update error handling guidance for HMP commandsDaniel P. Berrangé
Best practice is to use the 'hmp_handle_error' function, not 'monitor_printf' or 'error_report_err'. This ensures that the message always gets an 'Error: ' prefix, distinguishing it from normal command output. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-02docs/devel: tweak headings in monitor command docsDaniel P. Berrangé
The new headings reflect the intended structure of the document and will better suit additions that follow. Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-02docs/devel: rename file for writing monitor commandsDaniel P. Berrangé
The file already covers writing HMP commands, in addition to the QMP commands, so it deserves a more general name. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>