well, once a subsystem is "checkpatch-clean" (which my challenge above
obviously assumes), there's no such "partial style" problem. It
obviously also assumes that the maintainer agrees that having consistent
coding style across all of Linux is a long-term advantage.
The current visual inconsistency between subsystems makes the Linux
kernel appear rather unpleasant and unprofessional to new kernel
developers. This is not just embarrasing to us (we want to write the
best OS on the planet), it is also actively harmful: such a "consistent
style does not matter" stance turns away people who have taste and tends
to attract people who have no taste - which i'm sure you'll agree with
results in a deadly spiral if it gets strong enough.
So to turn around the argument: could you give me any reason why
differing coding style between subsystems, _often in blatant violation
of Documentation/CodingStyle_, is somehow "good" for Linux in the long
run? I listed numerous first-hand advantages that style consistency
brings and i listed numerous disadvantages created by inconsistency. So
i'm waiting for the list of counter-arguments - there _must_ be some
objective ones, besides the obvious "kernel old-timers are lazy to
change their ways" argument =B-)
In my experience in almost all cases the "style disagreement" between a
subsystem maintainer and checkpatch is due to the _maintainer_ being
wrong about seemingly unimportant (to him) style details.
And that very much includes myself: i used to have such "disagreement"
with checkpatch errors and i used to be annoyed at the style nitpicking
of checkpatch. And yes, it takes a certain amount of time for a
long-time kernel hacker like me to realize that a lot of code i wrote in
the past needs a good clean-up ;-)
These style differences are certainly not "wrong enough" to
inconvenience or displace an active maintainer (and i never made that
point), but they are nevertheless a death by a thousand cuts that the
general kernel is suffering from right now, and i'd be a fool not to
point it out. These seemingly unimportant style details add up to a
hodgepodge of coding style that makes life difficult for people who have
to look at many different parts of the kernel that they _dont maintain_.
That's why i asked about specific examples that we can talk about - and
i gave specific examples and filenames. The checkpatch maintainer (Andy
Whitcroft) has certainly shown flexibility to fix false positives ASAP.
note, all those patches are "Subject: x86: " and 99% of them is
maintained by us x86 maintainers.
Ingo
--
