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. --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
