[PATCH] add support for loading lzma compressed kernels
Florian Fainelli
florian at openwrt.org
Tue Nov 17 09:23:15 EST 2009
On Tuesday 17 November 2009 15:08:29 Florian Fainelli wrote:
> Hello Simon,
>
> On Tuesday 17 November 2009 04:04:38 Simon Horman wrote:
> > On Mon, Nov 16, 2009 at 12:53:06AM +0100, Florian Fainelli wrote:
> > > Hi Eric,
> > >
> > > This patch allows one to load a lzma compressed kernel using kexec -l.
> > > As I wanted the lzma code to be very similar to the existing
> > > zlib slurp_decompress I took lzread and associated routines
> > > from the cpio lzma support. Tested on my x86 laptop using the
> > > following commands:
> > >
> > > lzma e bzImage bzImage.lzma
> > > kexec -l bzImage.lzma
> > >
> > > Having lzma support is particularly useful on some embedded
> > > systems on which we have the kernel already lzma compressed
> > > and available on a mtd partition.
> > >
> > > Signed-off-by: Florian Fainelli <florian at openwrt.org>
> >
> > Should lzma_code_ be lzma_code. The former doesn't seem to work with
> > liblzma 4.999.9beta+20091016-1 from Debian.
>
> You are right it's actually lzma_code (without the trailing _).
>
> > > + AC_MSG_NOTICE([lzma support disabled])))
> >
> > The trailing "fi" line appears to be missing.
>
> Fixed too.
> [snip]
>
> > Does this imply that zlib compression isn't supported if
> > lzma compression support is enabled?
>
> Indeed, we might want to support both at runtime. Would you agree with the
> following proposal:
>
> - rename slurp_decompress_file to zlib/lzma_decompress_file
> - in case gzopen fails, do not die, but return NULL
> - test the return value of zlib_decompress_file and try
> lzma_decompress_file
We would also have to modify the call sites of slurp_decompress file this might
become pretty heavy if we support more decompression algorithms. What do you
think?
--
WBR, Florian
More information about the kexec
mailing list