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. 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
