* [Qemu-devel] RFC: Monitor high-level design
@ 2010-09-21 18:46 Luiz Capitulino
2010-09-21 19:08 ` [Qemu-devel] " Anthony Liguori
2010-09-22 12:32 ` [Qemu-devel] " Markus Armbruster
0 siblings, 2 replies; 6+ messages in thread
From: Luiz Capitulino @ 2010-09-21 18:46 UTC (permalink / raw)
To: qemu-devel; +Cc: Avi Kivity, Markus Armbruster
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Qemu-devel] Re: RFC: Monitor high-level design 2010-09-21 18:46 [Qemu-devel] RFC: Monitor high-level design Luiz Capitulino @ 2010-09-21 19:08 ` Anthony Liguori 2010-09-22 12:32 ` [Qemu-devel] " Markus Armbruster 1 sibling, 0 replies; 6+ messages in thread From: Anthony Liguori @ 2010-09-21 19:08 UTC (permalink / raw) To: Luiz Capitulino; +Cc: Markus Armbruster, qemu-devel, Avi Kivity 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] RFC: Monitor high-level design 2010-09-21 18:46 [Qemu-devel] RFC: Monitor high-level design Luiz Capitulino 2010-09-21 19:08 ` [Qemu-devel] " Anthony Liguori @ 2010-09-22 12:32 ` Markus Armbruster 2010-09-22 13:18 ` Anthony Liguori 1 sibling, 1 reply; 6+ messages in thread From: Markus Armbruster @ 2010-09-22 12:32 UTC (permalink / raw) To: Luiz Capitulino; +Cc: qemu-devel, Avi Kivity Luiz Capitulino <lcapitulino@redhat.com> 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] RFC: Monitor high-level design 2010-09-22 12:32 ` [Qemu-devel] " Markus Armbruster @ 2010-09-22 13:18 ` Anthony Liguori 2010-09-22 15:03 ` Luiz Capitulino 0 siblings, 1 reply; 6+ messages in thread From: Anthony Liguori @ 2010-09-22 13:18 UTC (permalink / raw) To: Markus Armbruster; +Cc: Avi Kivity, qemu-devel, Luiz Capitulino On 09/22/2010 07:32 AM, Markus Armbruster wrote: > Luiz Capitulino<lcapitulino@redhat.com> 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. > FWIW, print/sum can be easily implemented in terms of QMP commands. It's not really necessary for every possibly HMP command to be implemented in terms of QMP. However, unless you can do everything in QMP that you can do in HMP, then people will be inclined to use HMP as a management interface. So, the only real rule we should try to adopt is that QMP is at least as powerful as HMP. That should be our goal. >> - 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. > Yeah, I think what you describe makes perfect sense. As long as QMP is a thin wrapper around an API, and HMP also calls the API, then it's pretty clear that QMP is at least as powerful as HMP. There might be a few weird commands that are just open coded in HMP. I don't think we should have a hard rule to avoid it but at the same time, it should be an exception. Regards, Anthony Liguori > 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. > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] RFC: Monitor high-level design 2010-09-22 13:18 ` Anthony Liguori @ 2010-09-22 15:03 ` Luiz Capitulino 2010-09-22 15:39 ` Anthony Liguori 0 siblings, 1 reply; 6+ messages in thread From: Luiz Capitulino @ 2010-09-22 15:03 UTC (permalink / raw) To: Anthony Liguori; +Cc: Avi Kivity, Markus Armbruster, qemu-devel On Wed, 22 Sep 2010 08:18:10 -0500 Anthony Liguori <anthony@codemonkey.ws> wrote: > On 09/22/2010 07:32 AM, Markus Armbruster wrote: [...] > > I can't see why we must have a dogmatic "thou shalt not use anything but > > QMP to implement HMP commands, ever" rule. I based most of my ideas on what Anthony has described at: http://wiki.qemu.org/Features/QMP_0.14 But that's more like a start point, of course that we shouldn't be dogmatic, specially when we have better ideas. > FWIW, print/sum can be easily implemented in terms of QMP commands. Yes, but I think the point is when/if we should do it. > It's not really necessary for every possibly HMP command to be > implemented in terms of QMP. However, unless you can do everything in > QMP that you can do in HMP, then people will be inclined to use HMP as a > management interface. s/use HMP/use QMP > So, the only real rule we should try to adopt is that QMP is at least as > powerful as HMP. That should be our goal. Agreed. > >> - 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. Yes, that's right. > > 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. That's the 'is pretty similar' part I was referring to when I said (by IRC I guess) that qmon and hmon can share the device handling code. > > 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. Yes and note that we have 1 and 3 today already. > Yeah, I think what you describe makes perfect sense. As long as QMP is > a thin wrapper around an API, and HMP also calls the API, then it's > pretty clear that QMP is at least as powerful as HMP. Ok, let me get into two details: 1. The BufferCharDriverState is only going to be used for human monitor passthrough, right? 2. As Markus described above, QMP and HMP perform similar internal steps, so what about having them behind a common interface, like this: struct monitor_ops { const char *name; int (*init)(void *opaque); void (*exit)(void *opaque); int (*can_read)(void *opaque); void (*read)(void *opaque, const uint8_t *buf, int size); void (*event)(void *opaque, int event); void (*async_message)(void *opaque, MonitorEvent, QObject *data); }; Then monitor.c code would register itself with the chardev layer, calling each monitor's monitor_ops. Note that we already have a feature request to be able to create new monitors on demand. I believe such design will help. Is this overkill? Does anyone have better ideas on how both modules (QMP/HMP) should be designed/separated? Sketches are welcome. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] RFC: Monitor high-level design 2010-09-22 15:03 ` Luiz Capitulino @ 2010-09-22 15:39 ` Anthony Liguori 0 siblings, 0 replies; 6+ messages in thread From: Anthony Liguori @ 2010-09-22 15:39 UTC (permalink / raw) To: Luiz Capitulino; +Cc: Avi Kivity, Markus Armbruster, qemu-devel On 09/22/2010 10:03 AM, Luiz Capitulino wrote: > On Wed, 22 Sep 2010 08:18:10 -0500 > Anthony Liguori<anthony@codemonkey.ws> wrote: > > >> On 09/22/2010 07:32 AM, Markus Armbruster wrote: >> > [...] > > >>> I can't see why we must have a dogmatic "thou shalt not use anything but >>> QMP to implement HMP commands, ever" rule. >>> > I based most of my ideas on what Anthony has described at: > > http://wiki.qemu.org/Features/QMP_0.14 > > But that's more like a start point, of course that we shouldn't be dogmatic, > specially when we have better ideas. > > >> FWIW, print/sum can be easily implemented in terms of QMP commands. >> > Yes, but I think the point is when/if we should do it. > > >> It's not really necessary for every possibly HMP command to be >> implemented in terms of QMP. However, unless you can do everything in >> QMP that you can do in HMP, then people will be inclined to use HMP as a >> management interface. >> > s/use HMP/use QMP > > >> So, the only real rule we should try to adopt is that QMP is at least as >> powerful as HMP. That should be our goal. >> > Agreed. > > >>>> - 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. >>> > Yes, that's right. > > >>> 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. >>> > That's the 'is pretty similar' part I was referring to when I said (by IRC > I guess) that qmon and hmon can share the device handling code. > > >>> 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. >>> > Yes and note that we have 1 and 3 today already. > > >> Yeah, I think what you describe makes perfect sense. As long as QMP is >> a thin wrapper around an API, and HMP also calls the API, then it's >> pretty clear that QMP is at least as powerful as HMP. >> > Ok, let me get into two details: > > 1. The BufferCharDriverState is only going to be used for human monitor > passthrough, right? > Well, I think the pointer Markus raised is that there are two ways to implement HMP in terms of QMP. One of them is to do: static void do_commit(Monitor *mon, const char *device) { QObject *res; res = qmp_command("commit", "{'device': %s}", device); if (qobject_is_qerror(res)) { monitor_printf(mon, "commit: %s\n", qerror_to_str(qobject_to_qerror(res))); return; } } And the second way is: static void do_commit(Monitor *mon, const char *device) { Error *err = NULL; qpi_commit(device, &err); if (err) { monitor_printf(mon, "commit: %s\n", error_to_str(err); error_free(err); } } Which takes advantage of the notion that all QMP commands are expressed as proper C interfaces internally. Under the covers, qpi_commit() could be a direct API call or it could even be a QMP client RPC interface. As long as qpi_commit(...) maps directly to qmp_command("commit", ...) it's all equivalent. There's definitely an elegance to the second approach. Regards, Anthony Liguori > 2. As Markus described above, QMP and HMP perform similar internal steps, > so what about having them behind a common interface, like this: > > struct monitor_ops { > const char *name; > int (*init)(void *opaque); > void (*exit)(void *opaque); > int (*can_read)(void *opaque); > void (*read)(void *opaque, const uint8_t *buf, int size); > void (*event)(void *opaque, int event); > void (*async_message)(void *opaque, MonitorEvent, QObject *data); > }; > > Then monitor.c code would register itself with the chardev layer, calling > each monitor's monitor_ops. > > Note that we already have a feature request to be able to create new monitors > on demand. I believe such design will help. > > Is this overkill? Does anyone have better ideas on how both modules (QMP/HMP) > should be designed/separated? > > Sketches are welcome. > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-22 15:40 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-21 18:46 [Qemu-devel] RFC: Monitor high-level design Luiz Capitulino 2010-09-21 19:08 ` [Qemu-devel] " Anthony Liguori 2010-09-22 12:32 ` [Qemu-devel] " Markus Armbruster 2010-09-22 13:18 ` Anthony Liguori 2010-09-22 15:03 ` Luiz Capitulino 2010-09-22 15:39 ` Anthony Liguori
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).