[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[swati.dhingra@intel.com]

From: Swati Dhingra <swati.dhingra@intel.com>

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.

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.

TODO: Create documentation. Will do so in next version.

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)


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

 drivers/gpu/drm/Kconfig                    |   9 +
 drivers/gpu/drm/Makefile                   |   1 +
 drivers/gpu/drm/drm_drv.c                  |  12 +
 drivers/gpu/drm/drmfs.c                    | 555 +++++++++++++++++++++++++++++
 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 +
 8 files changed, 672 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/drmfs.c
 create mode 100644 include/drm/drmfs.h

-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx