Le 22/04/2011 02:43, Graeme Russ a écrit :
So, if someone maintains a U-Boot fork of checkpatch, keeps it up-to-date with the Linux version, and pushes patches back up to Linux (to keep them is sync as much as practicable possible) would we agree that that would be the most favoured solution?
I don't know about 'the most favoured', but I would agree that it would be a good way to implement a "zero error, zero warning" policy that actually makes sense, because we'll be the ones who decide what causes an error or warning and what does not. We could even serenely make it "absolutely zero error, ideally zero warning unless justified" if we can control which checks are warnings and which checks are errors.
I'm looking at checkpatch now (and its change history) - If I think I can take it on, I will send out a call for U-Boot specific checkpatch features
Wish you luck -- as I said, I did try once to have a fairly simple change put in the Linux checkpatch (make maximum line length a command line option), and I got zero answer, both public or private. As checkpatch compliance could be attained without this change, I eventually gave up, but a reactive 'u-checkpatch.pl' maintainer surely will attract my interest -- FWIW. :)
As for 'U-Boot specific features', I would advise to rather consider 'non-Linux-specific features'. We're having issues with the current checkpatch because it is Linux-centric (it either tests for actual Linux source-code related features or enforces 'Linux cultural' choices); replacing these Linux-specific checks with U-Boot specific checks would make the Linux and U-Boot checkpatches diverge.
So my personal Xmas wishlist #1 is to be able to choose the set of checks that will be performed and which ones will be errors vs warnings. Could be a command line option ('--linux' to apply the set of checks for a Linux patch and '--u-boot' for an U-Boot patch) or a configuration file, for instance.
Regards,
Graeme
Amicalement,