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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
