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
