Daniel P. Berrangé <[email protected]> writes:

> This introduces a Monitor QOM object, with MonitorHMP and
> MonitorQMP subclasses. This is the bare minimum conversion
> of just the type declarations and replacing g_new/g_free
> with object_new/object_unref. The Monitor base class is
> abstract since only the HMP/QMP variants should ever be
> created.
>
> When created through the existing QemuOpts interfaces, the
> new internal QOM object will get assigned a dynamic ID with
> the format "compat_monitorNNN" which is the historical
> QemuOpts ID naming pattern.

Uh, sometimes the name isn't "compat_monitorNNN".

I'm not sure whether talking about QemuOpts helps or hurts here.  Let me
try not to talk about it:

  This introduces abstract QOM type "monitor", with concrete subtypes
  "monitor-hmp" and "monitor-qmp". This is the bare minimum conversion
  of just the type declarations and replacing g_new/g_free with
  object_new/object_unref.

  Command line option -monitor now creates a monitor-hmp object
  /objects/compat_monitorNNN in addition to the character device
  /chardevs/compat_monitorNNN. NNN counts up from zero.

  Exception: -monitor chardev:ID creates a monitor-hmp object
  /objects/ID, and does not create a character device.

  -qmp and -qmp-pretty work the same, except they create a monitor-qmp
  object.

  -mon now creates a monitor-hmp or monitor-qmp object /objects/ID if
  the option argument provides an ID, else /objects/compat_monitorNNN.

If you want to make the connection to QemuOpts ID, add

  Note that the object's name in /objects/ matches the QemuOpts ID when
  it exists.  The only case where it doesn't exist is -mon without ID.

Finally, point to what's coming:

  A future patch will make "monitor-hmp" and "monitor-qmp" work with
  -object and object-add.

> Signed-off-by: Daniel P. Berrangé <[email protected]>

Reply via email to