linux-kernel - Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile

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:   Thu, 12 Sep 2019 07:17:51 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS:
 Maintainer Entry Profile

On Thu, Sep 12, 2019 at 4:02 AM Joe Perches <joe@...ches.com> wrote:
>
> (cut down the cc-list)
>
> On Thu, 2019-09-12 at 03:18 -0700, Joe Perches wrote:
> > On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> > > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@...el.com> wrote:
> > > > Now I come to find that CodingStyle has settled on clang-format (in
> > > > the last 15 months) as the new standard which is a much better answer
> > > > to me than a manually specified style open to interpretation. I'll
> > > > take a look at getting libnvdimm converted over.
> > >
> > > Note that clang-format cannot do everything as we want within the
> > > kernel just yet, but it is a close enough approximation -- it is near
> > > the point where we could simply agree to use it and stop worrying
> > > about styling issues. However, that would mean everyone needs to have
> > > a recent clang-format available, which I think is the biggest obstacle
> > > at the moment.
> >
> > I don't think that's close to true yet for clang-format.
> >
> > For instance: clang-format does not do anything with
> > missing braces, or coalescing multi-part strings,
> > or any number of other nominal coding style defects
> > like all the for_each macros, aligning or not aligning
> > columnar contents appropriately, etc...
> >
> > clang-format as yet has no taste.

Ok, good to confirm that we do not yet have an objective standard for
coding style. This means it's not yet something process documentation
can better standardize for contributors and will be subject to ongoing
taste debates. Lets reclaim the time to talk about objective items
that *can* clarified across maintainers.

> >
> > I believe it'll take a lot of work to improve it to a point
> > where its formatting is acceptable and appropriate.
> .
>
> Just fyi:
>
> Here's the difference that clang-format produces from the current
> nvdimm sources to the patch series I posted.
>
> clang-format does some OK, some not OK, some really bad.
> (e.g.: __stringify)
>
> My git branch for my patches is 20190911_nvdimm, and
> using Stephen Rothwell's git tree for -next:
>
> $ git checkout next-20190904
> $ clang-format -i drivers/nvdimm/*.[ch]
> $ git diff --stat -p 20190911_nvdimm -- drivers/nvdimm/ > nvdimm.clang-diff
> ---
[..]
>  25 files changed, 895 insertions(+), 936 deletions(-)

So, I'm lamenting the damage either of these mass conversions is going
to do git blame flows. To be honest I regret broaching Coding Style
standardization because it's taking the air out of the room for the
wider discussion of the maintainer/contributor topics we might be able
to agree.

As for libnvdimm at this point I'd rather start with objective
checkpatch error cleanups and defer the personal taste items.