[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200808191150.12345.jbarnes@virtuousgeek.org>
Date: Tue, 19 Aug 2008 11:50:11 -0700
From: Jesse Barnes <jbarnes@...tuousgeek.org>
To: Keith Packard <keithp@...thp.com>
Cc: Nick Piggin <nickpiggin@...oo.com.au>,
Dave Airlie <airlied@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM
On Tuesday, August 19, 2008 9:46 am Keith Packard wrote:
> On Tue, 2008-08-19 at 20:00 +1000, Nick Piggin wrote:
> > Not exactly sure what you mean by this. But I would like to see an effort
> > made to use existing userspace APIs in order to do this swappable object
> > allocation over tmpfs scheme. As I said, I don't object to a nice kernel
> > implementation, but we would be in a much better position to assess it if
> > we had an existing userspace implementation to compare it with.
>
> We need to allocate objects from kernel mode to get the console running.
> I'd prefer to let that occur before user mode was available. Also,
> emulating the existing fbdev syscall interface will require that we
> allocate objects within the kernel.
Yeah there's no question we need early kernel space allocations of GEM
objects. We need to setup the frame buffer, ring buffer, hardware status
page, and potentially other state at module init time so that people can see
their boot messages.
> Hence, the question about how we should create objects from kernel mode.
> I think we can do this with a series of VFS function calls. Would that
> series of VFS calls be preferable to directly accessing the existing
> shmem API?
>
> Another alternative is to improve the existing shmem API to better
> capture what we're trying to do here. Both drm and sysv shm just want
> anonymous pages that are backed by swap. If we started from scratch,
> what API would we like to have here? Would we have it support both shmem
> and hugetlbfs?
Improving the shmem API makes sense to me. There's a flip side to using the
ioctls as well; in doing the GTT mapping with the current code, I had to add
a new ioctl and create a new core function that would allow me to do I/O
remapping from something other than an ->mmap hook. I think we could have
conceptually cleaner code and less hassle if we extended shmem a bit to allow
for shmem "drivers" that could hook into its open/close/mmap/etc. routines
(though in the mmap case in particular we'd either need to abuse an existing
mmap flag or create a new one to recognize the backing store/GTT mapping
distinction).
What do you think, Nick? Adding this stuff to shmem would probably involve
using the file->private_data inside shmem, and creating a new sub-driver
registration function, then checking for sub-ops in the various important
shmem operations structs...
The advantage of all this is that we could probably use regular fds for the
most part (assuming we get a "high fd" mapping function sometime soon), and
all the regular file operations routines, making GEM look a like more like a
regular file system driver.
As for in-kernel stuff, as long as we keep the GEM shmem hooks separate from
the actual bookkeeping (like we do now with i915_gem_create_ioctl() vs
drm_gem_object_alloc() for example) we should be able to do the in-kernel
stuff w/o jumping through too many VFS/VM hoops. That would also assume we
don't care about swapping in the in-kernel case, which we don't; we want to
pin the kernel allocated frame buffer and other memory anyway, so using the
internal functions should be fine.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists