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

[Goel, Akash]

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.

Best regards
Akash

> -Daniel
>