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 to >>> 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. >>> >> >> The description "actually creates issues (brings a lot of things >> 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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
