[Intel-gfx] [RFC 00/12] Support for sustained capturing of GuC firmware logs

[Chris Wilson]

On Fri, Jun 03, 2016 at 03:44:09PM +0530, Goel, Akash wrote:
> 
> 
> On 6/3/2016 12:45 PM, Daniel Vetter wrote:
> >On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
> >>On Thu, 2016-06-02 at 10:16 +0000, Daniel Vetter wrote:
> >>
> >>>I still kinda like relayfs, except that it's not available in non-
> >>>debug builds. But so are plenty of other really interesting files we
> >>>have hidden in there.
> >>>
> >>>sysfs isn't the solution, I already have a black eye from the sysfs
> >>>maintainer for our error state.
> >>
> >>Heh. I tend to agree though.
> >>
> >>>No idea really where to put stuff. One option might be to have an
> >>>official debug directory (like we have power already) in sysfs as the
> >>>canonical place where drivers can dump stuff. We're not the only ones
> >>>with too much data to get to userspace for debugging driver/hw
> >>>issues, e.g. wireless firmware has pretty similar solutions.
> >>
> >>We have two things in wireless:
> >>
> >> 1) the devcoredump stuff, but that's a one-time event when something
> >>    bad happens and dumps a big blob into userspace, doesn't seem
> >>    relevant here
> >>
> >> 2) continuous logging, which uses a debugfs file (though it could be
> >>    relayfs as well, doesn't really make a difference)
> >
> >relayfs apparently moved in with debugfs. And a requirement (or at least
> >strong wishlist item) is that we can get at the data on production systems
> >(which really shouldn't mount debugfs). Seems like there's no place to
> >dump debug information outside of debugfs :(
> >
> >>There could be something said for using tracing, but that's only
> >>independent of debugfs since the tracefs introduction in kernel 4.1.
> >
> >We tried looking into tracing stuff for our performance counters, and at
> >least there the mismatch for dumping large-scale stuff was too much. But
> >tracefs looks like just the tracing debugfs directory cut out into a
> >separate filesystem, exactly to avoid that dreaded debugfs-is-insecure
> >issues.
> >
> >I'd say we should smash it into debugfs, and if these troubles persist
> >then maybe we need to clean up the mess in there a bit and expose it as
> >drm_debugfs or whatever. Probably a topic for kernel summit even. At least
> >I feel like there's not enough consensus to add ABI at this point.
> Hi Daniel,
> 
> Thanks much for your inputs.
> 
> So, on interim basis, can we have a relay backed debugfs interface only
> i.e. /sys/kernel/debug/dri/guc_log.
> 
> And once the support for drm_debugfs is added, its just a matter of
> changing the file location, i.e. move it inside the drm_debugfs.

Only, it will be called drm_kernfs :) Don't want to confuse people that
it won't be a stable ABI. Maybe drm_stablefs!

To start the ball rolling, canonical mountpoint:

	/sys/kernel/gpu # like /sys/kerenl/mm
	/sys/kernel/drm
	/sys/kernel/dri # like /dev/dri

?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre