On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
I remember at one point you had a plan along the lines of passing shmem fds across the protocol. I'm curious what happened to that -- too hard to get the passing to work, or something else? I'm just thinking of kernel developer grumbling that you've duplicated something that pretty much existed before.
There's no way to pass an fd without passing an extra byte of in-stream data, and it's weirdly invasive to try to thread that into the existing protocol. Sort of the same way getting socket peer credentials with recvmsg(SCM_CREDENTIALS) sucks, which is why we have getsockopt(SO_PEERCRED) instead. But unlike process credentials, SCM_RIGHTS is a queue, which is a funny kind of API to bolt into setsockopt.
Making something that looked like a hardware driver seemed way more symmetric. And, in the long-range future of being able to pass GEM objects among DRM devices, you'll probably want to apply any constraints like tiling round-up at object creation time. Doing it the other way around - xserver allocates with shm_open() then promotes to GEM - just introduces a way userspace can get it wrong.
If you can, I recommend using the intel gtt mapping type of mmap ioctl, where it gives you back an offset that you use the mmap syscall on, and implement the vgem_gem_fault to map its pages, instead. It should avoid tricking userland tools like valgrind, which really sucks with the do_mmap()-calling ioctl we have today.
That makes sense. Having two paths by which you could hit drm_gem_mmap() seemed weird when I was writing it.
I think the clean way of doing that requires exporting at least shmem_fault and possibly some other shmfs details.
- ajax
I'm working on this presently unless you've already done it. ~Ben