[Crash-utility] [RFC] makedumpfile, crash: LZO compression support

[HATAYAMA Daisuke]

Hello Dave,

From: Dave Anderson <anderson at redhat.com>
Subject: Re: [Crash-utility] [RFC] makedumpfile, crash: LZO compression support
Date: Thu, 17 Nov 2011 13:25:31 -0500 (EST)

> 
> 
> ----- Original Message -----
>> Hello,
>> 
>> This is a RFC patch set that adds LZO compression support to
>> makedumpfile and crash utility. LZO is as good as in size but by far
>> better in speed than ZLIB, leading to reducing down time during
>> generation of crash dump and refiltering.
>> 
>> How to build:
>> 
>>   1. Get LZO library, which is provided as lzo-devel package on recent
>>   linux distributions, and is also available on author's website:
>>   http://www.oberhumer.com/opensource/lzo/.
>> 
>>   2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0.
>> 
>>   3. Build both using make. But for crash, do the following now:
>> 
>>     $ make CFLAGS="-llzo2"
>> 
>> How to use:
>> 
>>   I've newly used -l option for lzo compression in this patch. So for
>>   example, do as follows:
>> 
>>   $ makedumpfile -l vmcore dumpfile
>>   $ crash vmlinux dumpfile
>> 
>> Request of configure-like feature for crash utility:
>> 
>>   I would like configure-like feature on crash utility for users to
>>   select wheather to add LZO feature actually or not in build-time,
>>   that is: ./configure --enable-lzo or ./configure --disable-lzo.
>> 
>>   The reason is that support staff often downloads and installs the
>>   latest version of crash utility on machines where lzo library is not
>>   provided.
> 
> Right, at least on Fedora, these three packages would need to be installed:
> 
>  lzo-2.06-1.fc15.x86_64
>  lzo-minilzo-2.06-1.fc15.x86_64
>  lzo-devel-2.06-1.fc15.x86_64
> 
>> 
>>   Looking at the source code, it looks to me that crash does some kind
>>   of configuration processing in a local manner, around configure.c,
>>   and I guess it's difficult to use autoconf tools directly.
>> 
>>   Or is there another better way?
> 
> Instead of using CFLAGS, it would be preferable to dynamically append "-llzo2" to 
> the string that the gdb_merge stanza in the Makefile writes to the "mergelibs"
> file here:
> 
> gdb_merge: force
>         @if [ ! -f ${GDB}/README ]; then \
>           make --no-print-directory gdb_unzip; fi
> ===>    @echo "${LDFLAGS} -lz -ldl -rdynamic" > ${GDB}/gdb/mergelibs
>         @echo "../../${PROGRAM} ../../${PROGRAM}lib.a" > ${GDB}/gdb/mergeobj
>         @if [ ! -f ${GDB}/config.status ]; then \
>           (cd ${GDB}; ./configure ${GDB_CONF_FLAGS} --with-separate-debug-dir=/usr/lib/debug \
>             --with-bugurl="" --with-expat=no --with-python=no; \
>           make --no-print-directory; echo ${TARGET} > crash.target) \
>         else (cd ${GDB}/gdb; make --no-print-directory;); fi
>         @if [ ! -f ${GDB}/gdb/libgdb.a ]; then \
>           echo; echo "gdb build failed: ${GDB}/gdb/libgdb.a does not exist"; \
>           echo; exit 1; fi
> 
> It also requires an additional #define so that the #include line in defs.h
> and the calls to lzo_init() and lzo1x_decompress_safe() in diskdump.c can 
> be encapsulated, i.e., something like:
> 
> #ifdef LZO 
> #include <lzo/lzo1x.h>
> #endif
> 
> #ifdef LZO
>         dd->lzo_supported = lzo_init() == LZO_E_OK;
> #endif
> 
> #ifdef LZO
>                 ret = lzo1x_decompress_safe(dd->compressed_page, pd.size,
>                                             dd->page_cache_hdr[i].pg_bufptr,
>                                             &retlen, LZO1X_MEM_DECOMPRESS);
> #endif
> 
> The -DLZO would only need to be passed to the diskump.c compile line.
> 
> This could involve configure.c, but conceivably it could all be done within the 
> Makefile itself.  For example, by entering something like "make compress=lzo2", 
> and then adding this to the Makefile:
> 
> ifneq ($(compress),)
> ifeq ($(compress), lzo2)
>   LZOFLAG=-DLZO
>   LZOLIB=-llzo2
> endif
> endif
> 
> And then the diskdump.c compile line could use ${LZOFLAG}, and the
> gdb_merge stanza could include ${LZOLIB}.
> 

Thanks for accepting the request and for detailed instructions.

I'll reflect these configuration logic in the next patch.

Thanks.
HATAYAMA, Daisuke