qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 14/17] monitor: Decouple terminals


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 14/17] monitor: Decouple terminals
Date: Mon, 09 Feb 2009 09:16:20 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Jan Kiszka wrote:
Currently all registered (and activate) monitor terminals work in
broadcast mode: Everyone sees what someone else types on some other
terminal and what the monitor reports back. This model is broken when
you have a management monitor terminal that is automatically operated
and some other terminal used for independent guest inspection. Such an
additional terminal can be a multiplexed device channel or a gdb
frontend connected to QEMU's stub.

Therefor, this patch decouples the buffers and states of all monitor
terminals, allowing the user to operate them independently. The basic
idea is stolen from Jason Wessel: When starting to handle a monitor
command or some terminal event, the current monitor terminal is set to
the one associated with the underlying char device, letting all
succeeding monitor_printf show up on only this selected terminal.

There are still two asynchronous monitor writers: some error reporting
in VNC's audio_add and the log-to-monitor feature of the audio
subsystem.

That concerns me.  Nothing should output to the monitor asychronously.

I'd like to see a few changes to make things a bit closer to the long term goals for the monitor (having proper multiple monitors devoid of global state).

Here's what I'd suggest:

1) Make monitor_printf() take a monitor state. The easiest thing to do would be to introduce this in your previous rename patch making everything use current_monitor. 2) Introduce current_monitor and default_monitor global variables. They map to what you describe above and should be maintained as such.
3) Make all monitor callbacks take a monitor state
4) Convert monitor_printf()s called from monitor callbacks to use the passed monitor state
5) Eliminate all uses of current_monitor/default_monitor.

I'd say, 1 and 2 are required for this patchset. I think 3 and 4 would be pretty easy to add to your patchset. I think 5 is probably tougher and could wait for another day.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]