[Intel-gfx] [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem

[Chris Wilson]

On Thu, Dec 01, 2016 at 10:48:31AM +0200, Jani Nikula wrote:
> On Thu, 01 Dec 2016, swati.dhingra at intel.com wrote:
> > Currently, for the purpose of providing output debug/loggging/crc and various
> > other kinds of data from DRM layer to userspace, we don't have a standard
> > filesystem, which would suffice for all the usecases. The filesystems used
> > currently such as debugfs/sysfs have their own constraints and are intended
> > to output a particular type of data. For instance, sysfs is suitable for
> > exporting only small data in form of attributes, thus not suitable to export
> > large data such as error states/logs/crc etc. Likewise for debugfs, which is
> > not available in production kernels, and may not be best place to hold certain
> > kinds of data. As a result, we currently are creating certain files in these
> > filesystems, which are not particularly suited there (For, i915, guc_log is a
> > case in point, which is currently created in debugfs, but not particularly
> > suited there).
> >
> > Due to these constraints, there is a need for a new pseudo filesytem,
> > customizable to DRM specific requirements and catering to the needs to DRM
> > subsystem components. This will provide a unified location to hold various
> > kinds of data from Linux DRM subsystems, for the files which can't really fit
> > anywhere else into the existing filesystems.
> 
> I don't think you properly describe the problems you have with the
> current interfaces. You need to be very specific here.
> 
> I don't think having one "standard filesystem" for drm that would cover
> all use cases is going to work out. We will need to combine several
> interfaces for our needs.

The only thing that DRM is registering is a filesystem to manage a
canonical mountpoint. That does not limit everyone to only using that
psuedofs underneath.

> Do you realize that you can't really remove anything from the current
> ABI? You can't move stuff from, say, sysfs to your new drmfs, you'd only
> be able to duplicate the API...

Exactly, why we wanted an ABI kernfs in the first place. sysfs is not
compatible, debugfs is not ABI.

> Did you notice that a new interface for CRCs was recently introduced?
> 
> Did you look at all options, such as adding a new device node for the
> guc logging needs, instead of adding a whole new filesystem? What is
> wrong with that? Where does it fall short?

Adding a device node was pretty ugly in comparison and would be less
transferrable/sharable to similar situations in future, or between
DRM drivers.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre