From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Fri, 22 Apr 2011 20:56:39 +1000 Subject: [U-Boot] Policy for checkpatch usage? In-Reply-To: <4DB11DB7.7060008@aribaud.net> References: <20110420115129.2a70418b@schlenkerla.am.freescale.net> <20110421111036.2abb4255@schlenkerla.am.freescale.net> <4DB0CF2F.2020701@gmail.com> <4DB11DB7.7060008@aribaud.net> Message-ID: <4DB15EE7.7000404@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 22/04/11 16:18, Albert ARIBAUD wrote: > 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. Checks which we do not have control over using the Linux checkpatch > >> 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. :) Well, I don't know perl (yet) but the code looks very neat and nicely laid out and all the checks well documented. Recent activity has not been that extreme so I don't think keeping a U-Boot version in sync with Linux will be that hard > 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. I don't think the Linux guys are too concerned about white-space cleanups in patches which include functional changes, but we are > 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. I think wrapping our requirements around a command line option is a good idea anyway, even if the Linux guys do not accept our changes to checkpatch. I want to make it so a single option makes any U-Boot fork of checkpatch behave exactly like the Linux version. That would mean combined U-Boot/Linux developers only need to worry about a single script Regards, Graeme