From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrqoe-00049F-CQ for qemu-devel@nongnu.org; Thu, 09 Apr 2009 05:45:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrqoZ-00045v-MK for qemu-devel@nongnu.org; Thu, 09 Apr 2009 05:44:59 -0400 Received: from [199.232.76.173] (port=56952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrqoZ-00045l-BX for qemu-devel@nongnu.org; Thu, 09 Apr 2009 05:44:55 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59220) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrqoY-0005on-Qb for qemu-devel@nongnu.org; Thu, 09 Apr 2009 05:44:55 -0400 Message-ID: <49DDC390.9040004@redhat.com> Date: Thu, 09 Apr 2009 11:44:48 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com> <1239200204-4934-2-git-send-email-aliguori@us.ibm.com> <20090408143335.GS18076@redhat.com> <49DCBCBE.6010102@redhat.com> <49DCE266.9080809@us.ibm.com> In-Reply-To: <49DCE266.9080809@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard On 04/08/09 19:44, Anthony Liguori wrote: > We want to be robust even in the face of poorly written management > apps/scripts so we need some expiration function too. Well, if you want protect against broken apps, then yes, you'll have to expire events ... > There two issues with this syntax. The first is that 'notify EVENT' > logically acts on the global event set. That's not necessarily what you > want. OK, having per-monitor events certainly makes sense. > The second issue is that there is no clear way to deliminate events > other than a new line. If we wanted to send data along with events, we > really want to be able to span multiple lines. Especially if we want > that data to be in the same format as some of the existing monitor > commands. You could get around this by introducing a new deliminator > like '.' but everyone can already handle '(qemu)'. Point. > Also, I think where the above really shines is if you're a human user > and you want to see all the events while debugging. You really don't > want to keep typing wait in the monitor. > So as a compromise, I think we need to introduce a mode where we can do > the above but I'd like to wait until after the first round of these go > in. I'm thinking along the lines of 'wait N' where N can be -1 to > signify an unlimited number of events or something like that. Hmm. Why would you want to use -- say -- "wait 3" ? It probably will be either "loop forever" or "single event" mode in practice. We might also have a "single event, but don't block if there isn't any" mode. cheers, Gerd