Patch Set 2:
This was already discussed at length previously (e.g. in CB:27533). The arguments for 80 characters are not primarily for the number itself but for consistency with other projects. Moving it to 96 characters isn't some compromise that makes everyone somewhat happy, it's just as bad for consistency as any other limit that's not 80.
These "other projects" would be mostly Linux, since that's the style we're closest to: try getting our code into a GNU project (for example) without reformatting it entirely.
But we are not Linux. IS_ENABLED() has different semantics than Linux's, oh, and we use CONFIG() now. Our Kconfig has different semantics than Linux's. We use volatile, which is frowned upon in Linux.
I don't think it's appropriate to just sneak in such a wide-ranging and clearly very controversial policy change in the night without letting anyone know,
I wasn't aware that it was night from Feb 27 to Mar 5.
This commit doesn't change everything from 80 to 96: it changes checkpatch from 80 to 96 and clang-format from "whatever" to 96. A plain revert would bring that inconsistency back and so I'm strongly opposed to that.
But how about this: We modify checkpatch so we can disable its coding style checks (as opposed its more useful tests about CONFIG(), for example) and do that for everything that is covered by clang-format (as defined in .clang-format-scope).
That also neatly solves the remaining consistency issues (see the checkpatch warnings in CB:31652 that complain about code as produced by clang-format) by having one tool decide on style instead of two tools fighting it out.
With that we can go back to clang-format's ColumnLimit: 0 (ie its "whatever" option) for the code it handles and checkpatch back to 80 for the code that it doesn't.
To view, visit change 31651. To unsubscribe, or for help writing mail filters, visit settings.