On Wed, 2016-06-15 at 16:01 -0700, Kees Cook wrote:

On Wed, Jun 15, 2016 at 1:39 PM, Emese Revfy [off-list ref] wrote:

quoted

On Wed, 15 Jun 2016 11:55:44 -0700 Kees Cook [off-list ref] wrote:

quoted

 The limit on the length of lines is 80 columns and this is a strongly
 preferred limit.

I think the code looks worse when it is truncated to 80 columns but
I'll do it and resend the patches.

Yup, I understand your concerns, but since we're optimizing for
readability by a larger audience that has agreed to the guidelines in
CodingStyle, this is what we get. :)

One area I'm unclear on with kernel coding style, though, is if
splitting all the stuff prior to function name onto a separate line is
"acceptable", since that solves most of the long lines where
__latent_entropy has been added. For example, I don't know which is
better:

All on one line (gmail may split this, but my intention is all one line):

static __latent_entropy void rcu_process_callbacks(struct
softirq_action *unused)

Types and attributes on a separate line:

static __latent_entropy void
rcu_process_callbacks(struct softirq_action *unused)

All arguments on the next line:

static __latent_entropy void rcu_process_callbacks(
                                                          struct
softirq_action *unused)


Greg, do you have a better sense of how to split (or not split) these
kinds of long lines?

Another option is to add __latent_entropy the same way most
__printf uses are done - on a separate line before the function

__latent_entropy
static void foo(...)


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>