From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: qemu-devel@nongnu.org, linux-debuggers@vger.kernel.org,
joao.m.martins@oracle.com,
Richard Henderson <richard.henderson@linaro.org>,
Thomas Huth <thuth@redhat.com>
Subject: Re: [PATCH qemu 2/2] dump: Only use the makedumpfile flattened format when necessary
Date: Tue, 22 Aug 2023 17:31:46 -0700 [thread overview]
Message-ID: <87fs4aha4t.fsf@oracle.com> (raw)
In-Reply-To: <87edl4d9wi.fsf@oracle.com>
Stephen Brennan <stephen.s.brennan@oracle.com> writes:
> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
>> I am a bit reluctant to change the dump format by default. But since the
>> flatten format is more "complicated" than the "normal" format, perhaps we
>> can assume all users will handle it.
>>
>> The change is probably late for 8.1 though..
>
> Thank you for your review and testing!
>
> I totally understand the concern about making the change by default. I
> do believe that nobody should notice too much because the normal format
> should be easier to work with, and more broadly compatible. I don't know
> of any tool which deals with the flattened format that can't handle the
> normal format, except for "makedumpfile -R" itself.
>
> If it's a blocker, I can go ahead and add a new flag to the command to
> enable the behavior. However there are a few good justifications not to
> add a new flag. I think it's going to be difficult to explain the
> difference between the two formats in documentation, as the
> implementation of the formats is a bit "into the weeds". The libvirt API
> also specifies each format separately (kdump-zlib, kdump-lzo,
> kdump-snappy) and so adding several new options there would be
> unfortunate for end-users as well.
>
> At the end of the day, it's your judgment call, and I'll implement it
> how you prefer.
I just wanted to check back on this to clarify the next step. Are you
satisfied with this and waiting to apply it until the right time? Or
would you prefer me to send a new version making this opt-in?
Thanks,
Stephen
next prev parent reply other threads:[~2023-08-23 0:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 16:38 [PATCH qemu 0/2] dump: Only use the makedumpfile flattened format when necessary Stephen Brennan
2023-07-17 16:38 ` [PATCH qemu 1/2] dump: Pass DumpState to write_ functions Stephen Brennan
2023-07-17 18:37 ` Marc-André Lureau
2023-07-17 16:38 ` [PATCH qemu 2/2] dump: Only use the makedumpfile flattened format when necessary Stephen Brennan
2023-07-18 8:25 ` Marc-André Lureau
2023-07-19 0:26 ` Stephen Brennan
2023-08-23 0:31 ` Stephen Brennan [this message]
2023-08-23 10:03 ` Marc-André Lureau
2023-09-12 6:34 ` Marc-André Lureau
2023-09-12 7:20 ` Omar Sandoval
2023-09-12 7:21 ` Thomas Huth
2023-09-12 8:26 ` Daniel P. Berrangé
2023-09-13 7:12 ` Stephen Brennan
2023-09-13 6:38 ` Stephen Brennan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fs4aha4t.fsf@oracle.com \
--to=stephen.s.brennan@oracle.com \
--cc=joao.m.martins@oracle.com \
--cc=linux-debuggers@vger.kernel.org \
--cc=marcandre.lureau@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).