drm: add pseudo filesystem for shared inodes
authorDavid Herrmann <dh.herrmann@gmail.com>
Fri, 3 Jan 2014 13:09:47 +0000 (14:09 +0100)
committerDavid Herrmann <dh.herrmann@gmail.com>
Sun, 16 Mar 2014 11:17:03 +0000 (12:17 +0100)
commit31bbe16f6d88622d6731fa2cb4ab38d57d844ac1
tree2a123ae13d3e3a9de36f82304b74b8052545cb87
parent786a7828bc74b9b1466e83abb200b75f80f94121
drm: add pseudo filesystem for shared inodes

Our current DRM design uses a single address_space for all users of the
same DRM device. However, there is no way to create an anonymous
address_space without an underlying inode. Therefore, we wait for the
first ->open() callback on a registered char-dev and take-over the inode
of the char-dev. This worked well so far, but has several drawbacks:
 - We screw with FS internals and rely on some non-obvious invariants like
   inode->i_mapping being the same as inode->i_data for char-devs.
 - We don't have any address_space prior to the first ->open() from
   user-space. This leads to ugly fallback code and we cannot allocate
   global objects early.

As pointed out by Al-Viro, fs/anon_inode.c is *not* supposed to be used by
drivers for anonymous inode-allocation. Therefore, this patch follows the
proposed alternative solution and adds a pseudo filesystem mount-point to
DRM. We can then allocate private inodes including a private address_space
for each DRM device at initialization time.

Note that we could use:
  sysfs_get_inode(sysfs_mnt->mnt_sb, drm_device->dev->kobj.sd);
to get access to the underlying sysfs-inode of a "struct device" object.
However, most of this information is currently hidden and it's not clear
whether this address_space is suitable for driver access. Thus, unless
linux allows anonymous address_space objects or driver-core provides a
public inode per device, we're left with our own private internal mount
point.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
drivers/gpu/drm/drm_stub.c
fs/dcache.c