From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNqaZ-0002Uh-QV for qemu-devel@nongnu.org; Fri, 16 Jan 2009 10:26:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNqaY-0002St-Dh for qemu-devel@nongnu.org; Fri, 16 Jan 2009 10:26:27 -0500 Received: from [199.232.76.173] (port=44713 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNqaY-0002Sj-6V for qemu-devel@nongnu.org; Fri, 16 Jan 2009 10:26:26 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:58254) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNqaX-0005Cf-UB for qemu-devel@nongnu.org; Fri, 16 Jan 2009 10:26:26 -0500 Received: by qyk13 with SMTP id 13so2516113qyk.10 for ; Fri, 16 Jan 2009 07:26:25 -0800 (PST) Message-ID: <4970A715.7020009@codemonkey.ws> Date: Fri, 16 Jan 2009 09:26:13 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] optionally specify vm stop message References: <20090115103733.GA11299@redhat.com> <496FA08E.4060806@codemonkey.ws> <20090116071437.GB27165@redhat.com> In-Reply-To: <20090116071437.GB27165@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Gleb Natapov wrote: > On Thu, Jan 15, 2009 at 02:46:06PM -0600, Anthony Liguori wrote: > >> Gleb Natapov wrote: >> >>> Should be applied on top of ENOSPC series. >>> >>> >> How about just adding a new vm_stop reason? That will work out better >> when we introduce the improved monitor. >> >> > We may want to specify different message for the same reason. For > instance we may want to print the name of the file we failed to write > to. I'm thinking about this from a management tool perspective. When we have a better monitor interface, this would generate an async notification. Instead of generating an arbitrary string, it could send a reason code that has a well defined meaning. For now, within vm_stop, it can say if (reason == VM_STOP_ENOSPC) printf("ran out of space"); or something. There are other places we stop a vm, like when -no-shutdown is used, where using a reason code would be very useful. > Also non zero reasons a handled differently by vm_stop. Don't know > why. > It's an ugly hack for gdbstub. It notifies gdb when a breakpoint occurs. We have far too many state tracking mechanisms. Anyway, gdb can pass something like VM_STOP_BP and that can be used to trigger the callback. Regards, Anthony Liguori > -- > Gleb. > > >