public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Policy for checkpatch usage?
Date: Fri, 22 Apr 2011 20:56:39 +1000	[thread overview]
Message-ID: <4DB15EE7.7000404@gmail.com> (raw)
In-Reply-To: <4DB11DB7.7060008@aribaud.net>

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

  reply	other threads:[~2011-04-22 10:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-20  9:24 [U-Boot] Policy for checkpatch usage? Detlev Zundel
2011-04-20 10:15 ` Graeme Russ
2011-04-20 12:43   ` Graeme Russ
2011-04-20 13:40     ` Detlev Zundel
2011-04-20 13:38   ` Detlev Zundel
2011-04-20 16:51   ` Scott Wood
2011-04-21  0:09     ` Graeme Russ
2011-04-21  5:18       ` Wolfgang Denk
2011-04-21 14:24         ` Detlev Zundel
2011-04-21 14:29     ` Detlev Zundel
2011-04-21 14:49       ` Eric Cooper
2011-04-21 14:56         ` Fabian Cenedese
2011-04-21 15:04           ` Eric Cooper
2011-04-21 15:37             ` Detlev Zundel
2011-04-21 15:19           ` Detlev Zundel
2011-04-21 15:46         ` Detlev Zundel
2011-04-23 15:29           ` Andreas Pretzsch
2011-04-27  9:07             ` Detlev Zundel
2011-04-21 16:10       ` Scott Wood
2011-04-22  0:43         ` Graeme Russ
2011-04-22  6:18           ` Albert ARIBAUD
2011-04-22 10:56             ` Graeme Russ [this message]
2011-04-22  8:54           ` Wolfgang Denk
2011-04-22 10:52             ` Graeme Russ
2011-04-22 12:46               ` Wolfgang Denk
2011-04-25  5:37                 ` Graeme Russ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DB15EE7.7000404@gmail.com \
    --to=graeme.russ@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox