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