> On Nov 6, 2020, at 9:15 AM, Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > > On 11/3/20 1:05 AM, Nick Terrell wrote: >> From: Nick Terrell <terrelln@xxxxxx> >> Please pull from >> git@xxxxxxxxxx: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
