Hi On Sat, Sep 4, 2021 at 10:26 AM Markus Armbruster <arm...@redhat.com> wrote:
> Doug Evans <d...@google.com> writes: > > > 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 see. > > > 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. > > Demonstrates "is of use only for human users" is wrong. > > > Presumably we don't want to print text in slirp only to parse it in qemu, > > right? > > Yes, we'd prefer not to parse. > > As long as libslirp can only give us text, we need to parse it > somewhere. > > We can parse it right in QEMU, or punt the job to whatever uses QEMU. > The latter can get away with parsing just the part they need. But we > may end up with multiple parsers. > > > > 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? > > This is a question for Samuel or Marc-André. > > If the answer is "no", then HMP only (so we don't have to parse in QEMU) > is fair, I think. The commit message should explain this. > > Until now, libslirp (& QEMU HMP) provided inner state details as textual form. But since there is a need for a programming-friendly API, it could be added to libslirp and exported as QAPI/QMP by QEMU. Let's try to design the API in a way that can be easily extended (via getters and/or keys etc). Alternatively, libslirp could dump its state as JSON, but this wouldn't fit so nicely with QMP machinery/introspection etc.
