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
next prev parent 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