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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-Daniel
-- 
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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux