From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQkVq-0003Gc-IE for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:28:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQkVl-0004fY-IY for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:28:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQkVl-0004fU-AS for qemu-devel@nongnu.org; Thu, 20 Mar 2014 17:28:25 -0400 Message-ID: <532B5D70.4030808@redhat.com> Date: Thu, 20 Mar 2014 22:28:16 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <532B51DD.8060807@de.ibm.com> <532B5607.6060206@redhat.com> <532B5B1E.4020702@de.ibm.com> In-Reply-To: <532B5B1E.4020702@de.ibm.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 On 03/20/14 22:18, Christian Borntraeger wrote: > On 20/03/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 >> >> Laszlo >> > So in essence: Due to the limitations of the command line parser we cannot > add the format to the hmp command line. > So something like adding > > dump_guest_memory_set_format > > would be the only possible solution with the hmp code as is. Correct? Yes, one possibility would be to make the dump command stateful (= compression format), and to add a new command setting/getting that state. Another option would be to leave the current command intact, and add an independent command that wouldn't take "begin", "end", nor "paging", but would take compression format. > (If adding such a command is nice or not is another question) Yep. Thanks Laszlo