* ron minnich <rminnich(a)gmail.com> [160727 02:26]:
A couple of questions preceded by the usual
curmudgeonly comment :-)
I'm not a big fan of checkpatch.pl. It's 5965 lines of dense perl spaghetti
code, continues to grow, and is attempting to achieve that which I understand
may be impossible: parsing C with REs and random blobs of PERL. Given that the
problem may be impossible, checkpatch finds it hard, and makes mistakes, as
experienced on the projects that use it.
It also finds a lot of inconsistencies in our code base, which are
(arguably) worth fixing.
It's not surprising it continues to grow, and not
surprising it's got lots of
errors. You can find discussions on the various lists which boil down to "just
ignore checkpatch.pl in this case." This is not confidence-inspiring.
I didn't see any errors reported since its use in coreboot, besides the
current discussion of whether it is the right thing to abstract out gcc
__attribute__(()) qualifiers or not.
I'd most prefer to move to clang-format for this
sort of thing, which is what
we're doing on at least one other kernel project I work on.
clang-format's scope is very different. It copes with whitespace, more
I continue to not understand the injunction on
typedefs; operating systems
written by the inventors of C continued to use them until Bell Labs disbanded
the OS group in 2015 ...
Finally, why the use of packed? In general you really
only want to use packed
when you're using it to directly address data. Why not deserialize the data
from memory into an unpacked struct? That's how ACPICA seems to do it.
Because in most cases, it is not data, but register space we are
Are you suggesting to learn our coding style from ACPI? Who are you and
what did you do to Ron Minnich? ;)