Hi Marek, On Sat, 28 Feb 2026 at 15:16, Marek Vasut <[email protected]> wrote: > > On 2/23/26 6:41 PM, Simon Glass wrote: > > Hello Simon, > > >>>> + /* > >>>> + * Allow runtime configuration of decompression chunk on > >>>> + * sandbox to better cover the chunked decompression > >>>> + * functionality without having to use > 4 GiB files. > >>>> + */ > >>>> + const ulong minchunk = 0x400; > >>>> + const ulong maxchunk = SZ_4G - minchunk; > >>>> + const ulong chunk = > >>>> + CONFIG_IS_ENABLED(SANDBOX, > >>>> + (clamp(env_get_ulong("gzwrite_chunk", > >>>> 10, maxchunk), > >>>> + minchunk, maxchunk)), > >>>> + (maxchunk)); > >>>> > >>> > >>> As you mentioned in the last version, there is a compression test in > >>> compression.c - could you add a version of this function that takes > >>> maxchunk as an argument and call it from that test? Reading an > >>> environment variable to avoid passing a parameter seems pretty odd to > >>> me :-) > >> Do we not want to test the command line interface ? > > > > Yes it is a good idea to test it, although we don't need to > > exhaustively test each compression case. I suggest using the dedicated > > compression/decompression tests to check detailed features, with the > > cmdline tests just checking for basic functionality. > The compression tests already test the memory-to-memory inflate path, > but they are not suitable to test the gzwrite inflate+write to block > storage path. The existing gzwrite test is suitable exactly for that. So > no, I don't see the compressions tests as a good place for gzwrite test. > The command line gzwrite test on the other hand is already there and is > testing exactly the inflate+write path.
OK I'll leave this to you. Regards, Simon
