On Tue, Dec 20, 2016 at 4:44 AM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Tue, 20 Dec 2016, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> Hi Swati, >> >> On Monday 19 Dec 2016 16:12:22 swati.dhingra@xxxxxxxxx wrote: >>> From: Swati Dhingra <swati.dhingra@xxxxxxxxx> >>> >>> Currently, we don't have a stable ABI which can be used for the purpose of >>> providing output debug/loggging/crc and other such data from DRM. >>> The ABI in current use (filesystems, ioctls, et al.) have their own >>> constraints and are intended to output a particular type of data. >>> Few cases in point: >>> sysfs - stable ABI, but constrained to one textual value per file >>> debugfs - unstable ABI, free-for-all >>> ioctls - not as suitable to many single purpose continuous data >>> dumping, we would very quickly run out ioctl space; requires more >>> userspace support than "cat" >>> device nodes - a real possibilty, kernel instantiation is more tricky, >>> requires udev (+udev.rules) or userspace discovery of the >>> dynamic major:minor (via sysfs) [mounting a registered >>> filesystem is easy in comparison] >>> netlink - stream based, therefore involves numerous copies. >>> >>> Debugfs is the lesser among the evils here, thereby we have grown used to >>> the convenience and flexibility in presentation that debugfs gives us >>> (including relayfs inodes) that we want some of that hierachy in stable user >>> ABI form. >> >> Seriously, why ? A subsystem growing its own file system sounds so wrong. It >> seems that you want to have all the benefits of a stable ABI without going >> through the standardization effort that this requires. I can see so many ways >> that drmfs could be abused, with drivers throwing in new data with little or >> no review. You'll need very compelling arguments to convince me. > > This is not unlike my sentiments on the first version posted > [1]. There's also the distinct feeling of [2]. Suffice it to say at this > time that I'm dubious, not convinced enough to defend this. > > Swati, please refrain from posting new versions of the patches until > there's some consensus one way or the other; it's counter-productive to > keep splitting off the discussion into several patch series threads at > this stage. Let's have the discussion here. > I'll echo Laurent's concerns here, seems like the goal is easy to merge, hard to change. I think the problem with this is that easy to merge usually leads to designs which need to change :) Secondly, I'm not sure there's value outside of i915, perhaps I'm missing use cases for other drivers. Sean > > BR, > Jani. > > > [1] http://mid.mail-archive.com/87lgw0xcf4.fsf@xxxxxxxxx > [2] https://xkcd.com/927/ > >> >>> Due to these limitations, there is a need for a new pseudo filesytem, that >>> would act as a stable 'free-for-all' ABI, with the heirarchial structure and >>> thus convenience of debugfs. This will be managed by drm, thus named >>> 'drmfs'. DRM would register this filesystem to manage a canonical >>> mountpoint, but this wouldn't limit everyone to only using that pseudofs >>> underneath. >>> >>> This can serve to hold various kinds of output data from Linux DRM >>> subsystems, for the files which can't truely fit anywhere else with >>> existing ABI's but present so, for the lack of a better place. >>> >>> In this patch series, we have introduced a pseudo filesystem named as >>> 'drmfs' for now. The filesystem is introduced in the first patch, and the >>> subsequent patches make use of the filesystem interfaces, in drm driver, >>> and making them available for use by the drm subsystem components, one of >>> which is i915. We've moved the location of i915 GuC logs from debugfs to >>> drmfs in the last patch. Subsequently, more such files such as pipe_crc, >>> error states, memory stats, etc. can be move to this filesystem, if the >>> idea introduced here is acceptable per se. The filesystem introduced is >>> being used to house the data generated by i915 driver in this patch series, >>> but will hopefully be generic enough to provide scope for usage by any >>> other drm subsystem component. >>> >>> The patch series is being floated as RFC to gather feedback on the idea and >>> infrastructure proposed here and it's suitability to address the specific >>> problem statement/use case. >>> >>> v2: fix the bat failures caused due to missing config check >>> >>> v3: Changes made: >>> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) >>> - Moving config checks to header (Chris,Daniel) >>> >>> v4: Added the kernel Documentaion (using Sphinx). >>> >>> Sourab Gupta (4): >>> drm: Introduce drmfs pseudo filesystem interfaces >>> drm: Register drmfs filesystem from drm init >>> drm: Create driver specific root directory inside drmfs >>> drm/i915: Creating guc log file in drmfs instead of debugfs >>> >>> Documentation/gpu/drm-uapi.rst | 76 ++++ >>> drivers/gpu/drm/Kconfig | 9 + >>> drivers/gpu/drm/Makefile | 1 + >>> drivers/gpu/drm/drm_drv.c | 26 ++ >>> drivers/gpu/drm/drmfs.c | 566 ++++++++++++++++++++++++++ >>> drivers/gpu/drm/i915/i915_guc_submission.c | 33 +- >>> include/drm/drm_drv.h | 3 + >>> include/drm/drmfs.h | 77 ++++ >>> include/uapi/linux/magic.h | 3 + >>> 9 files changed, 773 insertions(+), 21 deletions(-) >>> create mode 100644 drivers/gpu/drm/drmfs.c >>> create mode 100644 include/drm/drmfs.h > > -- > Jani Nikula, Intel Open Source Technology Center > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
