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:
http://lists.laptop.org/pipermail/devel/2008-January/009437.html
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