Re: [RFC 00/12] Support for sustained capturing of GuC firmware logs

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Jun 03, 2016 at 11:20:19AM +0100, Chris Wilson wrote:
> 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
> 
> ?

/me casts vote for gpu. Maybe someone will get bored and move the
vga_switcheroo stuff out of debugfs too ;-)
-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