On Thu, Dec 01, 2016 at 10:48:31AM +0200, Jani Nikula wrote: > On Thu, 01 Dec 2016, swati.dhingra@xxxxxxxxx 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
