On Thu, Apr 2, 2020 at 10:26 PM Nick Terrell <terrelln@xxxxxx> wrote: > > > > > On Apr 2, 2020, at 8:58 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > > > > On Wed, Apr 01, 2020 at 05:33:03PM +0000, Nick Terrell wrote: > >> The code is currently written so that all the compression algorithms use the > >> same ZO_z_extra_bytes. It is taken to be the maximum of the growth rate > >> plus the maximum fixed overhead. Just a few lines above is the comment: > >> > >> # … Hence safety > >> # margin should be updated to cover all decompressors so that we don't > >> # need to deal with each of them separately. Please check > >> # the description in lib/decompressor_xxx.c for specific information. > >> > >> So I was been following the guidance in the comments. > > > > Please state that in the commit message when you send your next > > revision. > > Will do. > > >> Does it matter? I’m not an expert here, > > > > Huh, you're only sending the code then? Or what do you mean with not > > being an expert? > > I mean that while I’ve read and understood this piece of the code, have tested > the patches, have followed the template of other compression methods > added, and am confident in the correctness of the code, I’m not a regular > contributor to the pre-boot x86 kernel code. So it is possible that there is a > use case for kernel compression that I’m not aware of where RAM is extremely > tight and within 64 KB of the current limits. > > It seems to me that adding 64KB to the memory requirement for kernel > decompression is not going to break anyone. If it did the kernel image is taking > up nearly all available RAM, which doesn’t seem likely. But, I don’t know all > use cases. If it does break someone, we can put up a separate patch that > switches all the compression methods over a per-method ZO_z_extra_bytes. > Hi Nick, are you planning a zstd-v5? If yes, please CC me, thanks. Regards, - Sedat -
