On 08/04/2009 05:47 PM, Phillip Lougher wrote:Andrew Morton wrote:On Mon, 3 Aug 2009 16:58:16 +0200
Albin Tonnerre <albin.tonnerre@xxxxxxxxxxxxxxxxxx> wrote:
These includes were added by 079effb6933f34b9b1b67b08bd4fd7fb672d16ef toThe description "actually creates issues (brings a lot of things
fix the build when using kmemtrace. However this is not necessary when
used to create a compressed kernel, and actually creates issues (brings
a lot of things unavailable in the decompression environment), so don't
include it if STATIC is defined.
unavailable in the decompression environment)" is inadequate. Please
describe te problem this patch fixes more completely so that others
(ie: me) can decide whether this patch is needed in 2.6.32, 2.6.31.
2.6.30, ...
This patch conflicts heavily with
http://userweb.kernel.org/~akpm/mmotm/broken-out/bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch
What should we do about that?
What do you normally do in this situation? I'm happy to send a revised
bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch
that would apply cleanly on-top of Alvin's patch, but, this will obviously
create dependencies on his patch being applied.
The general principle is that if A alone creates a more functional
environment than B alone, then B should be applied on top of A, and vice
versa. This is especially so if A is a stable candidate.
It *sounds* like your patch is B here, but I am not sure from the
description.