From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Remove function details from device error messages
Date: Mon, 9 Jul 2018 14:13:58 -0700 [thread overview]
Message-ID: <20180709211358.GJ28253@intel.com> (raw)
In-Reply-To: <153116724531.18500.79534091888257135@skylake-alporthouse-com>
On Mon, Jul 09, 2018 at 09:14:05PM +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-07-09 18:51:02)
> > On Mon, Jul 09, 2018 at 02:48:58PM +0100, Chris Wilson wrote:
> > > Error messages are intended to be addressed to the user; be clear,
> > > succinct, instructive and unambiguous. Adding the function name to
> > > that message does not add any information the user requires and in
> > > the process makes the message less clear.
> > >
> > > E.g.
> > >
> > > [ 245.539711] i915 0000:00:02.0: [drm:i915_gem_init [i915]] Failed to initialize GPU, declaring it wedged!
> >
> > Overall I like the idea...
> >
> > The down side is that for us when debugging we would need to always trust grep like
> > searches and many debug messages are constructed out of variables what makes it a bit
> > hard to find sometimes. Ok, nothing that we couldn't figure out...
>
> A big difference is that error messages are targeted at the user, and as
> such should be succinct and not require them to dig into the source code
> to understand what it means and what action they need to take. Usually
> such error messages are accompanied by a lot of debug output for
> developers to pour over, but for the average user, imo we just need to
> say what broke and no longer works, and how they can file a bug (any
> information we need for that bug should be captured automatically and
> read for them to attach).
it makes sense.
>
> > > becomes
> > >
> > > [ 245.539711] i915 0000:00:02.0: Failed to initialize GPU, declaring it wedged!
> >
> > What about adding an "ERROR:" ?
>
> The KERN_ERR is recorded in the output for the userspace application to
> decide how to colourize and highlight when it presents the kmsg records.
hmm... good point.
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-07-09 21:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 13:48 [PATCH] drm/i915: Remove function details from device error messages Chris Wilson
2018-07-09 14:36 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-07-09 17:51 ` [PATCH] " Rodrigo Vivi
2018-07-09 20:14 ` Chris Wilson
2018-07-09 21:13 ` Rodrigo Vivi [this message]
2018-07-09 20:57 ` ✗ Fi.CI.IGT: failure for " 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=20180709211358.GJ28253@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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.