Doug Evans <dje@google.com> writes:
> This command dumps the ARP and NDP tables maintained within slirp.
> One use-case for it is showing the guest's IPv6 address(es).
>
> Signed-off-by: Doug Evans <dje@google.com>
> ---
> hmp-commands-info.hx | 15 +++++++
> include/net/slirp.h | 1 +
> net/slirp.c | 15 +++++++
> tests/acceptance/info_neighbors.py | 69 ++++++++++++++++++++++++++++++
> 4 files changed, 100 insertions(+)
> create mode 100644 tests/acceptance/info_neighbors.py
Standard request for new HMP commands without corresponding QMP
commands: please state in the commit message why the QMP command is not
worthwhile.
HMP commands without a QMP equivalent are okay if their functionality
makes no sense in QMP, or is of use only for human users.
Example for "makes no sense in QMP": setting the current CPU, because a
QMP monitor doesn't have a current CPU.
Examples for "is of use only for human users": HMP command "help", the
integrated pocket calculator.
Debugging commands are kind of borderline. Debugging is commonly a
human activity, where HMP is just fine. However, humans create tools to
assist with their activities, and then QMP is useful. While I wouldn't
encourage HMP-only for the debugging use case, I wouldn't veto it.
Mostly I was following what I saw for "info usernet".
I don't see a difference between "info neighbors" and "info usernet" so I went with that.
Both draw their data from libslirp.
I'm happy to add QMP support if necessary.
Note that there is code that parses "info usernet" output, e.g., get_info_usernet_hostfwd_port for python.
Presumably we don't want to print text in slirp only to parse it in qemu, right?
That'll change the qemu/slirp interface.
OTOH, to what extent does libslirp want to export a more formal API for this, vs just text?