Re: [Qemu-devel] RFC: Monitor high-level design

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> Hi there,
>
> I was working on a detailed writeup about monitor's internals so that I could
> get some guidance regarding monitor's internal design, but after today's call
> I realized that we should discuss the general design first.
>
> I think we have two options: the first (and better known) is to make HMP
> (the human monitor) a QMP client. The other option would be to make QMP and
> HMP monitor implementations.
>
> Below I try to introduce both ideas, showing advantages and potential 
> problems.
> I've also tried drawing some nice diagrams. Please, be polite and appreciate
> them whether you agree or not :-)
>
>  1. HMP as a QMP client
>
>     Very briefly, QMP would export a function called qmp_command(), which 
> would
>     be called by HMP handlers. This has been proposed by Anthony and a
>     detailed description can be found at:
>
>         http://wiki.qemu.org/Features/QMP_0.14#Potential_Solutions
>
>     When fully implemented, I think it would look like this:
>
>                     |-----|
>                     | HMP |
>                     |-----|
>                       /  \
>                      /    \
>                  |-----|   \
>                  | QMP |    \
>                  |-----|     \
>                     |         \
>                     |          \
>                |---------|  |---------|
>                | chardev |  | chardev |
>                |---------|  |---------|
>
>      HMP will need to handle its own chardev, so that it's able to output
>      data to the user (and I guess command completion needs it too).
>
>      However, it's important to notice that HMP won't be using QMP's chardev
>      in any way. It's only there to show that QMP and HMP will handle their
>      own chardevs.
>
>     Advantages:
>
>        - QMP's interface is also used (and thus tested) internally
>        - In theory HMP can be moved outside of QEMU
>
>     Disadvantages/problems:
>
>        - What to do with handlers that make no sense in QMP, like print,
>          sum, etc?

I can't see why we must have a dogmatic "thou shalt not use anything but
QMP to implement HMP commands, ever" rule.

>        - Having QMP and HMP using different chardevs, probably means that we
>          won't be share coding as much as possible

I don't understand how the two chardevs in your picture are used.

>        - Isn't HMP pasthrough via QMP going to break this design? I think it
>          will, because QMP will have to make a sort of HMP call too
>
>  2. QMP and HMP as monitor implementations
>
>     In this design we have to define an internal monitor API, something like
>     struct monitor_ops. Which is implemented by both, QMP and HMP. Common
>     monitor code is moved behind this API, making QMP and HMP implementation
>     simpler. Also allows to have new kinds of Monitors.
>
>     Drawing:
>
>               |-----|    |-----|
>               | QMP |    | HMP |
>               |-----|    |-----|
>                 \           /
>                  \         /
>                   \       /
>                    \     /
>               |----------------|
>               | monitor common |
>               |----------------|
>                       |
>                       |
>                       |
>               |---------------|
>               | char devices  |
>               |---------------|
>
>    There's a small lie there: HMP will have to make QMP calls with 
> qmp_command()
>    which doesn't make those modules totally isolated. But I believe this could
>    be done via monitor common someway.
>
>    Advantages:
>
>        - We can take coding sharing to the limit, even allowing the creation
>          of new, idepedent monitors
>        - We can have HMP-only handlers (like print, sum, etc)
>
>    Disadvantages:
>
>        - HMP calls to QMP will break a bit the design
>        - HMP passthrough makes things ugly again, because we'll have each
>          module talking to each other

Maybe that's only because your picture is oversimplified.  See below.

>        - HMP can't be moved outside of QEMU, if we want that we'd have to
>          write a new Monitor client (potentially in a different language,
>          which is actually good)

I'd rather not worry about that now.

>        - Not sure if HMP features like command completion will perfectly fit

Maybe I'm naive, but I figure that as long as the human monitor controls
its character device and knows enough about its own commands, it can do
completion pretty much the same way it does now.


Let's have a closer look at the human monitor:

    +---------------+   reads/writes
    | human monitor | <--------------->  character device
    +---------------+                          ^
            |                                  |
            | calls                            |
            |                                  |
            v                                  |
    +---------------+        writes            |
    | hmon handlers | -------------------------+
    +---------------+              

The "human monitor" box actually has identifiable sub-boxes:

* Command table: human monitor command description

* Several argument types: methods to parse, check, complete, ...

* Reader: read a line of input from character device

  - Readline, uses table for completion

* Parser: parse a line of input, uses table to parse arguments

* Executor: call the appropriate handler, uses table

The machine monitor (short: qmon) is pretty similar, actually.
Differences:

* We read and parse JSON objects, not lines.

* We don't bother to set up completion.

* The qmon handlers don't write to the character device.  They return
  objects instead, to be written by the qmon executor.

Remember that we want qmon handlers to use proper internal interfaces to
do the real work.  In other words, qmon handlers should be fairly
trivial.

I can think of three ways to write a human monitor handler:

1. Call a qmon handler, print the object it returns, suitably formatted.

2. Call the internal interfaces, just like qmon handlers do.  Print the
   results.

   This cut out the qmon handler middle-man.  Since the qmon handler is
   supposed to be trivial, this isn't a big deal.

3. Just do it.  I think that's fine for some commands that make sense
   only human monitor, like print.  Also fine for legacy commands
   scheduled for removal; we got more useful things to do than
   beautifying those.  The ones we want to keep we should convert to
   1. or 2.  Doing that early may be advisable to get the internal
   interfaces used, but it's not like "need to convert everything before
   anything works".

You see hmon doesn't use all of qmon, only qmon handlers, and even that
only with 1.  Can't see a layering issue there.

Now consider human command pass-through.  The qmon handler for the
pass-through command needs to pass a command string to a human monitor,
and capture its output to the character device.  Thus, it needs to use
hmon parser and executor, with a special character device to capture
output.

There is no dependency cycle, because only the pass-through handler
depends on (parts of) hmon, and while hmon may depend on some qmon
handlers, the pass-through handler is not among them.