> Feel free to send a patch to dri-devel or just let me know the ioctls > and I will include it in this series.
Do you have a branch somewhere I can grab? That's a bit easier than applying the patchset from the list. Thanks, Christian. Am 23.08.2013 14:31, schrieb David Herrmann: > Hi > > On Fri, Aug 23, 2013 at 1:28 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Hi David, >> >> Am 23.08.2013 13:13, schrieb David Herrmann: >> >>> Hi >>> >>> I reduced the vma access-management patches to a minimum. I now do filp* >>> tracking in gem unconditionally and force drm_gem_mmap() to check this. >>> Hence, >>> all gem drivers are safe now. For TTM drivers, I now use the already >>> available >>> verify_access() callback to get access to the underlying gem-object. >>> Pretty >>> simple.. Why hadn't I thought of that before? >>> >>> Long story short: All drivers using GEM are safe now. This leaves vmwgfx.. >>> But >>> they do their own access-management, anyway. >>> >>> The 3 patches on top implement render-nodes. I added a "drm_rnodes" module >>> parameter to core drm. You need to pass "drm.rnodes=1" on the kernel >>> command-line or via sysfs _before_ loading a driver. Otherwise, render >>> nodes >>> will not be created. >>> >>> This allows us to test render-nodes and play with the API. I added FLINK >>> for >>> now so we can better test it. Not sure whether we should allow it in the >>> end, >>> though. >>> >>> Maybe we can get this into 3.11? >> >> A bit unlikely, but 3.12 should work fine. > whoops, 3.12 of course. > >> I'm working on a project that can make good use of this, so if Alex doesn't >> mind like to add the necessary radeon flags (should be only a few one liners >> anyway). > Feel free to send a patch to dri-devel or just let me know the ioctls > and I will include it in this series. > > Regards > David >
