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
