On 2016-09-01 at 22:17 "'Christopher Koch' via Akaros"
> Akaros seems to require some things that the Linux kernel style guide
> doesn't ask for.
> 
> For example, parameters of a function definition are indented with spaces
> if they do not fit into 80 characters. Same for function calls and
> arguments. The Linux kernel style guide does not specify spaces, which
> means it's tabs, and it only specifies that the new line be indented
> "substantially to the right" (as opposed to aligning with parens).

Feel free to ignore the tabs vs spaces there.  I've said that in the
past, before your time, but the guide is out of date on that.  I don't
complain about either usage (spaces for alignment or tabs + spaces),
and neither does checkpatch.  Sorry - that's one of many things that
are out of date.

> I'm not sure I've argued about formatting before. So I've definitely spent
> way more time formatting. But it's time now.
> 
> Let people automate this. A tool serves two purposes here: it kills the
> time spent formatting manually, and it kills the time spent arguing
> (because you can just point to the tool).

If you have a tool that automates well, then I'd be okay with it.  When
it doesn't, then I have a problem.  I care about the output, not the
method.  I don't think we have tools that do a good job at this.  For
instance, the tool doesn't help here (assuming you used it):

> @@ -48,7 +55,7 @@ struct uthread *thread0_uth;
>   * don't actually attach this mgmt info to it.  But since we just have one
>   * thread, it doesn't matter. */
>  struct thread0_info {
> -     bool                                            is_blocked;
> +     bool is_blocked;  

Barret

-- 
You received this message because you are subscribed to the Google Groups 
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to