• David Herrmann's avatar
    drm: add pseudo filesystem for shared inodes · 31bbe16f
    David Herrmann authored
    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: default avatarDavid Herrmann <dh.herrmann@gmail.com>
    31bbe16f
dcache.c 87.7 KB