[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4554A2F9.37B0023E@redhat.com>
Date: Fri, 10 Nov 2006 11:04:09 -0500
From: Dave Anderson <anderson@...hat.com>
To: Magnus Damm <magnus.damm@...il.com>
CC: vgoyal@...ibm.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
Magnus Damm <magnus@...inux.co.jp>,
linux-kernel@...r.kernel.org, Andi Kleen <ak@....de>,
fastboot@...ts.osdl.org, Horms <horms@...ge.net.au>
Subject: Re: [PATCH 02/02] Elf: Align elf notes properly
>
> > >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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists