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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 27 Jun 2018 16:07:25 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Jason Gunthorpe <jgg@...lanox.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 9:33 PM, Jason Gunthorpe <jgg@...lanox.com> wrote:
> 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...

OK -- I will send the MAINTAINERS update patch :)

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

Sure! :)

(and thanks!)

Cheers,
Miguel

>
> Thanks,
> Jason