Messages in this thread | | | Date | Tue, 5 Aug 2008 08:22:11 +1000 | From | "Dave Airlie" <> | Subject | Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM |
| |
On Tue, Aug 5, 2008 at 7:58 AM, Keith Packard <keithp@keithp.com> wrote: > On Mon, 2008-08-04 at 19:02 +1000, Nick Piggin wrote: > >> > I suppose we could have user space allocate the shmem file (either via >> > tmpfs or sysv ipc). tmpfs suffers from the maxfd issue, while sysv ipc >> > runs up against the SHMMAX value. >> >> This is how I'd suggested it work as well. I think a little bit >> more effort should be spent looking at making this work. > > Well, I've spent a day thinking about using existing user-space APIs to > get at shmem files. While it's nice that we've discovered a > filesystem-independent mechanism to pin file pages, we haven't found > anything similar for creating the files. In particular, what I want is: > > 1) Anonymous files backed by swap > 2) Freed when the last process using them exits > 3) That never appear in the file system > 4) Do not consume a low FD (yeah, I know, rewrite the desktop) > > So, what I could do is > > char template[] = "/dev/shm/drm-XXXXXX"; > int fd; > fd = mkstemp (template); > unlink (template); > ftruncate (fd, size) > object = drm_create_an_object_for_a_file (fd); > close (fd); > > While I haven't written any code yet, this should work and will even be > compatible with my current user-space API. I have to create a DRM object > for the file in any case, and so I don't need to hold onto the fd. > Releasing the fd also eliminates any ulimit issues. > > The drm_create_an_object_for_a_file call could return another fd. But, > note that the original shmem fd has no real value to the application in > this case. > > I can imagine other cases where mapping non-shmem files would make sense > though, in particular it's fairly easy to envision mapping an image file > to the GTT and having the graphics process decode and display it without > any additional copies. I think this demonstrates the potential utility > of the general file mapping operation. > > But, I'd like to have you reconsider whether it makes sense for user > space to go through the above dance to create anonymous shared objects > when the kernel already supports precisely the desired semantics and > even exposes them to the ipc/shm implementation. > > We'd offer two paths in DRM -- one that used an existing file and > created an object using that as backing store, and a second one that > created anonymous objects using shmem as backing store. Transient data > would use anonymous objects while applications could directly map > arbitrary file contents as well.
We also have a need to create in-kernel objects for things like fbcon. If we cannot create these without doing a major dance around the vfs then it'll be rather ugly.
Dave.
| |