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
