On Wed, 2016-06-15 at 16:01 -0700, Kees Cook wrote: > On Wed, Jun 15, 2016 at 1:39 PM, Emese Revfy <re.emese@xxxxxxxxx> wrote: > > On Wed, 15 Jun 2016 11:55:44 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > 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 from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
