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
