>> Hi
>>
>> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
>>> Hi
>>>
>>> With 3.13-rc1 the required VFS core changes for anonymous backing inodes in DRM
>>> got merged. This series reworks the previous patches (I think from early
>>> August '13) and finally replaces the ugly drm_device->dev_mapping hack.
>>>
>>> The patches should be fairly obvious. As I currently only have nouveau here, I'd
>>> be happy to get some more testers with other drivers.
>>>
>>> Patch #1 adds an internal private mount point to DRM core.
>>> Patch #2 replaces ->dev_mapping with a private anonymous inode for each device.
>>> Patch #3 removes the delayed dev_mapping initialization in TTM.
>>>
>>> The internal mnt-point is based on fs/aio.c and fs/anon_inode.c which do the
>>> same. It's not clear to me why we cannot share the mnt-point between all these,
>>> but Al Viro made clear that he will reject any patches on anon_inode.c which do
>>> that. So lets follow his recommendation and use our own internal mnt-point.
>> Also tested on i915 ivb now (before: nouveau+TTM). I think this is
>> ready for 3.14 if nobody finds any issues.
>
I talked to Al,
7:13 < viro> umm...
17:14 < viro> you do realize that your module will be impossible to unload?
17:14 < viro> kern_mount will pin that fs down
17:14 < viro> bumping module refcount
17:15 < viro> so kern_unmount() in module_exit is not going to be called at all
17:15 -!- rafael__ [^rafael@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit
[Ping timeout: 608 seconds]
17:16 < viro> what you want is some variation on simple_pin_fs()
17:17 < viro> done from drm_dev_alloc()
17:18 < viro> with simple_release_fs() from drm_dev_free(), right after iput()
17:20 < viro> the export itself is OK (albeit we might be better off
exporting a variant of mount_pseudo() instead, so that aio and
this sucker would both just call mount_dname_pseudo())
17:21 < viro> the problem I see there is with kern_mount() use
17:47 -!- sameo [~samuel@192.55.55.41] has quit [Remote host closed
the connection]
So maybe we should think about it a bit more :-)
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
