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
Attachment:
pgpb2VmsqB8fb.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
