Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
On Mon, 3 Aug 2009 16:58:16 +0200 Albin Tonnerre albin.tonne...@free-electrons.com 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? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
On Mon, 3 Aug 2009 16:58:17 +0200 Albin Tonnerre albin.tonne...@free-electrons.com wrote: When unaligned accesses are required for uncompressing a kernel (such as for LZO decompression on ARM in a patch that follows), including linux/kernel.h causes issues as it brings in a lot of things that are not available in the decompression environment. However, those files apparently use nothing from linux/kernel.h, all they need is the declaration of types such as u32 or u64, so linux/types.h should be enough Again, please provide a full description of thes issues which a patch addresses so that the patch's importance can be understood by others, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Add support for LZO-compressed kernels
On Mon, 3 Aug 2009 16:58:18 +0200 Albin Tonnerre albin.tonne...@free-electrons.com wrote: This is the first part of the lzo patch Please pass this patch (and all others!) through scritps/checkpatch.pl. checkpatch reports a number of trivial errors which you wouldn't have included had you known about them. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Friday 31 July 2009, Pierre Ossman wrote: Restoring back the system state from MMC after a successful hibernation http://marc.info/?t=12481853473r=1w=2 I don't agree with this approach. The point of the workqueue is so that the kernel can do things in parallel, so this patch is a step back. The problem is really with how the kernel doesn't properly cope with asynchronous disk scanning during bootup. The root_delay parameter was added for this for the normal case, but it seems more work is needed. Doesn't handing of resumes needs more attention overall? Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't resume at all well the last time I checked ... mounted file systems (not just root) made trouble. Hardware that reliably reports card insert/remove was rude in the same ways. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
Andrew Morton wrote: On Mon, 3 Aug 2009 16:58:16 +0200 Albin Tonnerre albin.tonne...@free-electrons.com 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. Phillip -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
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.tonne...@free-electrons.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Add support for LZO-compressed kernels
On 08/04/2009 04:00 PM, Andrew Morton wrote: 0.24 seconds booting speedup sounds pretty thin. Adding a new decompression format will introduce more configuration/build/deployment complexities. How do we justify this? Keep in mind this may be out of a 3-5 second boot budget. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
H. Peter Anvin wrote: 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.tonne...@free-electrons.com 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. Gosh, who wants to get into the my patch is better than yours argument. I certainly don't... My patch series cleans up the code and fixes a number of rough edges (which I expect to hit when I try to make Squashfs use the new decompression code). Albin's looks to be adding a new set of LZO functionality. Regarding the conflicting patches in question, my patch removes a hack, Albin's moves #include slab.h into code covered by #ifndef STATIC, so it doesn't pull in loads of unnecessary definitions when the file is being built in the pre-boot environment. I personally can't decide which is A or B. Phillip -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined
Andrew Morton wrote: On Wed, 05 Aug 2009 01:47:57 +0100 Phillip Lougher phil...@lougher.demon.co.uk wrote: What do you normally do in this situation? I normally fix the rejects ;) But I'd like to confirm that the two patches don't fix the same thing via different means. Lacking a full description of Albin's issues, that's hard to determine. They do appear to be unrelated. No they're not fixing the same thing. Albin's patch is moving #include slab.h inside the #ifndef STATIC ... #endif code segment. This ensures that slab.h isn't included when the file is being built in the stripped down pre-boot environment. I imagine Albin's issues is that slab.h pulls in a lot of definitions unnecessary in the pre-boot environment and which rely on things which are missing in the stripped down pre-boot environment. My changes to the #ifndef STATIC logic defines PREBOOT if STATIC is defined. My patch uses the PREBOOT definition later to define the decompress wrapper function, which is only needed in the preboot environment. i.e. #ifdef STATIC #define PREBOOT #else #include linux/decompress/unlzma.h #endif ... Lots of code ... #ifdef PREBOOT static int INIT decompress. #endif Obvious question, why doesn't my patch use STATIC here rather than PREBOOT? The header file linux/decompress/unlzma.h defines STATIC, .i.e the #ifndef STATIC case defines STATIC via an include file, which makes decisions on STATIC later in the file impossible. 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. Reworked lib-decompress_-only-include-linux-slabh-if-static-is-not-defined.patch: The patch looks OK. Thanks Phillip -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html