Re: [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem

[Jani Nikula <jani.nikula@linux.intel.com>]

On Thu, 01 Dec 2016, swati.dhingra@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.

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...

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?

My first impression here is that you think this will make things easier,
but eventually you'll notice you've ended up with all the same problems
as before, but with an additional filesystem to maintain to the end of
time.

I'm not a fan unless you come up with much more compelling reasons.

BR,
Jani.


PS. Needs to be posted to dri-devel.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx