User: Password:
|
|
Subscribe / Log in / New account

Squashfs submitted for the mainline

Squashfs submitted for the mainline

Posted Oct 30, 2008 9:48 UTC (Thu) by Trou.fr (subscriber, #26289)
In reply to: Squashfs submitted for the mainline by sbergman27
Parent article: Squashfs submitted for the mainline

Talking about LZMA, are there any explanations for why it is not going to be included in the kernel (it seems) ?


(Log in to post comments)

Squashfs submitted for the mainline

Posted Oct 30, 2008 10:02 UTC (Thu) by dlang (subscriber, #313) [Link]

I've seen some discussions about the possibility of using LZMA for the boot kernel, and one issue that I've seen is that LZMA can use incredible amounts of ram under corner cases

Squashfs submitted for the mainline

Posted Oct 30, 2008 11:43 UTC (Thu) by Tuxie (guest, #47191) [Link]

But AFAIK that depends on how the data was compressed, which parameters was used. You CAN do LZMA compression with extreme parameters which will only slightly improve compression but will take 100x the time and/or RAM usage for both encoding and decoding. Just use sane parameters when compressing the kernel and everything will be fine...

Squashfs submitted for the mainline

Posted Oct 30, 2008 11:59 UTC (Thu) by epa (subscriber, #39769) [Link]

But can you guarantee a maximum memory usage for decompressing? With gzip you can allocate a 32kbyte window and a little bit of housekeeping and you're guaranteed to decompress any valid stream. No dynamic memory allocation is needed. Can LZMA say the same?

Squashfs submitted for the mainline

Posted Oct 30, 2008 13:22 UTC (Thu) by ajb (subscriber, #9694) [Link]

If you're doing the compressing, you ought to be able to guarantee a memory limit for decompression. Just try decompressing while you still have the original around, and tweak the compression parameters if you run out of memory. That's how MPEG encoders work - consumer products that do mpeg stream decompression have a defined amount of memory (2Mbits, if I remember correctly).

Admittedly that might be considered an expensive solution, but it proves that a solution exists.

Squashfs submitted for the mainline

Posted Oct 30, 2008 13:42 UTC (Thu) by Tuxie (guest, #47191) [Link]

According to Wikipedia, "LZMA is effectively deflate (zlib, gzip, zip) with a larger dictionary size, 32MB instead of 32kB".

It also say: "the amount of RAM required during decompression is principally determined by the size of the sliding window used during compression. Small code size and relatively low memory overhead, particularly with smaller dictionary lengths, make the LZMA decompression algorithm well-suited to embedded applications."

I'm not sure if that's a good enough answer. :)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds