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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/21/2010 01:46 PM, Luiz Capitulino wrote:
> 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
>    

3. Introduce a BufferCharDriverState

This is a chr that works entirely based on in-memory buffers.  To 
execute a human monitor command, create a BufferCharDriverState, 
populate the input buffer, then create a new Monitor with this chr.  
Then we can simply parse the output buffer to determine when the command 
is complete.  When it's complete, destroy the monitor.

Likewise, we can do the same thing for QMP.

We sort of already do this for gdbstub's monitor integration FWIW.

Regards,

Anthony Liguori