> On Jul 3, 2020, at 12:06 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Fri, Jul 03, 2020 at 10:15:20AM +0200, Sedat Dilek wrote: >> On Thu, Jul 2, 2020 at 5:18 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> >>> On Wed, Jul 01, 2020 at 10:35:48AM -0400, Alex Xu (Hello71) wrote: >>>> ZSTD compression patches have been sent in a number of times over the >>>> past few years. Every time, someone asks for benchmarks. Every time, >>>> someone is concerned about compression time. Sometimes, someone provides >>>> benchmarks. >>> >>> Where's the latest series for this, btw? I thought it had landed. :P It >>> seemed like it was done. >>> >> >> Hi, >> >> Again, I would like to see this upstream, too. >> >> Last I asked for a rebase against Linux v5.8-rc1 or later. >> >> Beyond above adaptations, the latest series "zstd-v5" of Nick T.s >> patchset needs some addition of zstd to the patch (see [1]): >> >> commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 >> "kbuild: add variables for compression tools" >> >> NOTE: >> "zstd-v5" was against Linux-next 20200408 or download the series from >> patchwork LKML which applies cleanly against Linux v5.7 - last is what >> I did. >> >> There was a follow-up to the above patch (see [2]): >> >> commit e4a42c82e943b97ce124539fcd7a47445b43fa0d >> "kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables" > > Okay, cool. Yes, now is the right time to send an updated series based > on v5.8-rc2 with any outstanding adjusted/fixes made. > > It seems v5 is here? > https://lore.kernel.org/lkml/20200408215711.137639-1-nickrterrell@xxxxxxxxx/ > > That wasn't sent "to" a maintainer, so it likely went unnoticed by either > akpm or the x86 maintainers. I think this should likely go via the x86 > tree. > >> Nevertheless, this is the kernel-side of doing - user-space like for >> example Debian's initramfs-tools needs adaptations (see [3]). > > Right, but the kernel needs to implement the support first. :) > >> @Kees: Can you aid Nick T. to get this upstream? You know the >> processes a bit better than me. > > Sure; Nick, can you please rebase and handle any issues from v5? With > the result, send a v6 as you did for v5 before, but I would make your > "to" be: > > Borislav Petkov <bp@xxxxxxxxx> > Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > and keep the CC as you had it. I’ll send it out today, thanks for the advice! -Nick