[RFC PATCH] drm/vgem: virtual GEM provider

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120111/629f04fd/attachment.pgp>