Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Monday 04 August 2008 11:54, Keith Packard wrote:
> On Fri, 2008-08-01 at 16:50 -0400, Christoph Hellwig wrote:
> > Nope.  Let the userspace protion create a file in shmfs instead of
> > adding fugly kernel interfaces hdiing this fact.
>
> shmem_file_setup is already public, just not exposed to kernel modules.

This is not an argument. shmem_file_setup is public because that's
how ipc is implemented, not because it makes sense to be used
anywhere else. Lots of other things in mm/ are public that should
never be used outside that directory for example.


> 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.


> The other interface we use, shmem_getpage, doesn't seem supported
> through existing interfaces though. I don't want to map the file into
> any address space, I just need a pointer to the physical pages which
> underlie it. I'll take those pages and hand them to the graphics engine.
> shmem_getpage performs precisely the operation needed here.

Mapping the file into an address space might be a way to make it
work (using get_user_pages to get the struct page). splice might
also work. read_mapping_page or similar could also be something to
look at. But using shmem_getpage seems wrong because it circumvents
the vfs API.

If you genuinely have problems that can't be fit into existing
APIs without significant modification, and that is specific just to
your app, then we could always look at making special cases for you.
But it would be nice if we generically solve problems you have with
processes manipulating thousands of files.