From: Jan Kiszka <jan.kiszka@siemens.com>
To: Avi Kivity <avi@redhat.com>
Cc: libvir-list@redhat.com, Anthony Liguori <aliguori@us.ibm.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Hollis Blanchard <hollisb@us.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Date: Thu, 09 Apr 2009 17:49:18 +0200 [thread overview]
Message-ID: <49DE18FE.30803@siemens.com> (raw)
In-Reply-To: <49DE1125.3080108@redhat.com>
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> Gerd Hoffmann wrote:
>>>
>>>> On 04/09/09 16:03, Avi Kivity wrote:
>>>>
>>>>> I don't want multiplexed monitor sessions, at all.
>>>>>
>>>> I'm very happy to finally see them. Finally one can run vms with
>>>> libvirt and *still* access the monitor for debugging and development
>>>> purposes.
>>>>
>>>>
>>> Right, I like them for that purpose as well. But not for ordinary
>>> control.
>>>
>>
>> How do you want to differentiate? What further complications would this
>> bring us?
>>
>
> 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.
>>
>> 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.
>
> 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.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-04-09 15:49 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 18:34 [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) Anthony Liguori
2009-04-08 18:34 ` [Qemu-devel] [PATCH 2/6] Introduce monitor 'wait' command (v2) Anthony Liguori
2009-04-08 18:34 ` [Qemu-devel] [PATCH 3/6] Introduce wait filtering (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 4/6] Document new events (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 5/6] Implement vm-state notifications (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 6/6] Implement vnc-event " Anthony Liguori
2009-04-08 18:43 ` [Qemu-devel] Re: [PATCH 2/6] Introduce monitor 'wait' command (v2) Anthony Liguori
2009-04-08 19:01 ` [Qemu-devel] " Blue Swirl
2009-04-08 19:02 ` Anthony Liguori
2009-04-09 11:01 ` Avi Kivity
2009-04-09 13:40 ` Anthony Liguori
2009-04-09 13:58 ` Avi Kivity
2009-04-09 14:19 ` Jan Kiszka
2009-04-09 8:19 ` [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) Avi Kivity
2009-04-09 13:28 ` Anthony Liguori
2009-04-09 13:40 ` Avi Kivity
2009-04-09 13:47 ` Anthony Liguori
2009-04-09 14:03 ` Avi Kivity
2009-04-09 14:13 ` Anthony Liguori
2009-04-09 14:28 ` Avi Kivity
2009-04-09 14:30 ` Anthony Liguori
2009-04-09 14:37 ` Avi Kivity
2009-04-09 14:57 ` Anthony Liguori
2009-04-09 15:11 ` Avi Kivity
2009-04-09 15:40 ` Anthony Liguori
2009-04-09 15:57 ` Avi Kivity
2009-04-09 16:09 ` Anthony Liguori
2009-04-09 16:30 ` Avi Kivity
2009-04-09 16:42 ` Anthony Liguori
2009-04-09 17:00 ` Avi Kivity
2009-04-09 17:40 ` Anthony Liguori
2009-04-11 16:25 ` Avi Kivity
2009-04-11 20:18 ` Anthony Liguori
2009-04-11 21:14 ` Avi Kivity
2009-04-12 18:42 ` Jamie Lokier
2009-04-14 8:30 ` [libvirt] " Daniel P. Berrange
2009-04-14 9:15 ` Avi Kivity
2009-04-14 9:17 ` Daniel P. Berrange
2009-04-14 9:29 ` Jan Kiszka
2009-04-14 9:36 ` Avi Kivity
2009-04-14 9:38 ` Avi Kivity
2009-04-14 18:21 ` Jamie Lokier
2009-04-14 18:19 ` Jamie Lokier
2009-04-16 9:03 ` Avi Kivity
2009-04-11 23:16 ` Zachary Amsden
2009-04-12 8:23 ` Zachary Amsden
2009-04-14 8:28 ` Gerd Hoffmann
2009-04-14 18:20 ` Jamie Lokier
2009-04-11 19:11 ` Avi Kivity
2009-04-11 21:47 ` Andreas Färber
2009-04-12 18:44 ` Jamie Lokier
2009-04-09 16:01 ` Jamie Lokier
2009-04-09 14:15 ` [libvirt] " Gerd Hoffmann
2009-04-09 14:19 ` Avi Kivity
2009-04-09 14:56 ` Jan Kiszka
2009-04-09 15:15 ` François Revol
2009-04-09 15:15 ` Avi Kivity
2009-04-09 15:49 ` Jan Kiszka [this message]
2009-04-09 16:01 ` Avi Kivity
2009-04-09 16:07 ` Jamie Lokier
2009-05-11 20:54 ` Hollis Blanchard
2009-05-11 21:51 ` Anthony Liguori
2009-05-12 8:48 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49DE18FE.30803@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=hollisb@us.ibm.com \
--cc=kraxel@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).