lkml.org 
[lkml]   [2010]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
    On Wed, 06 Jan 2010 14:04 -0800, Andrew Morton wrote :
    > On Fri, 11 Dec 2009 01:34:08 +0000
    > Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
    >
    > > Add a config option DECOMPRESS_LZMA_NEEDED which allows subsystems to
    > > specify they need the unlzma code. Normally decompress_unlzma.c is
    > > compiled with __init and unlzma is not exported to modules.
    > >
    > > Move INIT definition into separate header files for bzip2/lzma/inflate
    > > so it can be defined differently for each decompressor.
    > >
    >
    > This patch (which is in linux-next) breaks
    > lib-add-support-for-lzo-compressed-kernels.patch, below. The
    > definition of INIT is no longer available in lib/decompress_unlzo.c, and
    >
    > lib/decompress_unlzo.c: In function 'unlzo':
    > lib/decompress_unlzo.c:106: error: 'error' undeclared (first use in this function)
    > lib/decompress_unlzo.c:106: error: (Each undeclared identifier is reported only once
    > lib/decompress_unlzo.c:106: error: for each function it appears in.)
    > lib/decompress_unlzo.c:111: error: implicit declaration of function 'error'
    >
    >
    > I'm planning on merging
    >
    > zlib-optimize-inffast-when-copying-direct-from-output.patch
    > lib-add-support-for-lzo-compressed-kernels.patch
    > arm-add-support-for-lzo-compressed-kernels.patch
    > x86-add-support-for-lzo-compressed-kernels.patch
    > add-lzo-compression-support-for-initramfs-and-old-style-initrd.patch
    >
    > into 2.6.33. I don't immediately remember why I decided that - perhaps
    > because the patches did arrive in time for .33, but got stalled because
    > people were screwing around in other trees.
    >
    > So if I go ahead with that merge, linux-next will need fixing. And I
    > didn't get down and work what the appropriate fix is, and I don't want
    > to break linux-next in serious ways.
    >
    >
    > So what to do? I guess I could go ahead with the mainline merge, and
    > Stephen drops <whatever that tree was> from linux-next until it has
    > been fixed up?

    I'd go for that one, although I'm obviously biaised. IMHO the linux-next fix
    should be easy enough not to postpone the above five patches until 2.6.34.

    Regards,
    --
    Albin Tonnerre, Free Electrons
    Kernel, drivers and embedded Linux development,
    consulting, training and support.
    http://free-electrons.com


    \
     
     \ /
      Last update: 2010-01-06 23:47    [W:0.045 / U:0.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site