On Tue, Jun 17, 2008 at 10:39 PM, Javier Martín <[EMAIL PROTECTED]> wrote: > El mar, 17-06-2008 a las 11:06 +0800, Bean escribió: >> AFAIK, lzma decompresser don't need intermediate buffers, it operates >> directly on the input and output buffer, for example, the lzmadecoder >> in coreboot: > I think you didn't see the intermediate buffer because it is hidden in > the Probs field passed through the decoderstate struct. I've googled my > way through the net to find what the hell "probs" mean, and I still > don't understand ten contiguous lines of the LZMA code. What I could > find is that > > http://qa.coreboot.org/docs/doxygen/lzma_8c-source.html > > provides the decoder with about 32KiB of "scratchpad" memory and will > reject decompressing files which "require" (as somehow indicated by the > first 5 bytes of the LZMA stream) more than that. I don't know if that > space is used for dictionaries, trees, forests or a Matrix full of > virtual monkeys hitting keys at random until the decompressed stream is > achieved, but its size seems to impose constraints at the time of > compression (probably a maximum -n level) that merit investigation. > > PS: have you tested the performance of other compression algorithms like > gzip-deflate (much simpler) or bzip2 (near LZMA for small files but with > less memory requisites)?
Hi, I think memory is not a problem here, as grub2 can use upper memory: src = raw data dest = 0x100000 buf = dest + kernel_size -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
