From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQkGn-0004CI-8f for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:13:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQkGd-0007nz-IL for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:12:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQkGd-0007nm-AO for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:12:47 -0400 Message-ID: <532B59C6.5060001@redhat.com> Date: Thu, 20 Mar 2014 22:12:38 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <532B51DD.8060807@de.ibm.com> <532B5607.6060206@redhat.com> In-Reply-To: <532B5607.6060206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] hmp interface for kdump compressed format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , qiaonuohan Cc: "qemu-devel@nongnu.org" , Luiz Capitulino Two additional points: On 03/20/14 21:56, Laszlo Ersek wrote: > On 03/20/14 21:38, Christian Borntraeger wrote: >> Qiao Nuohan, >> >> is there a reason why you did not implemented the HMP part for that format >> of kdump compressed format? After all this is a patch mostly for developers, >> so a HMP interface might come handy. Do you already have some patch in >> preparation or know somebody doing it? > > http://thread.gmane.org/gmane.comp.emulators.qemu/249283/focus=250059 - HMP interface could be implemented as a fully new command of course, - the feature being targeted at developers strikes me as a completely unexpected idea. The main goal in my understanding is to allow the management layer (libvirt) to save a compressed vmcore when the guest panicks, crashes, or the admin feels like it. For communication with another program, QMP is actually preferable. So I'm certainly not against anyone adding a HMP interface too, but it cannot be an extension to the current HMP command (because it would break existing HMP command lines unless the HMP parser were reworked too), plus during review I saw no reason to stall the series even longer, for a side feature that I perceived to be of low importance (and I actually thought that Qiao Nuohan shared that notion). Thanks Laszlo