[Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces

Chris Wilson chris at chris-wilson.co.uk
Sat Dec 3 09:25:53 UTC 2016


On Sat, Dec 03, 2016 at 06:23:20AM +0530, sourab gupta wrote:
> On Fri, 2016-12-02 at 14:40 -0800, Roper, Matthew D wrote:
> > Am I correct in assuming the data made available via drmfs is not
> > considered ABI?  If we're not going to guarantee a stable ABI and
> > backward compatibility forever for the items exposed here, then it's
> > important to state that very explicitly up front so that no userspace
> > software gets written with the wrong assumption.  I'd suggest making an
> > explicit note one way or the other in the commit message here and
> > probably in the Kconfig help text as well.
> 
> We've intended for drmfs to be ABI as Chris mentioned here:
> https://lists.freedesktop.org/archives/intel-gfx/2016-December/113245.html
> The intent is for drmfs to be a stable ABI for the files it's holding.
> This can be ensured moresoever since it'll be under sole control of drm.
> Chris, can you correct me if i'm wrong.

sysfs: stable ABI, one textual value per file
debugfs: unstable ABI, free-for-all

Proposed drmfs: stable ABI, free-for-all

Alternatives: ioctls, device nodes, netlink

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

In short, 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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list