From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVAR7-0001jg-Cc for qemu-devel@nongnu.org; Tue, 01 Apr 2014 21:57:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVAR2-00050k-S2 for qemu-devel@nongnu.org; Tue, 01 Apr 2014 21:57:53 -0400 Received: from [59.151.112.132] (port=64903 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVAR2-00050N-D4 for qemu-devel@nongnu.org; Tue, 01 Apr 2014 21:57:48 -0400 Message-ID: <533B6DE5.8040706@cn.fujitsu.com> Date: Wed, 2 Apr 2014 09:54:45 +0800 From: qiaonuohan MIME-Version: 1.0 References: <532B51DD.8060807@de.ibm.com> <532B5607.6060206@redhat.com> <532B5B1E.4020702@de.ibm.com> <532B5D70.4030808@redhat.com> <532B62FF.9030804@redhat.com> <532C0684.90505@cn.fujitsu.com> <87mwgc28o9.fsf@blackfin.pond.sub.org> <53337CD7.90705@cn.fujitsu.com> <8761n0t4rn.fsf@blackfin.pond.sub.org> In-Reply-To: <8761n0t4rn.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="UTF-8"; format=flowed 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: Markus Armbruster Cc: Paolo Bonzini , Luiz Capitulino , Laszlo Ersek , "qemu-devel@nongnu.org" , Christian Borntraeger Hello guys, I have sent the patch, please check here: http://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg00018.html On 03/27/2014 04:38 PM, Markus Armbruster wrote: > "qiaonuohan@cn.fujitsu.com" writes: > >> On 03/27/2014 01:04 AM, Markus Armbruster wrote: >>>>>>> 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. >>>>>>> >>>>>>> Another possibility is to kill begin/length from the >>>>>>> dump-guest-memory command. >>>>>>> HMP is not stable, so if that's useful we can do it. >>>>> >>>>> AFAIK, kdump-compressed format can only be analyzed by crash-utility right >>>>> now. ELF is big but we still need it, then begin/length will help us save >>>>> time and space when only part of the memory is need. >>>>> >>>>> IMHO, a new HMP command will be a good choice and it is more simple than >>>>> making dump format 'stateful'. I am not so clear about HMP, but I think >>>>> the new HMP command can be 'dump-guest-memory-with-format', and still >>>>> base on qmp_dump_guest_memory. If you guys like it, I will send a patch >>>>> that add this command. >>> Paolo encouraged you to*break* the existing HMP command instead of >>> adding a new one. I'd like to second that. >>> . >>> >> >> Hello markus, >> >> I have finish my patch as I stated in my last mail, but something is >> wrong with my mail server, I have to wait a couple of days before >> sending the patch. You said you prefer *breaking* the existing HMP >> command. Since paging/begin/length is still usefull, would you please >> give some reason and I will consider that. > > I'm encouraging you to design a HMP command that gives you all you need. > Then call that dump-guest-memory, backward compatibility be damned. > > Would > > dump-guest-memory [-p] filename [[format] begin length] > > do? > > An alternative could be two commands: > > dump-guest-memory filename [format [begin length]] > dump-guest-memory-elf [-p] filename [begin length] > > This bakes the restriction "paging, begin and length work only with > format 'elf'" into the interface. Not sure that's a good idea, but I'm > leaving that to folks who actually know something about this dumping > business. > > If you can find better command names, go right ahead. You could pick > names that avoid incompatible change. I care about avoiding > incompatible change to exotic HMP commands even less (a lot less, in > fact) than about naming of exotic HMP commands. > > . > -- Regards Qiao Nuohan