Alex Bennée <alex.ben...@linaro.org> writes: > Mario Fleischmann <mario.fleischm...@lauterbach.com> writes: > >> On 08.04.2025 16:37, Markus Armbruster wrote:
[...] >>> 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. >> >> If I understand you correctly, when QAPI-MCD runs on a separate socket >> without using a monitor, it's still coupled to the monitor code >> internally? Does this have an influence on the either the usage of a >> monitor or the MCD interface or is it rather an implementation detail? > > An implementation detail - we should try and avoid needless coupling if > we can though. > > AFAIK not all monitor commands map to QMP equivalents but I'm not sure > if that's true the other way around - can you do everything you can over > QMP under HMP? If you don't have to then that implies we can over a > separate schema on a debug socket that doesn't need monitor bits tied > in. Ideally, HMP commands are human-friendly wrappers around QMP commands. Such commands can't do anything that could be done with QMP. Not all the functionality of QMP needs to be exposed in HMP. Some functionality might only exist in QMP. How much to expose is a pragmatic "is it worth the bother?" decision. Certain HMP commands make no sense in QMP. Examples: * HMP cpu sets the default CPU. The concept doesn't exist in QMP. * Ad hoc debugging commands that are used only by humans, such as sync-profile. * The desk calculator[*] My abstract mental model of MCD has it completely separate from monitors (HMP and QMP). Just like gdbstub. We're considering to use QAPI/QMP as interface definition and transport infrastructure. Mario's patches do that in a simple way: by "embedding" MCD in the QMP monitor. This creates a coupling that doesn't exist in my abstract mental model. We could have a separate QAPI schema for interface definition, and a separate socket for transport. This avoids coupling. Obviously, we'd still want to reuse existing QMP infrastructure as much as practical. Some of that that code is gnarly. If we're not careful, we get some subtle coupling deep under the hood. Here's one possible complication. While we can have any number of QMP monitors, we still funnel most[**] commands to the main loop thread, where they run one after the other. If we reuse all that machinery for MCD, we end up forcing MCD commands through the same funnel to the main loop thread. This coupling could be undesirable. Before we contemplate how to press the existing QMP infrastructure into service for MCD, we should first figure out how we'd want MCD to operate if we started on a green field. Can we have more than one MCD connection? Which thread should execure MCD commands? Any locking requirements? Any need for asynchronous commands? [*] Which arguably makes no sense in HMP either. [**] Not out-of-band commands. You probably don't want to know more.
