public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dim-tools@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: i915 vs checkpatch
Date: Thu, 1 Mar 2018 13:21:12 +0200	[thread overview]
Message-ID: <20180301112112.GV5453@intel.com> (raw)
In-Reply-To: <87371kuldh.fsf@intel.com>

On Thu, Mar 01, 2018 at 12:43:22PM +0200, Jani Nikula wrote:
> On Thu, 01 Mar 2018, Arkadiusz Hiler <arkadiusz.hiler@intel.com> wrote:
> > Since not so long ago our CI is running and reporting sparse and
> > checkpatch. Sparse is doing just fine but I had to disable checkpatch
> > for the time being - too much "false" positives causing people to
> > complain. It's simply confusing to see one thing in the code, and
> > fitting your change in only to get a report that it's wrong.
> >
> > We are explicitly going against couple of the recommendations it tries
> > to enforce, e.g. not using BIT macro, splitting quoted strings:
> > https://lists.freedesktop.org/archives/intel-gfx/2018-February/156613.html
> >
> > IMHO we should make a couple of decisions here:
> >  1. Do we really want to use the checkpatch / have CI reports?
> 
> I think yes, for the benefit of both patch authors and reviewers. For
> the most part, we do want to encourage uniform style.
> 
> >  2. Which of the checkpatch checks we want to disabled for i915?
> 
> One low hanging fruit is to ignore the CHECK messages, or drop the
> --strict option to checkpatch.pl in CI, although I think some of them
> are nice.

IMO the strict vs. not split is totally arbitrary. Some really obviously
correct warning are only enabled with strict, whereas even w/o strict
you get some warnings that are just plain silly. Thus I think strict
does more good than harm.

> 
> >  3. How strongly do we want to enforce the rest?
> 
> That's a tough one. With code movement, you want the code to remain the
> same instead of changing at the same time. And some of the warnings are
> subjective. For example, I'd prefer to stick with the 80 column rule but
> only when it makes sense. ;)
> 
> Another example, I would like to move towards kernel types over uint8_t
> and friends. However, when you have code surrounded by uint8_t and
> friends, it's often better to stick with the style around you.
> 
> >  4. Do we want to change what's already in the tree, for compliance?
> 
> No. I don't think we should encourage mindless checkpatch fixes.
> 
> Does checkpatch support disabling checks or do you have to filter them
> out from the output?
> 
> BR,
> Jani.
> 
> 
> >
> > Recent-ish drm-tip, vanilla checkpatch on i915 reports:
> > total: 399 errors, 3573 warnings, 209374 lines checked
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> dim-tools mailing list
> dim-tools@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-01 11:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-01  9:47 i915 vs checkpatch Arkadiusz Hiler
2018-03-01 10:43 ` Jani Nikula
2018-03-01 11:21   ` Ville Syrjälä [this message]
2018-03-02 16:07   ` Jani Nikula
2018-03-01 16:13 ` Jani Nikula
2018-03-01 18:00   ` Rodrigo Vivi
2018-03-02  9:37     ` Joonas Lahtinen
2018-03-02 10:07       ` Jani Nikula
2018-03-01 23:17 ` Chris Wilson
2018-03-05 12:55   ` Arkadiusz Hiler
2018-03-05  8:14 ` Daniel Vetter
2018-03-05 11:10   ` Jani Nikula
2018-03-05 12:44     ` Arkadiusz Hiler
2018-03-13 11:38       ` Jani Nikula

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=20180301112112.GV5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dim-tools@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=rodrigo.vivi@intel.com \
    /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