All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	dedekind1@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-embedded@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, phillip.lougher@gmail.com,
	Tim Bird <tim.bird@am.sony.com>,
	Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Subject: Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a 	separate file
Date: Thu, 10 Dec 2009 23:20:17 +0100	[thread overview]
Message-ID: <4B217421.5000802@openwrt.org> (raw)
In-Reply-To: <4B21656B.1090607@lougher.demon.co.uk>

On 2009-12-10 10:17 PM, Phillip Lougher wrote:
> Geert Uytterhoeven wrote:
>> 
>>> Yes I did consider using the cryptoapi, but this doesn't have support for
>>> lzma in mainline.
>> 
>> IIRC, Felix Fietkau added support for that for OpenWRT...
>> 
> 
> Yes, but it isn't in mainline, and OpenWRT don't appear to have tried to submit
> it.  IMHO the major problem with their patch is it uses a second private copy
> of lzma, rather than being a wrapper around the pre-existing lzma implementation.
> I don't think it's going to be easy to get a second lzma implementation accepted
> into mainline, when it took so long to get one accepted.  I have nothing against
> the cryptoapi, but it doesn't seem likely to be getting lzma support anytime soon.
> 
> As I previously said my aim is to use the pre-existing lzma implementation.  Unless
> it is stupendously bad (which it isn't), that seems to be the quickest, easiest and
> best way to get lzma support into Squashfs.
The main reason why my implementation couldn't be done as a simple
wrapper around the existing implementation is that it reuses the
caller's split output buffers instead wasting precious RAM by allocating
a contiguous buffer big enough to cover the entire block.
Especially at bigger block sizes (which provide better compression),
this probably has noticeable effects on tiny embedded systems with
little RAM.

- Felix

  reply	other threads:[~2009-12-10 22:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1NHTHg-0001sM-NQ@dylan.lougher.demon.co.uk>
2009-12-07 22:57 ` [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file Andrew Morton
2009-12-08 22:20   ` Phillip Lougher
2009-12-09 10:00     ` Artem Bityutskiy
2009-12-10  0:38       ` Phillip Lougher
2009-12-10 10:01         ` Geert Uytterhoeven
2009-12-10 10:01           ` Geert Uytterhoeven
2009-12-10 21:17           ` Phillip Lougher
2009-12-10 22:20             ` Felix Fietkau [this message]
2009-12-10 23:20           ` Phillip Lougher
2009-12-07  8:37 Phillip Lougher
  -- strict thread matches above, loose matches on Subject: below --
2009-12-07  8:25 root

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B217421.5000802@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=Geert.Uytterhoeven@sonycom.com \
    --cc=akpm@linux-foundation.org \
    --cc=dedekind1@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillip.lougher@gmail.com \
    --cc=phillip@lougher.demon.co.uk \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.