Attention is currently required from: Paul Fagerburg, Julius Werner, Jan Dabros. Jakub Czapiga 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:
(2 comments)
File tests/include/tests/lib/lzmadecode_data.h:
https://review.coreboot.org/c/coreboot/+/56305/comment/8bec62b8_a342e4e4 PS1, Line 24: unsigned char test_lzmadecode_data_binary[] = {
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.
Oh, ok. Thanks for clarifying that :)
BTW, I don't know what exactly you mean by "binary" files ... but if you mean object code files they should definitely still see a notable benefit from compression
Yes, I was talking about object code files. I should have specified that.
To save test execution time and space in Git I'd recommend storing the test data as a separate .bin file
So, how should we generate the test data? Would libcmocka.so be good? It is a object file, its size is roughly similar to the coreboot payloads size. We would just have to create additional Makefile targets for data generation.
fopen()/fread()) from the test itself rather than compiling it in
It seems to be simpler than generating data, converting it to C array, sed-ing to match test variable names etc.
coreboot is able to read the files generated thusly from xz, that's what we're using for depthcharg
I have checked the `xz` manual again. Specifically, the `Streamed vs. non-streamed .lzma files` section. It says, that XZ Utils always use end-of-payload marker, and put unknown (zero) uncompressed file size in the LZMA header. Moreover, manual suggests using LZMA Utils instead, if one needs uncompressed file size field to be filled.
File tests/lib/lzmadecode-test.c:
https://review.coreboot.org/c/coreboot/+/56305/comment/282fdefb_34ea2e6f PS1, Line 97: LzmaDecode(&dstate, test_state->encoded_data_ptr + data_offset,
Everything in lzmadecode.c is the third-party code directly copied into the coreboot repo. […]
I understand. It makes sense :)
-
Jakub Czapiga (Code Review)