Re: [PATCH v2] drm/i915: Tune down init error message due to failure injection

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Mar 18, 2016 at 11:15:35AM +0200, Imre Deak wrote:
> On Fri, 2016-03-18 at 10:59 +0200, Joonas Lahtinen wrote:
> > On pe, 2016-03-18 at 00:18 +0200, Imre Deak wrote:
> > > On Thu, 2016-03-17 at 22:14 +0000, Chris Wilson wrote:
> > > > 
> > > > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote:
> > > > > 
> > > > > On Thu, 2016-03-17 at 21:48 +0000, Chris Wilson wrote:
> > > > > > 
> > > > > > I would also like this to be the preferred
> > > > > > DRM_ERROR reporting mechanism i.e. anytime we emit an ERROR
> > > > > > we
> > > > > > should
> > > > > > be
> > > > > > encouraging the user to file a bug, and do so in a user
> > > > > > friendly
> > > > > > fashion.
> > > > > Ok, but only in i915 I assume. Should we also convert then all
> > > > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still use
> > > > > DRM_ERROR?
> > > > Within i915. I am thinking along the lines that no DRM_ERROR
> > > > should
> > > > exist that doesn't acknowlege that it is a user facing error
> > > > message
> > > > (i.e. written in plain English and is informative, and includes a
> > > > bug
> > > > reporting reference). So i915_report_error() or somesuch.
> > > Ok, will give it a go.
> > 
> > Daniel didn't want i915 debugging/erroring mechanisms to deviate from
> > core DRM. So I guess this would follow in the same category.
> > 
> > I'm all in for structuring a coherent debugging/error message logic
> > and
> > functions for it and then everyone can follow the suit.
> 
> The dev_err/dbg method has obvious advantages, like dynamic debug or
> showing the device instance, so I think that's something we want in any
> case. I don't see a problem with first rolling it out in i915 then
> proposing it for more generic use.

Well that's just silly me trying to apply some pressure into making
something that's compatible with DRM_*. Or well, porting those macros over
to whatever the newfangled fancy thing is. Including keeping drm.debug
alive with some hacks (we can write our own store functions, which could
enable the right stuff with dynamic debugging, if we export a few funcs)
so that the gazillion of howtos out there don't all break.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx