Thread (15 messages) flat view 15 messages, 6 authors, 2021-10-05

Re: [PATCH v4] docs: Explain the desired position of function attributes

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2021-10-02 06:31:54
Also in: linux-hardening, lkml

On Fri, Oct 01, 2021 at 12:05:25PM -0700, Nick Desaulniers wrote:
On Thu, Sep 30, 2021 at 4:58 PM Kees Cook [off-list ref] wrote:
quoted
While discussing how to format the addition of various function
attributes, some "unwritten rules" of ordering surfaced[1]. Capture as
close as possible to Linus's preferences for future reference.

(Though I note the dissent voiced by Joe Perches, Alexey Dobriyan, and
others that would prefer all attributes live on a separate leading line.)

[1] https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/ (local)

Signed-off-by: Kees Cook <redacted>
While I appreciate you getting the ball across the finish line (having
_any_ documentation to point to in future bikesheds), I can't help but
shake the feeling that the chosen policy will harm the ability of
existing automated code formatting tools from being able to automate
code formatting on the kernel.
Why would documenting the expected format have an affect on tools not
being able to follow that exact expected format?  Are we defining a
format that is somehow impossible for them to use?

If anything I would think that now we have a format that the tools can
actually follow, while before it was semi-random as to what to pick as
the "one true way".

What am I missing here?

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help