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 ? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
