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

[Luiz Capitulino]

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?
       - Having QMP and HMP using different chardevs, probably means that we
         won't be share coding as much as possible
       - 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
       - 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)
       - Not sure if HMP features like command completion will perfectly fit