From: Dave Anderson <anderson@redhat.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: vgoyal@in.ibm.com, "Eric W. Biederman" <ebiederm@xmission.com>,
Magnus Damm <magnus@valinux.co.jp>,
linux-kernel@vger.kernel.org, Andi Kleen <ak@muc.de>,
fastboot@lists.osdl.org, Horms <horms@verge.net.au>
Subject: Re: [PATCH 02/02] Elf: Align elf notes properly
Date: Fri, 10 Nov 2006 11:04:09 -0500 [thread overview]
Message-ID: <4554A2F9.37B0023E@redhat.com> (raw)
In-Reply-To: 20061110144922.GA8155@in.ibm.com
>
> > >Therefore we use 4 byte alignment unless it can be shown that the
> > >linux core dumps are a fluke and should be fixed.
> >
> > Ok. Vivek, Dave, anyone? Comments?
> >
>
> IMHO, I think we should go by the specs (8byte boundary alignment on 64bit
> platforms) until and unless it can be proven that specs are wrong. This
> probably will mean that we will break things for sometime (until and unless
> it is fixed in tool chain and probably will also break the capability to use
> an older kernel for capturing dump). But that's unavoidable if we want to be
> compliant to specs.
>
> Thanks
> Vivek
IMHO, why break things if it's not necessary? As I understand it, you can
still take the course of least resistance and implement 64-bit xen/kdump
vmcores with 4-byte alignment -- and everybody's happy, right?
Unlike other tools that could potentially be broken, the crash utility will have
to maintain backwards compatibility for all the other 4-byte aligned 64-bit
vmcores out there. So to me, it's more a PITA than anything else, and
I'll just adapt it to whatever's out there...
Thanks,
Dave
next prev parent reply other threads:[~2006-11-10 16:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 10:19 [PATCH 01/02] Elf: Always define elf_addr_t in linux/elf.h Magnus Damm
2006-11-02 10:19 ` [PATCH 02/02] Elf: Align elf notes properly Magnus Damm
2006-11-09 14:00 ` Eric W. Biederman
2006-11-10 0:50 ` Horms
2006-11-10 4:00 ` Magnus Damm
2006-11-10 23:37 ` Jeremy Fitzhardinge
2006-11-10 23:39 ` David Miller
2006-11-11 0:26 ` Jeremy Fitzhardinge
2006-11-11 0:43 ` David Miller
2006-11-11 1:20 ` Jeremy Fitzhardinge
2006-11-13 2:16 ` Magnus Damm
2006-11-13 3:03 ` Eric W. Biederman
2006-11-13 0:23 ` Horms
2006-11-13 1:47 ` David Miller
2006-11-10 3:52 ` Magnus Damm
2006-11-10 5:09 ` Eric W. Biederman
2006-11-10 6:53 ` Magnus Damm
2006-11-10 14:49 ` Vivek Goyal
2006-11-10 16:04 ` Dave Anderson [this message]
2006-11-10 16:10 ` Eric W. Biederman
2006-11-10 23:39 ` Jeremy Fitzhardinge
2006-11-02 10:43 ` [PATCH 01/02] Elf: Always define elf_addr_t in linux/elf.h Jakub Jelinek
2006-11-02 10:51 ` Magnus Damm
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=4554A2F9.37B0023E@redhat.com \
--to=anderson@redhat.com \
--cc=ak@muc.de \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=magnus@valinux.co.jp \
--cc=vgoyal@in.ibm.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