linux-kernel - Re: [GIT PULL][PATCH v5 0/9] Update to zstd-1.4.6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6D8DAFAA-0442-470B-B58A-6EBD72E39AF6@fb.com>
Date:   Fri, 6 Nov 2020 18:51:02 +0000
From:   Nick Terrell <terrelln@...com>
To:     Josef Bacik <josef@...icpanda.com>
CC:     Nick Terrell <nickrterrell@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "squashfs-devel@...ts.sourceforge.net" 
        <squashfs-devel@...ts.sourceforge.net>,
        "linux-f2fs-devel@...ts.sourceforge.net" 
        <linux-f2fs-devel@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>, Chris Mason <clm@...com>,
        Petr Malat <oss@...at.biz>, Johannes Weiner <jweiner@...com>,
        Niket Agarwal <niketa@...com>, Yann Collet <cyan@...com>
Subject: Re: [GIT PULL][PATCH v5 0/9] Update to zstd-1.4.6

> On Nov 6, 2020, at 9:15 AM, Josef Bacik <josef@...icpanda.com> wrote:
> 
> On 11/3/20 1:05 AM, Nick Terrell wrote:
>> From: Nick Terrell <terrelln@...com>
>> Please pull from
>>   git@...hub.com:terrelln/linux.git tags/v5-zstd-1.4.6
>> to get these changes. Alternatively the patchset is included.
> 
> Where did we come down on the code formatting question?  Personally I'm of the mind that as long as the consumers themselves adhere to the proper coding style I'm fine not maintaining the code style as long as we get the benefit of easily syncing in code from the upstream project.  Thanks,

The general consensus of everyone who has been involved in the discussion so far, seems to be that the benefits of keeping zstd in-sync with upstream outweigh the cost of accepting upstream’s API, though not everyone agrees. The alternative is to provide a wrapper around upstream’s API, but this makes it slightly harder to debug, since you have to go through the wrapper whose only purpose is to adapt to the coding style, and allows bugs to sneak into the kernel implementation, which aren’t present upstream.

Additionally, in 2017 LZ4 switched to using upstream LZ4’s API in order to stay up to date with upstream, which sets precedent. I also help maintain LZ4, and once the zstd update is merged, I plan to work on making it easier to update LZ4 in the kernel when upstream updates. That will be a much smaller change, since LZ4 is already nearly using upstream’s code directly.

Best,
Nick