On Sat, Jan 25, 2020 at 04:08:39PM +0000, Chris Wilson wrote: > Quoting Wambui Karuga (2020-01-22 12:57:48) > > This series is a part of the conversion to the new struct drm_device > > based logging macros in drm/i915. > > This series focuses on the drm/i915/gem directory and converts all > > straightforward instances of the printk based logging macros to the new > > macros. > > Overall, I'm not keen on this as it perpetuates the mistake of putting > client debug message in dmesg and now gives them even more an air of > being device driver debug messages. We need a mechanism by which we > report the details of what a client did wrong back to that client > (tracefs + context/client getparam to return an isolated debug fd is my > idea). Sean is working on that, but it's a global thing still. Well since it's tracefs should be easy to filter for a given process at least. We've had long discussion about how to expose that, big fear (especially with atomic) is that clients/compositors will start to look at random debug strings and make them uapi. But I think for stuff like igt we should be able to wire it up easily and get it dumped when things go wrong. Maybe similar when mesa gets an unexpected errno. -Daniel > > Wambui Karuga (2): > > drm/i915/gem: initial conversion to new logging macros using > > coccinelle. > > drm/i915/gem: manual conversion to struct drm_device logging macros. > > Still this is a necessary evil for the current situation, > Acked-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > -Chris -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
