[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