All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>,
	Chris Wilson <chris@chris-wilson.co.uk>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH] drm/i915: make GEM_WARN_ON less terrible
Date: Mon, 19 Mar 2018 22:21:31 +0200	[thread overview]
Message-ID: <87po3zzuic.fsf@intel.com> (raw)
In-Reply-To: <CAM0jSHPbC6YJZ0v5jn7X2Egu8ChJSdAKUB91rBPNbPfk54CMkw@mail.gmail.com>

On Mon, 19 Mar 2018, Matthew Auld <matthew.william.auld@gmail.com> wrote:
> On 19 March 2018 at 18:17, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> Quoting Matthew Auld (2018-03-19 18:08:54)
>>> GEM_WARN_ON() was originally intended to be used only as:
>>>
>>>    if (GEM_WARN_ON(expr))
>>>         ...
>>>
>>> but it just so happens to also work as simply:
>>>
>>>    GEM_WARN_ON(expr);
>>>
>>> since it just wraps WARN_ON, which is a little misleading since for
>>> !DRM_I915_DEBUG_GEM builds the second case will actually break the
>>> build. Given that there are some patches floating around which seem to
>>> miss this, it probably makes sense to just make it work for both cases.
>>
>> That really was quite intentional. The only time to use GEM_WARN_ON() is
>> inside an if, otherwise what's the point?
>
> Why wouldn't we want it to behave like WARN_ON? That seems to be what
> people expect, since it does wrap WARN_ON, and we don't always use
> WARN_ON in an if...

Looking at this, I'm more baffled by GEM_WARN_ON() evaluating to expr on
CONFIG_DRM_I915_DEBUG_GEM=y and 0 otherwise. That's the seriously
misleading part here.

Are you sure all those if (GEM_WARN_ON(expr)) are to be ignored? I'm no
expert on gem code, but I could be easily persuaded to believe not.


BR,
Jani.

PS. On the original question, if you design GEM_WARN_ON() to be used
within if conditions only, I think you better squeeze in an inline
function with __must_check.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-19 20:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 18:08 [PATCH] drm/i915: make GEM_WARN_ON less terrible Matthew Auld
2018-03-19 18:17 ` Chris Wilson
2018-03-19 19:23   ` Matthew Auld
2018-03-19 20:21     ` Jani Nikula [this message]
2018-04-04  9:13       ` Joonas Lahtinen
2018-04-04 10:05         ` Matthew Auld
2018-04-04 10:24           ` Joonas Lahtinen
2018-03-19 19:18 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-03-19 19:36 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-19 22:33 ` ✓ Fi.CI.IGT: " Patchwork

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=87po3zzuic.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.william.auld@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.