* Re: flicker free booting
From: Geert Uytterhoeven @ 2009-08-03 8:37 UTC (permalink / raw)
To: Sascha Hauer
Cc: Bill Gatliff, Robert Schwebel, David VomLehn, linux-embedded,
Juergen Beisert, Wolfram Sang
In-Reply-To: <20090803081905.GP2714@pengutronix.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset="ks_c_5601-1987", Size: 1714 bytes --]
On Mon, 3 Aug 2009, Sascha Hauer wrote:
> On Fri, Jul 31, 2009 at 01:42:35PM -0500, Bill Gatliff wrote:
> > Could your bootloader pre-initialize the graphics hardware to the same
> > mode that the Linux driver will ultimately select, and then throw up a
> > static graphic? That would give you some output until the driver itself
> > comes online.
>
> I implemented exactly this for the i.MX framebuffer last week. It works
> by looking at the controllers physical screen start address, ioremapping
> this address and copying the content to the newly allocated framebuffer.
> Currently the driver still reinitilializes the controller with exactly
> the same values. We could skip this initialization step depending on a
> imxfb.preinitialized=1 command line parameter and read back
> resolution/depth from the device in order to fill the fb_info struct.
>
> This approach works good, I just wonder how acceptable it is for
> mainline.
If the actual frame buffer driver doesn't do much after initialization, we
already have (at least) two similar drivers in the kernel: vesafb and offb.
Both rely on firmware (PC BIOS vs. Open Firmware) to initialize the graphics
mode. Feel free to unify all of this into `staticfb.c'...
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-08-03 10:34 UTC (permalink / raw)
To: Matt Fleming
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090731105407.GA31900@console-pimps.org>
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
On Fri, 31 Jul 2009 11:54:07 +0100
Matt Fleming <matt@console-pimps.org> wrote:
> On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
> >
> > [PATCH 0/32] mmc and omap_hsmmc patches
> > http://marc.info/?t=124722953900010&r=1&w=2
> >
> > I haven't looked through these at all. The ones affecting the core
> > probably need some thorough reviews.
> >
> > I did notice the patch to say which cards a controller supports though,
> > and I'm very sceptical about that one. The scanning process should work
> > anyway, and the performance impact should be negligible as it is only
> > on init. So that patch only adds complexity and confusion IMO.
> >
>
> How much complexity does it really add? Surely it's better to give the
> host controller driver writers the ability to not entertain supporting
> some cards if they cannot be used? If they want to avoid the scanning
> process for certain cards, why not let them?
>
Let's look at the pros and cons of this:
Con:
- The scanning code gets less clear as you increase the number of
possible paths through it.
- Different systems will have different init sequences, possibly
provoking bugs in the cards.
- Host driver writers now have more capability bits they have to
consider. And these might be less than obvious since SD/MMC/SDIO are
normally compatible so these bits seem useless.
- With the current logic (which was better in the first version),
"normal" drivers will have to explicitly state that they work as
intended by setting all bits.
Pro:
- A slightly reduced scanning time.
I simply don't see it as being worth it. Linux patches generally need
to provide the answer to "Why?", not just be able to avoid "Why not?".
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-08-03 11:10 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090803123429.390a636f@mjolnir.ossman.eu>
On Mon, Aug 03, 2009 at 12:34:29PM +0200, Pierre Ossman wrote:
> On Fri, 31 Jul 2009 11:54:07 +0100
> Matt Fleming <matt@console-pimps.org> wrote:
>
> > On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
> > >
> > > [PATCH 0/32] mmc and omap_hsmmc patches
> > > http://marc.info/?t=124722953900010&r=1&w=2
> > >
> > > I haven't looked through these at all. The ones affecting the core
> > > probably need some thorough reviews.
> > >
> > > I did notice the patch to say which cards a controller supports though,
> > > and I'm very sceptical about that one. The scanning process should work
> > > anyway, and the performance impact should be negligible as it is only
> > > on init. So that patch only adds complexity and confusion IMO.
> > >
> >
> > How much complexity does it really add? Surely it's better to give the
> > host controller driver writers the ability to not entertain supporting
> > some cards if they cannot be used? If they want to avoid the scanning
> > process for certain cards, why not let them?
> >
>
> Let's look at the pros and cons of this:
>
> Con:
>
> - The scanning code gets less clear as you increase the number of
> possible paths through it.
>
Yes, it does but the function is only small. It's not that much more
complexity. And there's a trade off here between the added complexity
and the shorter initialisation time for cards. Running initialisation
functions on cards that don't need it just seems pointless.
> - Different systems will have different init sequences, possibly
> provoking bugs in the cards.
>
Good. I'd like to know about bugs in the cards so that we can fix/work
around any issues. This seems like a pretty weak argument against the
change to me.
> - Host driver writers now have more capability bits they have to
> consider. And these might be less than obvious since SD/MMC/SDIO are
> normally compatible so these bits seem useless.
>
Yes, but they also have the flexibility to more clearly describe their
host controllers. Besides, any new host controller driver will likely
just copy one of the older drivers (which I updated) anyway.
> - With the current logic (which was better in the first version),
> "normal" drivers will have to explicitly state that they work as
> intended by setting all bits.
>
I thought that the way I wrote the patch was more natural (which was why
I rewrote Adrian's to begin with), but if you think the original was
clearer I've no issue with pushing that patch through instead.
> Pro:
>
> - A slightly reduced scanning time.
>
>
> I simply don't see it as being worth it. Linux patches generally need
> to provide the answer to "Why?", not just be able to avoid "Why not?".
>
That's not at all what I said, I have provided the why (and so have you
by noting the Pro above).
^ permalink raw reply
* Re: New MMC maintainer needed
From: Adrian Hunter @ 2009-08-03 11:13 UTC (permalink / raw)
To: Pierre Ossman
Cc: Matt Fleming, Andrew Morton, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, nico@cam.org,
nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
Lavinen Jarkko (Nokia-D/Helsinki), ben@fluff.org,
saschasommer@freenet.de, avorontsov@ru.mvista.com,
oakad@yahoo.com, ian@mnementh.co.uk, HaraldWelte@
In-Reply-To: <20090803123429.390a636f@mjolnir.ossman.eu>
Pierre Ossman wrote:
> On Fri, 31 Jul 2009 11:54:07 +0100
> Matt Fleming <matt@console-pimps.org> wrote:
>
>> On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
>>> [PATCH 0/32] mmc and omap_hsmmc patches
>>> http://marc.info/?t=124722953900010&r=1&w=2
>>>
>>> I haven't looked through these at all. The ones affecting the core
>>> probably need some thorough reviews.
>>>
>>> I did notice the patch to say which cards a controller supports though,
>>> and I'm very sceptical about that one. The scanning process should work
>>> anyway, and the performance impact should be negligible as it is only
>>> on init. So that patch only adds complexity and confusion IMO.
>>>
>> How much complexity does it really add? Surely it's better to give the
>> host controller driver writers the ability to not entertain supporting
>> some cards if they cannot be used? If they want to avoid the scanning
>> process for certain cards, why not let them?
>>
>
> Let's look at the pros and cons of this:
But the cons are all subjective.
> Con:
>
> - The scanning code gets less clear as you increase the number of
> possible paths through it.
>
> - Different systems will have different init sequences, possibly
> provoking bugs in the cards.
>
> - Host driver writers now have more capability bits they have to
> consider. And these might be less than obvious since SD/MMC/SDIO are
> normally compatible so these bits seem useless.
>
> - With the current logic (which was better in the first version),
> "normal" drivers will have to explicitly state that they work as
> intended by setting all bits.
And the pro is objective.
> Pro:
>
> - A slightly reduced scanning time.
That's great! Why do you disregard this so easily?
> I simply don't see it as being worth it. Linux patches generally need
> to provide the answer to "Why?", not just be able to avoid "Why not?".
You have just supplied answers to both "Why?" and "Why not?".
In my opinion "Why?" outweighs "Why not?" because the pro is objective and
the cons and not.
^ permalink raw reply
* [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <20090731093107.GA29704@merkur.ravnborg.org>
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.
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
lib/decompress_bunzip2.c | 2 +-
lib/decompress_inflate.c | 2 +-
lib/decompress_unlzma.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 708e2a8..14b0c7d 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -47,10 +47,10 @@
#ifndef STATIC
#include <linux/decompress/bunzip2.h>
+#include <linux/slab.h>
#endif /* !STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#ifndef INT_MAX
#define INT_MAX 0x7fffffff
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index e36b296..fc30d50 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -19,11 +19,11 @@
#include "zlib_inflate/inflate.h"
#include "zlib_inflate/infutil.h"
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define INBUF_LEN (16*1024)
diff --git a/lib/decompress_unlzma.c b/lib/decompress_unlzma.c
index 32123a1..f078c88 100644
--- a/lib/decompress_unlzma.c
+++ b/lib/decompress_unlzma.c
@@ -31,10 +31,10 @@
#ifndef STATIC
#include <linux/decompress/unlzma.h>
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/6] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <1249311501-23102-1-git-send-email-albin.tonnerre@free-electrons.com>
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
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
include/linux/unaligned/be_byteshift.h | 2 +-
include/linux/unaligned/le_byteshift.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/unaligned/be_byteshift.h b/include/linux/unaligned/be_byteshift.h
index 46dd12c..9356b24 100644
--- a/include/linux/unaligned/be_byteshift.h
+++ b/include/linux/unaligned/be_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_BE_BYTESHIFT_H
#define _LINUX_UNALIGNED_BE_BYTESHIFT_H
-#include <linux/kernel.h>
+#include <linux/types.h>
static inline u16 __get_unaligned_be16(const u8 *p)
{
diff --git a/include/linux/unaligned/le_byteshift.h b/include/linux/unaligned/le_byteshift.h
index 59777e9..be376fb 100644
--- a/include/linux/unaligned/le_byteshift.h
+++ b/include/linux/unaligned/le_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_LE_BYTESHIFT_H
#define _LINUX_UNALIGNED_LE_BYTESHIFT_H
-#include <linux/kernel.h>
+#include <linux/types.h>
static inline u16 __get_unaligned_le16(const u8 *p)
{
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/6] Add support for LZO-compressed kernels
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <1249311501-23102-2-git-send-email-albin.tonnerre@free-electrons.com>
This is the first part of the lzo patch
The lzo compressor is worse than gzip at compression, but faster at
extraction. Here are some figures for an ARM board I'm working on:
Uncompressed size: 3.24Mo
gzip 1.61Mo 0.72s
lzo 1.75Mo 0.48s
So for a compression ratio that is still relatively close to gzip, it's
much faster to extract, at least in that case.
This version applies to kernel 2.6.31-rc3
This part contains:
- Makefile routine to support lzo compression
- Fixes to the existing lzo compressor so that it can be used in
compressed kernels
- wrapper around the existing lzo1x_decompress, as it only extracts one
block at a time, while we need to extract a whole file here
- config dialog for kernel compression
Changelog since v1:
lib/decompress_unlzo.c
- Rename lzo_decompress to unlzo to match the prototype in decompress/unlzo.h
- Use LZO_BLOCK_SIZE instead of BLOCK_SIZE to avoid confusion
- Add support for using the posp, fill and flush arguments
- Reorder includes so that linux/types.h is included before
linux/lzo.h. This prevents issue when not used as bootstrap code, as
lzo.h needs things like size_t
- When we are not using unlzo as part of kernel bootstrap code, we need
linux/slab.h for memory allocation functions.
- ... and we also need a call to set_error_fn so that the provided error
function is used correctly
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
include/linux/decompress/unlzo.h | 10 ++
init/Kconfig | 18 +++-
lib/decompress_unlzo.c | 206 ++++++++++++++++++++++++++++++++++++++
lib/lzo/lzo1x_decompress.c | 9 +-
scripts/Makefile.lib | 5 +
5 files changed, 241 insertions(+), 7 deletions(-)
create mode 100644 include/linux/decompress/unlzo.h
create mode 100644 lib/decompress_unlzo.c
diff --git a/include/linux/decompress/unlzo.h b/include/linux/decompress/unlzo.h
new file mode 100644
index 0000000..d1925ea
--- /dev/null
+++ b/include/linux/decompress/unlzo.h
@@ -0,0 +1,10 @@
+#ifndef DECOMPRESS_UNLZO_H
+#define DECOMPRESS_UNLZO_H
+
+int unlzo(unsigned char *inbuf, int len,
+ int(*fill)(void*, unsigned int),
+ int(*flush)(void*, unsigned int),
+ unsigned char *output,
+ int *pos,
+ void(*error)(char *x));
+#endif
diff --git a/init/Kconfig b/init/Kconfig
index cb2c092..ada6182 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -115,10 +115,13 @@ config HAVE_KERNEL_BZIP2
config HAVE_KERNEL_LZMA
bool
+config HAVE_KERNEL_LZO
+ bool
+
choice
prompt "Kernel compression mode"
default KERNEL_GZIP
- depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA
+ depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_LZO
help
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
@@ -141,9 +144,8 @@ config KERNEL_GZIP
bool "Gzip"
depends on HAVE_KERNEL_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config KERNEL_BZIP2
bool "Bzip2"
@@ -164,6 +166,14 @@ config KERNEL_LZMA
two. Compression is slowest. The kernel size is about 33%
smaller with LZMA in comparison to gzip.
+config KERNEL_LZO
+ bool "LZO"
+ depends on HAVE_KERNEL_LZO
+ help
+ Its compression ratio is the poorest among the 4. The kernel
+ size is about about 10% bigger than gzip; however its speed
+ (both compression and decompression) is the fastest.
+
endchoice
config SWAP
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
new file mode 100644
index 0000000..a18417a
--- /dev/null
+++ b/lib/decompress_unlzo.c
@@ -0,0 +1,206 @@
+/*
+ * LZO decompressor for the Linux kernel. Code borrowed from the lzo
+ * implementation by Markus Franz Xaver Johannes Oberhumer.
+ *
+ * Linux kernel adaptation:
+ * Copyright (C) 2009
+ * Albin Tonnerre, Free Electrons <albin.tonnerre@free-electrons.com>
+ *
+ * Original code:
+ * Copyright (C) 1996-2005 Markus Franz Xaver Johannes Oberhumer
+ * All Rights Reserved.
+ *
+ * lzop and the LZO library are free software; you can redistribute them
+ * and/or modify them under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.
+ * If not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Markus F.X.J. Oberhumer
+ * <markus@oberhumer.com>
+ * http://www.oberhumer.com/opensource/lzop/
+ */
+
+#ifdef STATIC
+#include "lzo/lzo1x_decompress.c"
+#else
+#include <linux/slab.h>
+#endif
+
+#include <linux/types.h>
+#include <linux/lzo.h>
+#include <linux/decompress/mm.h>
+#include <linux/decompress/unlzo.h>
+
+#include <linux/compiler.h>
+#include <asm/unaligned.h>
+
+static const unsigned char lzop_magic[] =
+ { 0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
+
+#define LZO_BLOCK_SIZE (256*1024l)
+#define HEADER_HAS_FILTER 0x00000800L
+
+STATIC inline int INIT parse_header(u8 *input, u8 *skip)
+{
+ int l;
+ u8 *parse = input;
+ u8 level = 0;
+ u16 version;
+
+ /* read magic: 9 first bits */
+ for (l = 0; l < 9; l++) {
+ if (*parse++ != lzop_magic[l])
+ return 0;
+ }
+ /* get version (2bytes), skip library version (2),
+ * 'need to be extracted' version (2) and
+ * method (1) */
+ version = get_unaligned_be16(parse);
+ parse += 7;
+ if (version >= 0x0940)
+ level = *parse++;
+ if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
+ parse += 8; /* flags + filter info */
+ else
+ parse += 4; /* flags */
+
+ /* skip mode and mtime_low */
+ parse += 8;
+ if (version >= 0x0940)
+ parse += 4; /* skip mtime_high */
+
+ l = *parse++;
+ /* don't care about the file name, and skip checksum */
+ parse += l + 4;
+
+ *skip = parse - input;
+ return 1;
+}
+
+STATIC inline int INIT unlzo(u8 *input, int in_len,
+ int (*fill) (void *, unsigned int),
+ int (*flush) (void *, unsigned int),
+ u8 *output, int *posp,
+ void (*error_fn) (char *x))
+{
+ u8 skip = 0, r = 0;
+ u32 src_len, dst_len;
+ size_t tmp;
+ u8 *in_buf, *in_buf_save, *out_buf;
+ int obytes_processed = 0;
+
+ set_error_fn(error_fn);
+
+ if (output)
+ out_buf = output;
+ else if (!flush) {
+ error("NULL output pointer and no flush function provided");
+ goto exit;
+ }
+ else if (!(out_buf = malloc(LZO_BLOCK_SIZE))) {
+ error("Could not allocate output buffer");
+ goto exit;
+ }
+
+ if (input && fill) {
+ error("Both input pointer and fill function provided, don't know what to do");
+ goto exit_1;
+ }
+ else if (input)
+ in_buf = input;
+ else if (!fill || !posp) {
+ error("NULL input pointer and missing position pointer or fill function");
+ goto exit_1;
+ }
+ else if (!(in_buf = malloc(lzo1x_worst_compress(LZO_BLOCK_SIZE)))) {
+ error("Could not allocate input buffer");
+ goto exit_1;
+ }
+ in_buf_save = in_buf;
+
+ if (posp)
+ *posp = 0;
+
+ if (fill)
+ fill(in_buf, lzo1x_worst_compress(LZO_BLOCK_SIZE));
+
+ if (!parse_header(input, &skip)) {
+ error("invalid header");
+ goto exit_2;
+ }
+ in_buf += skip;
+
+ if (posp)
+ *posp = skip;
+
+ for (;;) {
+ /* read uncompressed block size */
+ dst_len = get_unaligned_be32(in_buf);
+ in_buf += 4;
+
+ /* exit if last block */
+ if (dst_len == 0) {
+ if (posp)
+ *posp += 4;
+ break;
+ }
+
+ if (dst_len > LZO_BLOCK_SIZE) {
+ error("dest len longer than block size");
+ goto exit_2;
+ }
+
+ /* read compressed block size, and skip block checksum info */
+ src_len = get_unaligned_be32(in_buf);
+ in_buf += 8;
+
+ if (src_len <= 0 || src_len > dst_len) {
+ error("file corrupted");
+ goto exit_2;
+ }
+
+ /* decompress */
+ tmp = dst_len;
+ r = lzo1x_decompress_safe((u8 *) in_buf, src_len, out_buf, &tmp);
+
+ if (r != LZO_E_OK || dst_len != tmp) {
+ error("Compressed data violation");
+ goto exit_2;
+ }
+
+ obytes_processed += dst_len;
+ if (flush)
+ flush(out_buf, dst_len);
+ if (output)
+ out_buf += dst_len;
+ if (posp)
+ *posp += src_len + 12;
+ if (fill) {
+ in_buf = in_buf_save;
+ fill(in_buf, lzo1x_worst_compress(LZO_BLOCK_SIZE));
+ }
+ else
+ in_buf += src_len;
+ }
+
+exit_2:
+ if (!input)
+ free(in_buf);
+exit_1:
+ if (!output)
+ free(out_buf);
+exit:
+ return obytes_processed;
+}
+
+#define decompress unlzo
diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c
index 5dc6b29..f2fd098 100644
--- a/lib/lzo/lzo1x_decompress.c
+++ b/lib/lzo/lzo1x_decompress.c
@@ -11,11 +11,13 @@
* Richard Purdie <rpurdie@openedhand.com>
*/
+#ifndef STATIC
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/lzo.h>
-#include <asm/byteorder.h>
+#endif
+
#include <asm/unaligned.h>
+#include <linux/lzo.h>
#include "lzodefs.h"
#define HAVE_IP(x, ip_end, ip) ((size_t)(ip_end - ip) < (x))
@@ -244,9 +246,10 @@ lookbehind_overrun:
*out_len = op - out;
return LZO_E_LOOKBEHIND_OVERRUN;
}
-
+#ifndef STATIC
EXPORT_SYMBOL_GPL(lzo1x_decompress_safe);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("LZO1X Decompressor");
+#endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7a77787..7b721d1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -230,3 +230,8 @@ quiet_cmd_lzma = LZMA $@
cmd_lzma = (cat $(filter-out FORCE,$^) | \
lzma -9 && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
(rm -f $@ ; false)
+
+quiet_cmd_lzo = LZO $@
+cmd_lzo = (cat $(filter-out FORCE,$^) | \
+ lzop -9 && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+ (rm -f $@ ; false)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/6] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <1249311501-23102-3-git-send-email-albin.tonnerre@free-electrons.com>
This is the second part of patch. This part includes:
- changes to ach/arch/boot/Makefile to make it easier to add new
compression types
- new piggy.lzo.S necessary for lzo compression
- changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
gzip, depending on the config
- Kconfig support
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
arch/arm/Kconfig | 2 +
arch/arm/boot/compressed/Makefile | 16 +++--
arch/arm/boot/compressed/misc.c | 110 ++++++++------------------------
arch/arm/boot/compressed/piggy.S | 6 --
arch/arm/boot/compressed/piggy.gzip.S | 6 ++
arch/arm/boot/compressed/piggy.lzo.S | 6 ++
6 files changed, 52 insertions(+), 94 deletions(-)
delete mode 100644 arch/arm/boot/compressed/piggy.S
create mode 100644 arch/arm/boot/compressed/piggy.gzip.S
create mode 100644 arch/arm/boot/compressed/piggy.lzo.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index aef63c8..ea71c0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -18,6 +18,8 @@ config ARM
select HAVE_KRETPROBES if (HAVE_KPROBES)
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
select HAVE_GENERIC_DMA_COHERENT
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZO
help
The ARM series is a line of low-power-consumption RISC chip designs
licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index ce39dc5..4ea8f25 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -63,8 +63,12 @@ endif
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/
-targets := vmlinux vmlinux.lds piggy.gz piggy.o font.o font.c \
- head.o misc.o $(OBJS)
+suffix_$(CONFIG_KERNEL_GZIP) = gzip
+suffix_$(CONFIG_KERNEL_LZO) = lzo
+
+targets := vmlinux vmlinux.lds \
+ piggy.$(suffix_y) piggy.$(suffix_y).o \
+ font.o font.c head.o misc.o $(OBJS)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
@@ -94,15 +98,15 @@ LDFLAGS_vmlinux += -p --no-undefined -X \
# would otherwise mess up our GOT table
CFLAGS_misc.o := -Dstatic=
-$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
+$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
$(addprefix $(obj)/, $(OBJS)) FORCE
$(call if_changed,ld)
@:
-$(obj)/piggy.gz: $(obj)/../Image FORCE
- $(call if_changed,gzip)
+$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
+ $(call if_changed,$(suffix_y))
-$(obj)/piggy.o: $(obj)/piggy.gz FORCE
+$(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) FORCE
CFLAGS_font.o := -Dstatic=
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 9e6e512..c4ec564 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,11 +18,15 @@
unsigned int __machine_arch_type;
+#define _LINUX_STRING_H_
+
#include <linux/compiler.h> /* for inline */
#include <linux/types.h> /* for size_t */
#include <linux/stddef.h> /* for NULL */
#include <asm/string.h>
+#include <asm/unaligned.h>
+
#ifdef STANDALONE_DEBUG
#define putstr printf
#else
@@ -189,34 +193,8 @@ static inline __ptr_t memcpy(__ptr_t __dest, __const __ptr_t __src,
/*
* gzip delarations
*/
-#define OF(args) args
#define STATIC static
-typedef unsigned char uch;
-typedef unsigned short ush;
-typedef unsigned long ulg;
-
-#define WSIZE 0x8000 /* Window size must be at least 32k, */
- /* and a power of two */
-
-static uch *inbuf; /* input buffer */
-static uch window[WSIZE]; /* Sliding window buffer */
-
-static unsigned insize; /* valid bytes in inbuf */
-static unsigned inptr; /* index of next byte to be processed in inbuf */
-static unsigned outcnt; /* bytes in output buffer */
-
-/* gzip flag byte */
-#define ASCII_FLAG 0x01 /* bit 0 set: file probably ascii text */
-#define CONTINUATION 0x02 /* bit 1 set: continuation of multi-part gzip file */
-#define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */
-#define ORIG_NAME 0x08 /* bit 3 set: original file name present */
-#define COMMENT 0x10 /* bit 4 set: file comment present */
-#define ENCRYPTED 0x20 /* bit 5 set: file is encrypted */
-#define RESERVED 0xC0 /* bit 6,7: reserved */
-
-#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())
-
/* Diagnostic functions */
#ifdef DEBUG
# define Assert(cond,msg) {if(!(cond)) error(msg);}
@@ -234,24 +212,20 @@ static unsigned outcnt; /* bytes in output buffer */
# define Tracecv(c,x)
#endif
-static int fill_inbuf(void);
-static void flush_window(void);
static void error(char *m);
extern char input_data[];
extern char input_data_end[];
-static uch *output_data;
-static ulg output_ptr;
-static ulg bytes_out;
+static unsigned char *output_data;
+static unsigned long output_ptr;
static void error(char *m);
static void putstr(const char *);
-extern int end;
-static ulg free_mem_ptr;
-static ulg free_mem_end_ptr;
+static unsigned long free_mem_ptr;
+static unsigned long free_mem_end_ptr;
#ifdef STANDALONE_DEBUG
#define NO_INFLATE_MALLOC
@@ -259,46 +233,13 @@ static ulg free_mem_end_ptr;
#define ARCH_HAS_DECOMP_WDOG
-#include "../../../../lib/inflate.c"
-
-/* ===========================================================================
- * Fill the input buffer. This is called only when the buffer is empty
- * and at least one byte is really needed.
- */
-int fill_inbuf(void)
-{
- if (insize != 0)
- error("ran out of input data");
-
- inbuf = input_data;
- insize = &input_data_end[0] - &input_data[0];
-
- inptr = 1;
- return inbuf[0];
-}
+#ifdef CONFIG_KERNEL_GZIP
+#include "../../../../lib/decompress_inflate.c"
+#endif
-/* ===========================================================================
- * Write the output window window[0..outcnt-1] and update crc and bytes_out.
- * (Used for the decompressed data only.)
- */
-void flush_window(void)
-{
- ulg c = crc;
- unsigned n;
- uch *in, *out, ch;
-
- in = window;
- out = &output_data[output_ptr];
- for (n = 0; n < outcnt; n++) {
- ch = *out++ = *in++;
- c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
- }
- crc = c;
- bytes_out += (ulg)outcnt;
- output_ptr += (ulg)outcnt;
- outcnt = 0;
- putstr(".");
-}
+#ifdef CONFIG_KERNEL_LZO
+#include "../../../../lib/decompress_unlzo.c"
+#endif
#ifndef arch_error
#define arch_error(x)
@@ -317,20 +258,26 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
-ulg
-decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
- int arch_id)
+unsigned long
+decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
+ unsigned long free_mem_ptr_end_p,
+ int arch_id)
{
- output_data = (uch *)output_start; /* Points to kernel start */
+ unsigned char *tmp;
+
+ output_data = (unsigned char *)output_start;
free_mem_ptr = free_mem_ptr_p;
free_mem_end_ptr = free_mem_ptr_end_p;
__machine_arch_type = arch_id;
arch_decomp_setup();
- makecrc();
+ tmp = (unsigned char *) (((unsigned long)input_data_end) - 4);
+ output_ptr = get_unaligned_le32(tmp);
+
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr(" done, booting the kernel.\n");
return output_ptr;
}
@@ -342,11 +289,10 @@ int main()
{
output_data = output_buffer;
- makecrc();
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr("done.\n");
return 0;
}
#endif
-
diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S
deleted file mode 100644
index 54c9518..0000000
--- a/arch/arm/boot/compressed/piggy.S
+++ /dev/null
@@ -1,6 +0,0 @@
- .section .piggydata,#alloc
- .globl input_data
-input_data:
- .incbin "arch/arm/boot/compressed/piggy.gz"
- .globl input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.gzip.S b/arch/arm/boot/compressed/piggy.gzip.S
new file mode 100644
index 0000000..a68adf9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.gzip.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.gzip"
+ .globl input_data_end
+input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lzo.S b/arch/arm/boot/compressed/piggy.lzo.S
new file mode 100644
index 0000000..a425ad9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lzo.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.lzo"
+ .globl input_data_end
+input_data_end:
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/6] Add support for LZO-compressed kernels on x86
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <1249311501-23102-4-git-send-email-albin.tonnerre@free-electrons.com>
This is the third and last part of the patch, which contains the
necessary changes to the x86 Kconfig and boot/compressed to allow the
use of this new compression method
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
arch/x86/Kconfig | 1 +
arch/x86/boot/compressed/Makefile | 5 ++++-
arch/x86/boot/compressed/misc.c | 4 ++++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 738bdc6..49974d3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -48,6 +48,7 @@ config X86
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZMA
+ select HAVE_KERNEL_LZO
select HAVE_ARCH_KMEMCHECK
config OUTPUT_FORMAT
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index e2ff504..95bfe0e 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -4,7 +4,7 @@
# create a compressed vmlinux image from the original vmlinux
#
-targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma head_$(BITS).o misc.o piggy.o
+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.lzo head_$(BITS).o misc.o piggy.o
KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
@@ -48,10 +48,13 @@ $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
$(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
+$(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
+ $(call if_changed,lzo)
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
+suffix-$(CONFIG_KERNEL_LZO) := lzo
quiet_cmd_mkpiggy = MKPIGGY $@
cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 842b2a3..3b22fe8 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -162,6 +162,10 @@ static int lines, cols;
#include "../../../../lib/decompress_unlzma.c"
#endif
+#ifdef CONFIG_KERNEL_LZO
+#include "../../../../lib/decompress_unlzo.c"
+#endif
+
static void scroll(void)
{
int i;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 6/6] Add LZO compression support for initramfs and old-style initrd
From: Albin Tonnerre @ 2009-08-03 14:58 UTC (permalink / raw)
To: sam; +Cc: hpa, linux, alain, linux-kernel, linux-embedded, akpm,
Albin Tonnerre
In-Reply-To: <1249311501-23102-5-git-send-email-albin.tonnerre@free-electrons.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
lib/Kconfig | 4 ++++
lib/Makefile | 1 +
lib/decompress.c | 5 +++++
usr/Kconfig | 25 ++++++++++++++++++++-----
4 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index bb1326d..8639349 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -117,6 +117,10 @@ config DECOMPRESS_BZIP2
config DECOMPRESS_LZMA
tristate
+config DECOMPRESS_LZO
+ select LZO_DECOMPRESS
+ tristate
+
#
# Generic allocator support is selected if needed
#
diff --git a/lib/Makefile b/lib/Makefile
index 2e78277..cfa4041 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
+lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
obj-$(CONFIG_TEXTSEARCH) += textsearch.o
obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o
diff --git a/lib/decompress.c b/lib/decompress.c
index d2842f5..a760681 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -9,6 +9,7 @@
#include <linux/decompress/bunzip2.h>
#include <linux/decompress/unlzma.h>
#include <linux/decompress/inflate.h>
+#include <linux/decompress/unlzo.h>
#include <linux/types.h>
#include <linux/string.h>
@@ -22,6 +23,9 @@
#ifndef CONFIG_DECOMPRESS_LZMA
# define unlzma NULL
#endif
+#ifndef CONFIG_DECOMPRESS_LZO
+# define unlzo NULL
+#endif
static const struct compress_format {
unsigned char magic[2];
@@ -32,6 +36,7 @@ static const struct compress_format {
{ {037, 0236}, "gzip", gunzip },
{ {0x42, 0x5a}, "bzip2", bunzip2 },
{ {0x5d, 0x00}, "lzma", unlzma },
+ { {0x89, 0x4c}, "lzo", unlzo },
{ {0, 0}, NULL, NULL }
};
diff --git a/usr/Kconfig b/usr/Kconfig
index 1c3039f..04a826e 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -72,6 +72,15 @@ config RD_LZMA
Support loading of a LZMA encoded initial ramdisk or cpio buffer
If unsure, say N.
+config RD_LZO
+ bool "Support initial ramdisks compressed using LZO" if EMBEDDED
+ default !EMBEDDED
+ depends on BLK_DEV_INITRD
+ select DECOMPRESS_LZO
+ help
+ Support loading of a LZO encoded initial ramdisk or cpio buffer
+ If unsure, say N.
+
choice
prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
help
@@ -108,16 +117,15 @@ config INITRAMFS_COMPRESSION_GZIP
bool "Gzip"
depends on RD_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config INITRAMFS_COMPRESSION_BZIP2
bool "Bzip2"
depends on RD_BZIP2
help
Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the three. The initramfs
+ Decompression speed is slowest among the four. The initramfs
size is about 10% smaller with bzip2, in comparison to gzip.
Bzip2 uses a large amount of memory. For modern kernels you
will need at least 8MB RAM or more for booting.
@@ -128,7 +136,14 @@ config INITRAMFS_COMPRESSION_LZMA
help
The most recent compression algorithm.
Its ratio is best, decompression speed is between the other
- two. Compression is slowest. The initramfs size is about 33%
+ three. Compression is slowest. The initramfs size is about 33%
smaller with LZMA in comparison to gzip.
+config INITRAMFS_COMPRESSION_LZO
+ bool "LZO"
+ depends on RD_LZO
+ help
+ Its compression ratio is the poorest among the four. The kernel
+ size is about about 10% bigger than gzip; however its speed
+
endchoice
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 5/6] Add support for LZO-compressed kernels on x86
From: H. Peter Anvin @ 2009-08-03 15:11 UTC (permalink / raw)
To: Albin Tonnerre; +Cc: sam, linux, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <1249311501-23102-5-git-send-email-albin.tonnerre@free-electrons.com>
On 08/03/2009 07:58 AM, Albin Tonnerre wrote:
> This is the third and last part of the patch, which contains the
> necessary changes to the x86 Kconfig and boot/compressed to allow the
> use of this new compression method
>
> Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/boot/compressed/Makefile | 5 ++++-
> arch/x86/boot/compressed/misc.c | 4 ++++
> 3 files changed, 9 insertions(+), 1 deletions(-)
>
Acked-by: H. Peter Anvin <hpa@zytor.com>
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH 6/6] Add LZO compression support for initramfs and old-style initrd
From: H. Peter Anvin @ 2009-08-03 15:12 UTC (permalink / raw)
To: Albin Tonnerre; +Cc: sam, linux, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <1249311501-23102-6-git-send-email-albin.tonnerre@free-electrons.com>
On 08/03/2009 07:58 AM, Albin Tonnerre wrote:
>
> +config INITRAMFS_COMPRESSION_LZO
> + bool "LZO"
> + depends on RD_LZO
> + help
> + Its compression ratio is the poorest among the four. The kernel
> + size is about about 10% bigger than gzip; however its speed
> +
> endchoice
Truncated help text...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH 6/6] Add LZO compression support for initramfs and old-style initrd
From: Albin Tonnerre @ 2009-08-03 16:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: sam, linux, alain, linux-kernel, linux-embedded, akpm
In-Reply-To: <4A76FE43.4070708@zytor.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
Updated with a missing part of the description for INITRAMFS_COMPRESSION_LZO
lib/Kconfig | 4 ++++
lib/Makefile | 1 +
lib/decompress.c | 5 +++++
usr/Kconfig | 26 +++++++++++++++++++++-----
4 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index bb1326d..8639349 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -117,6 +117,10 @@ config DECOMPRESS_BZIP2
config DECOMPRESS_LZMA
tristate
+config DECOMPRESS_LZO
+ select LZO_DECOMPRESS
+ tristate
+
#
# Generic allocator support is selected if needed
#
diff --git a/lib/Makefile b/lib/Makefile
index 2e78277..cfa4041 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
+lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
obj-$(CONFIG_TEXTSEARCH) += textsearch.o
obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o
diff --git a/lib/decompress.c b/lib/decompress.c
index d2842f5..a760681 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -9,6 +9,7 @@
#include <linux/decompress/bunzip2.h>
#include <linux/decompress/unlzma.h>
#include <linux/decompress/inflate.h>
+#include <linux/decompress/unlzo.h>
#include <linux/types.h>
#include <linux/string.h>
@@ -22,6 +23,9 @@
#ifndef CONFIG_DECOMPRESS_LZMA
# define unlzma NULL
#endif
+#ifndef CONFIG_DECOMPRESS_LZO
+# define unlzo NULL
+#endif
static const struct compress_format {
unsigned char magic[2];
@@ -32,6 +36,7 @@ static const struct compress_format {
{ {037, 0236}, "gzip", gunzip },
{ {0x42, 0x5a}, "bzip2", bunzip2 },
{ {0x5d, 0x00}, "lzma", unlzma },
+ { {0x89, 0x4c}, "lzo", unlzo },
{ {0, 0}, NULL, NULL }
};
diff --git a/usr/Kconfig b/usr/Kconfig
index 1c3039f..bf30c32 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -72,6 +72,15 @@ config RD_LZMA
Support loading of a LZMA encoded initial ramdisk or cpio buffer
If unsure, say N.
+config RD_LZO
+ bool "Support initial ramdisks compressed using LZO" if EMBEDDED
+ default !EMBEDDED
+ depends on BLK_DEV_INITRD
+ select DECOMPRESS_LZO
+ help
+ Support loading of a LZO encoded initial ramdisk or cpio buffer
+ If unsure, say N.
+
choice
prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
help
@@ -108,16 +117,15 @@ config INITRAMFS_COMPRESSION_GZIP
bool "Gzip"
depends on RD_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config INITRAMFS_COMPRESSION_BZIP2
bool "Bzip2"
depends on RD_BZIP2
help
Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the three. The initramfs
+ Decompression speed is slowest among the four. The initramfs
size is about 10% smaller with bzip2, in comparison to gzip.
Bzip2 uses a large amount of memory. For modern kernels you
will need at least 8MB RAM or more for booting.
@@ -128,7 +136,15 @@ config INITRAMFS_COMPRESSION_LZMA
help
The most recent compression algorithm.
Its ratio is best, decompression speed is between the other
- two. Compression is slowest. The initramfs size is about 33%
+ three. Compression is slowest. The initramfs size is about 33%
smaller with LZMA in comparison to gzip.
+config INITRAMFS_COMPRESSION_LZO
+ bool "LZO"
+ depends on RD_LZO
+ help
+ Its compression ratio is the poorest among the four. The kernel
+ size is about about 10% bigger than gzip; however its speed
+ (both compression and decompression) is the fastest.
+
endchoice
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-08-03 21:41 UTC (permalink / raw)
To: Adrian Hunter
Cc: pierre, matt, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan
In-Reply-To: <4A76C658.6050002@nokia.com>
On Mon, 03 Aug 2009 14:13:28 +0300
Adrian Hunter <adrian.hunter@nokia.com> wrote:
> Pierre Ossman wrote:
> > On Fri, 31 Jul 2009 11:54:07 +0100
> > Matt Fleming <matt@console-pimps.org> wrote:
> >
> >> On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
> >>> [PATCH 0/32] mmc and omap_hsmmc patches
> >>> http://marc.info/?t=124722953900010&r=1&w=2
> >>>
> >>> I haven't looked through these at all. The ones affecting the core
> >>> probably need some thorough reviews.
> >>>
> >>> I did notice the patch to say which cards a controller supports though,
> >>> and I'm very sceptical about that one. The scanning process should work
> >>> anyway, and the performance impact should be negligible as it is only
> >>> on init. So that patch only adds complexity and confusion IMO.
> >>>
> >> How much complexity does it really add? Surely it's better to give the
> >> host controller driver writers the ability to not entertain supporting
> >> some cards if they cannot be used? If they want to avoid the scanning
> >> process for certain cards, why not let them?
> >>
> >
> > Let's look at the pros and cons of this:
>
> But the cons are all subjective.
>
> > Con:
> >
> > - The scanning code gets less clear as you increase the number of
> > possible paths through it.
> >
> > - Different systems will have different init sequences, possibly
> > provoking bugs in the cards.
> >
> > - Host driver writers now have more capability bits they have to
> > consider. And these might be less than obvious since SD/MMC/SDIO are
> > normally compatible so these bits seem useless.
> >
> > - With the current logic (which was better in the first version),
> > "normal" drivers will have to explicitly state that they work as
> > intended by setting all bits.
Subjective or not, they are real and valid.
> And the pro is objective.
>
> > Pro:
> >
> > - A slightly reduced scanning time.
>
> That's great! Why do you disregard this so easily?
Coz nobody quantified it. Let's go to the changelog:
: Some hosts can accept only certain types of cards. For example, an eMMC
: is MMC only and a uSD slot may be SD only. However the MMC card scanning
: logic checks for all card types one by one.
:
: Add host capabilities to specify which card types can be used, and amend
: the card scanning logic to skip scanning for those types which cannot be
: used.
See, it provides no reason at all for adding this additional complexity.
Now we're told "it's faster". OK. How much faster? Show us the
numbers so we can all understand why the change is justifiable!
^ permalink raw reply
* Re: New MMC maintainer needed
From: David Brownell @ 2009-08-04 1:51 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090731122623.254fd0f1@mjolnir.ossman.eu>
On Friday 31 July 2009, Pierre Ossman wrote:
> Restoring back the system state from MMC after a successful hibernation
> http://marc.info/?t=124818534700003&r=1&w=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
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Andrew Morton @ 2009-08-04 22:55 UTC (permalink / raw)
Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded,
albin.tonnerre, Phillip Lougher
In-Reply-To: <1249311501-23102-1-git-send-email-albin.tonnerre@free-electrons.com>
On Mon, 3 Aug 2009 16:58:16 +0200
Albin Tonnerre <albin.tonnerre@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?
^ permalink raw reply
* Re: [PATCH 2/6] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
From: Andrew Morton @ 2009-08-04 22:55 UTC (permalink / raw)
Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded,
albin.tonnerre
In-Reply-To: <1249311501-23102-2-git-send-email-albin.tonnerre@free-electrons.com>
On Mon, 3 Aug 2009 16:58:17 +0200
Albin Tonnerre <albin.tonnerre@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.
^ permalink raw reply
* Re: [PATCH 3/6] Add support for LZO-compressed kernels
From: Andrew Morton @ 2009-08-04 23:00 UTC (permalink / raw)
Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded,
albin.tonnerre
In-Reply-To: <1249311501-23102-3-git-send-email-albin.tonnerre@free-electrons.com>
On Mon, 3 Aug 2009 16:58:18 +0200
Albin Tonnerre <albin.tonnerre@free-electrons.com> wrote:
> This is the first part of the lzo patch
> The lzo compressor is worse than gzip at compression, but faster at
> extraction. Here are some figures for an ARM board I'm working on:
>
> Uncompressed size: 3.24Mo
> gzip 1.61Mo 0.72s
> lzo 1.75Mo 0.48s
>
> So for a compression ratio that is still relatively close to gzip, it's
> much faster to extract, at least in that case.
Is 3.2Mb a typical kernel size for small systems? It sounds large.
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?
Did anyone look into just speeding up the gzip decompressor?
> +#ifdef STATIC
What is this STATIC thing for?
^ permalink raw reply
* Re: [PATCH 3/6] Add support for LZO-compressed kernels
From: Andrew Morton @ 2009-08-04 23:04 UTC (permalink / raw)
Cc: sam, hpa, linux, alain, linux-kernel, linux-embedded,
albin.tonnerre
In-Reply-To: <1249311501-23102-3-git-send-email-albin.tonnerre@free-electrons.com>
On Mon, 3 Aug 2009 16:58:18 +0200
Albin Tonnerre <albin.tonnerre@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.
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Phillip Lougher @ 2009-08-05 0:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Albin Tonnerre, sam, hpa, linux, alain, linux-kernel,
linux-embedded
In-Reply-To: <20090804155500.db6c88fa.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Mon, 3 Aug 2009 16:58:16 +0200
> Albin Tonnerre <albin.tonnerre@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
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: H. Peter Anvin @ 2009-08-05 0:57 UTC (permalink / raw)
To: Phillip Lougher
Cc: Andrew Morton, Albin Tonnerre, sam, linux, alain, linux-kernel,
linux-embedded
In-Reply-To: <4A78D6BD.3030003@lougher.demon.co.uk>
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@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
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Andrew Morton @ 2009-08-05 1:08 UTC (permalink / raw)
To: Phillip Lougher
Cc: Albin Tonnerre, sam, hpa, linux, alain, linux-kernel,
linux-embedded
In-Reply-To: <4A78D6BD.3030003@lougher.demon.co.uk>
On Wed, 05 Aug 2009 01:47:57 +0100 Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
> Andrew Morton wrote:
> > On Mon, 3 Aug 2009 16:58:16 +0200
> > Albin Tonnerre <albin.tonnerre@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 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.
> 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:
lib/decompress_bunzip2.c | 2 +-
lib/decompress_inflate.c | 2 +-
lib/decompress_unlzma.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff -puN lib/decompress_bunzip2.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined lib/decompress_bunzip2.c
--- a/lib/decompress_bunzip2.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined
+++ a/lib/decompress_bunzip2.c
@@ -49,10 +49,10 @@
#define PREBOOT
#else
#include <linux/decompress/bunzip2.h>
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#ifndef INT_MAX
#define INT_MAX 0x7fffffff
diff -puN lib/decompress_inflate.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined lib/decompress_inflate.c
--- a/lib/decompress_inflate.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined
+++ a/lib/decompress_inflate.c
@@ -19,11 +19,11 @@
#include "zlib_inflate/inflate.h"
#include "zlib_inflate/infutil.h"
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define GZIP_IOBUF_SIZE (16*1024)
diff -puN lib/decompress_unlzma.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined lib/decompress_unlzma.c
--- a/lib/decompress_unlzma.c~lib-decompress_-only-include-linux-slabh-if-static-is-not-defined
+++ a/lib/decompress_unlzma.c
@@ -33,10 +33,10 @@
#define PREBOOT
#else
#include <linux/decompress/unlzma.h>
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
_
^ permalink raw reply
* Re: [PATCH 1/6] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Phillip Lougher @ 2009-08-05 1:32 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andrew Morton, Albin Tonnerre, sam, linux, alain, linux-kernel,
linux-embedded
In-Reply-To: <4A78D8DF.8070303@zytor.com>
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.tonnerre@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
^ permalink raw reply
* Re: [PATCH 3/6] Add support for LZO-compressed kernels
From: H. Peter Anvin @ 2009-08-05 1:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Albin Tonnerre, sam, linux, alain, linux-kernel, linux-embedded
In-Reply-To: <20090804160043.82b256d8.akpm@linux-foundation.org>
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
^ permalink raw reply
* Re: New MMC maintainer needed
From: David VomLehn @ 2009-08-05 1:42 UTC (permalink / raw)
To: David Brownell
Cc: Pierre Ossman, Andrew Morton, linux-kernel, linux-embedded, nico,
nicolas.ferre, hskinnemoen, tony, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <200908031851.24375.david-b@pacbell.net>
On Mon, Aug 03, 2009 at 06:51:23PM -0700, David Brownell wrote:
> On Friday 31 July 2009, Pierre Ossman wrote:
> > Restoring back the system state from MMC after a successful hibernation
> > http://marc.info/?t=124818534700003&r=1&w=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
I've been half- (or less) watching this discussion, but I'm sort of thinking
that one piece of this might be a patch I just reposted that provides for
synchronizing the discovery/initialization of devices during start up with
their use. One thing I expect it to do is to largely eliminate the need for
root_delay. It currently knows nothing about resuming, but perhaps it should.
Since the patch touches USB and SCSI, as well as some core kernel pieces, it
was posted to a bunch of places, but by tomorrow you should be able to find it
by searching for "initdev" in the kernel mailing list archives.
David VomLehn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox