Alex Bennée <alex.ben...@linaro.org> writes: > Markus Armbruster <arm...@redhat.com> writes: > >> Alex Bennée <alex.ben...@linaro.org> writes: >> >>> Markus Armbruster <arm...@redhat.com> writes: >>> >>>> Mario Fleischmann <mario.fleischm...@lauterbach.com> writes: >>>> >>>>> Apologies for the line wrapping in yesterday's answer. Should be fixed >>>>> now. >>>>> >>>>> On 08.04.2025 09:00, Markus Armbruster wrote: >> >> [...] >> >>>>>> What about providing the MCD interface as a separate QMP-like protocol? >>>>>> It gets its own QAPI schema, just like for qemu-ga. Simplifies >>>>>> compiling it out when not needed. >>>>>> >>>>>> It gets its own socket, just like the GDB stub. Might reduce >>>>>> interference between debugging and QMP. >>>>>> >>>>>> Thoughts? Alex, Philippe, care to chime in? >>>>> >>>>> Sound reasonable to me. Keeping in mind the size of generated QAPI code, >>>>> an option to `./configure [...] --enable-mcd` is definitely advisable. >>>> >>>> Alex, Philippe? >>> >>> When I spoke to Mario at DVCon last year I liked the idea of re-using >>> QMP instead of inventing yet another RPC interface for QEMU. QMP >>> certainly has nicer properties than the gdbstub which has a very >>> "organic" and "serial" feel to it. >>> >>> Are you suggesting we re-use the machinery but use an entirely separate >>> socket with just the MCD namespace in it? I don't see that being a >>> problem as long as we can test it properly in the CI. >> >> Yes. >> >> "Keep them separate" is only a gut feeling, though. While I pay >> attention to my gut feelings, I know they can be wrong. I am soliciting >> opinions. > > I forgot to add isn't the flexibility of the QMP API something we need > to handle for single binary anyway?
I have no idea :) Evolving a target-dependent interface into a target-independent interface without breaking compatibility is always a bother. It's likely more of a bother when the interface is binary. Textual interfaces tend to have less target-dependence. Designing a target-independent interface is probably easier than evolving it compatibly from a target-dependent one. QMP is textual, and it's designed for certain kinds of compatible evolution. Using QAPI/QMP for a debugging interface may be a perfectly sensible idea. I don't know enough about debugging interfaces to judge. Use of QAPI/QMP does not imply use of the QMP monitor. We can keep the monitor and the debugging interface separate even though both are based on QAPI/QMP. The monitor code is gnarly, I'm afraid. It supports multiple monitors, but they are not fully independent for historical reasons, chiefly implied mutual exclusion for commands. Adding a QAPI/QMP-based debugging interface without undue coupling to monitors may pose a few technical problems. One way to find out.
