From: Thomas Huth <thuth@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Stephen Brennan" <stephen.s.brennan@oracle.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, linux-debuggers@vger.kernel.org,
joao.m.martins@oracle.com,
Richard Henderson <richard.henderson@linaro.org>,
Janosch Frank <frankja@linux.ibm.com>
Subject: Re: [PATCH qemu 2/2] dump: Only use the makedumpfile flattened format when necessary
Date: Tue, 12 Sep 2023 09:21:49 +0200 [thread overview]
Message-ID: <b614f33c9fcc461f8099a11b97af4340ceb4cf1a.camel@redhat.com> (raw)
In-Reply-To: <CAJ+F1CK0PTM-wHaK90EiuvvsG5OBVXQ4X8iV-AbBxdc6_=RvPQ@mail.gmail.com>
On Tue, 2023-09-12 at 10:34 +0400, Marc-André Lureau wrote:
> Hi
>
> On Wed, Aug 23, 2023 at 2:03 PM Marc-André Lureau
> <marcandre.lureau@gmail.com> wrote:
> >
> > Hi
> >
> > On Wed, Aug 23, 2023 at 4:31 AM Stephen Brennan
> > <stephen.s.brennan@oracle.com> wrote:
> > >
> > > 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?
> > >
> >
> > Nobody seems to raise concerns. If it would be just me, I would
> > change
> > it. But we should rather be safe, so let's make it this opt-in
> > please.
> >
> >
>
> Alex, Daniel, Thomas .. Do you have an opinion on changing the dump
> format?
I just double-checked with Janosch Frank, and from s390x perspective
we're mostly interested in the ELF dump format, so from the s390x side
of view: ¯\_(ツ)_/¯
Thomas
next prev parent reply other threads:[~2023-09-12 7:22 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
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 [this message]
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=b614f33c9fcc461f8099a11b97af4340ceb4cf1a.camel@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=frankja@linux.ibm.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=stephen.s.brennan@oracle.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).