On Mon, Jan 20, 2020 at 01:56:21PM -0500, Steven Rostedt wrote: > On Thu, 16 Jan 2020 07:27:22 +0100 > Daniel Vetter <daniel@xxxxxxxx> wrote: > > > On Tue, Jan 14, 2020 at 12:21:43PM -0500, Sean Paul wrote: > > > From: Sean Paul <seanpaul@xxxxxxxxxxxx> > > > > > > This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston) > > > of DRM logs for a specified set of debug categories. The user writes a > > > bitmask of debug categories to the "trace_mask" node and can read log > > > messages from the "trace" node. > > > > > > These nodes currently exist in debugfs under the dri directory. I > > > intended on exposing all of this through tracefs originally, but the > > > tracefs entry points are not exposed, so there's no way to create > > > tracefs files from drivers at the moment. I think it would be a > > > worthwhile endeavour, but one requiring more time and conversation to > > > ensure the drm traces fit somewhere sensible. > > > > Hm, since the idea is to ship this in production environments debugfs is > > out. sysfs is also kinda the wrong thing, so maybe trying to get this > > stuffed into tracefs is actually the way to go? > > > > Why not use normal tracepoints and the tracing infrastructure? You can > add your own instance as rasdaemon does, which isn't affected by other > tracing. There's code now to even create these instances and enable and > disable events from within the kernel. > > https://lore.kernel.org/lkml/1574276919-11119-1-git-send-email-divya.indi@xxxxxxxxxx/ Hm, without looking at the details this indeed seems like the thing we want ... Sean? -Daniel > > As this is tracefs, you can mount it without even compiling in debugfs. > > -- Steve -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
