* ron minnich rminnich@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 like indent.
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 ...
Agreed.
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 accessing.
Are you suggesting to learn our coding style from ACPI? Who are you and what did you do to Ron Minnich? ;)
thanks
ron
Stefan