On Tuesday, August 19, 2008 9:46 am Keith Packard wrote:
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.
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
--
