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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ