Re: [PATCH 1/6] lib/decompress_*: only include linux/slab.h if STATIC is not defined

2009-08-04 Thread Andrew Morton
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

2009-08-04 Thread Andrew Morton
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

2009-08-04 Thread Andrew Morton
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

2009-08-04 Thread David Brownell
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

2009-08-04 Thread Phillip Lougher

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

2009-08-04 Thread H. Peter Anvin
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

2009-08-04 Thread H. Peter Anvin
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

2009-08-04 Thread Phillip Lougher

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

2009-08-04 Thread Phillip Lougher

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