Attention is currently required from: Jakub Czapiga, Paul Fagerburg, Jan Dabros. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56305 )
Change subject: tests: Add lib/lzmadecode-test test case ......................................................................
Patch Set 1:
(1 comment)
File tests/include/tests/lib/lzmadecode_data.h:
https://review.coreboot.org/c/coreboot/+/56305/comment/5fcc57bf_f8ca5865 PS1, Line 24: unsigned char test_lzmadecode_data_binary[] = {
I'm not sure if that even comes into play on files this small
Text files are well compressed regardless of selected compression level using XZ Utils and LZMA Utils. On the other side, small binary files are not compressed, but even increase their size by a few tens of bytes.
With "comes into play" I was specifically referring to dictSize. I believe dictSize can only make a difference as long as the uncompressed file size is larger than it.
BTW, I don't know what exactly you mean by "binary" files (it would also be good to specify that better in the comment), but if you mean object code files they should definitely still see a notable benefit from compression (that's the main file type coreboot uses these for, after all).
I think we should try to find a good balance between file size / test run speed and coverage. Maybe pick one low and one high compression level or something and go with that (and maybe also one file that's compressed with exactly what cbfstool's do_lzma_compress() does, because that's what we care most about). To save test execution time and space in Git I'd recommend storing the test data as a separate .bin file and loading it (fopen()/fread()) from the test itself rather than compiling it in. You could also use the same uncompressed data for all the different compression settings so you can save a bit more space there (by just having to store the uncompressed version once).
Regarding compression tools. We have to make a distinction between `lzma` provided by XZ Utils present in most systems, and `lzma` provided by LZMA Utils. AFAIK coreboot uses implementation from older version of LZMA Utils.
Yes, coreboot uses the older LZMA1 format. When you call xz via the `lzma` symlink name (or with --format=lzma), it produces that format. coreboot is able to read the files generated thusly from xz, that's what we're using for depthcharge (specifically https://packages.gentoo.org/packages/app-arch/xz-utils).
-
Julius Werner (Code Review)