On Fri, Sep 3, 2021 at 6:08 AM Markus Armbruster <arm...@redhat.com> wrote:
> Doug Evans <d...@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 <d...@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?
