[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

Avi Kivity avi at redhat.com
Thu Apr 9 16:01:06 UTC 2009

Jan Kiszka wrote:
>> I'm not sure I understand your questions.  Multiple monitor sessions are
>> like multiple shell sessions.  I don't think a control program should
>> use more than one session, but it should allow a developer to connect to
>> issue 'info registers' and 'x/20i' commands.  Of course if a developer
>> issues 'quit' or a hotunplug command, things will break.
> We agree if we want decoupled states of the monitor sessions (one
> session should definitely not be used to configure the output of another
> one). But I see no issues with collecting the events in one session that
> happen to be caused by activity in some other session. But maybe I'm
> missing your point.

The management application will still think the device is plugged in, 
and things will break if it isn't.

Of course if you asked for notification X on session Y, then event X 
should be delivered to session Y no matter how it originated (but not to 
session Z).

>>> Please no more async notifications to the monitors. They are just ugly
>>> to parse, at least for us humans. I don't want to see any notification
>>> in the middle of my half-typed command e.g.
>> If we can identify an interactive session, we might redraw the partial
>> command after the prompt.
> Uhh, please not this kind of terminal reprinting. The terminal user keep
> full control over when things can be printed.

Very well.  I guess a human user can open another session for 
notifications, if they are so inclined.

>> btw, why would a human enable notifications?  Note notifications enabled
>> on the management session will only be displayed there.
> It's true that the common use case for events will be monitor
> applications. Still, enabling them for testing or simple scripting
> should not switch on ugly output mode or complicate the parsing.

Fair enough.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

More information about the libvir-list mailing list