linux-kernel - Re: [PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

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: <20180626193325.GA5356@mellanox.com>
Date:   Tue, 26 Jun 2018 13:33:25 -0600
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Andy Whitcroft <apw@...onical.com>,
        Joe Perches <joe@...ches.com>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

On Tue, Jun 26, 2018 at 05:05:40PM +0200, Miguel Ojeda wrote:
> Hi,
> 
> On Tue, Jun 26, 2018 at 12:44 AM, Jason Gunthorpe <jgg@...lanox.com> wrote:
> > The true option causes this indenting for functions:
> >
> > static struct something_very_very_long *
> >     function(void *arg)
> > {
> >
> > While a quick survey suggests that the usual Linux fallback is the GNU
> > style:
> >
> > static struct something_very_very_long *
> > function(void *arg)
> > {
> >
> > Eg as seen in:
> >
> > kernel/cpu.c
> > kernel/fork.c
> > etc
> >
> > Acked-by: Joe Perches <joe@...ches.com>
> > Signed-off-by: Jason Gunthorpe <jgg@...lanox.com>
> >  .clang-format | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Resending outside the merge window with no change..
> >
> > If there is no clear upstream path for this file (it has no
> > MAINTAINERS entry?) I could take it to Linus via the rdma.git tree, eg
> 
> We can add an specific entry, yeah. Is there any policy for "general
> files" (or some general/catch-all entry)?
> 
> > as a 'collectively maintained' file.
> 
> As you prefer -- I can also pick it up through auxdisplay; but I am
> not sure if we should put it in any "unrelated" tree, though. (Since
> the file will not probably receive many patches, I originally thought
> that it would be picked up by Andrew or some other "general" tree
> instead.)

Well, I'd rather you take it as the owner of the file, honestly :)
Along with a MAINTAINERS update...

I also don't know too well what the policy is for these sorts of files
- other catch all files like kernel.h I run through rdma.git from time
to time, but that is in relation to patches that depend on them..

> > Would prefer Miguel's Ack to do that though. Looks like Andrew Morton
> > took the original patch introducing the file?
> 
> Yep, I sent it to Andrew and he kindly picked it up. Probably he
> didn't notice this one.
> 
> As for the patch:
> 
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>

Lets give Andrew some time, he is probably very busy. If it gets to
rc5 without it getting picked up one of us can grab it instead to help
out..

Thanks,
Jason