LZO support

NoiseEHC NoiseEHC at freemail.hu
Tue Jul 15 13:27:20 EDT 2008

It seems that you two did not notice the smiley at the end of that 
sentence... I rather not to think about that it was not funny... :)

First, I have to apologize since that statement was made by Mitch 
Bradley here:
I am sorry, seems that I am just too old to remember names anymore.
For excuse I could say that both names starts with M so it was close... :)

Now about my obsession of compression code tuning:
Lately I have more or less finished documenting the Geode processor and 
need some problem where I can test what I have learned. Since 
compression is small, has potential and relatively isolated, I have 
chosen that. It could have been anything else but it seems that this can 
have the most effect.

C. Scott Ananian wrote:
> On Mon, Jul 14, 2008 at 6:01 PM, Michael Stone <michael at laptop.org> wrote:
>> On Mon, Jul 14, 2008 at 11:51:20PM +0200, Tomeu Vizoso wrote:
>>> On Mon, Jul 14, 2008 at 9:00 PM, NoiseEHC <NoiseEHC at freemail.hu>
>>> wrote:
>>>> I have a partially finished ZLIB decompression code as well. mstone
>>>> just
>>>> told me that time that we will use LZO so that effort was moot...
>>>> Currently I cannot decide if I should cry or just laugh
>>>> hysterically... :)
>> I believe I made statements a few months ago about what compression we
>> presently _do_ use, but I don't think I commented on what compression we
>> ought to be using. Can you remind me of my words?
> And, for the record, I didn't say "we'll be using zlib instead" -- in
> reality, we are trying to move off jffs2 just as quickly as possible,
> and the compression scheme we use "next" will be heavily influenced by
> whatever the "other filesystem" has adopted.  But it is a fact that we
> are currently using zlib and rtime compression in jffs2, and OFW
> doesn't currently support lzo compression, so that adoption of LZO in
> jffs2 would have to wait until partition support -- which is also
> roughly the time when I hope to replace the non-boot partitions with
> something better than jffs2.  So the window for LZO-related jffs2
> improvements is very narrow.  If logfs/ubifs/yaffs can benefit from
> your LZO work, then you've multiplied its potential usefulness -- and
> a quick google shows discussions of LZO in ubifs.  Besides, improving
> LZO in the kernel improves things for everyone, not just OLPC, so if
> it's your itch, go scratch it!
>   --scott

More information about the Devel mailing list