On Monday, September 29, 2008 6:10 pm Eric Anholt wrote: > On Tue, 2008-09-23 at 11:10 +0200, Nick Piggin wrote: > > If my cursory reading is correct, then my allocator won't work so well as > > a drop in replacement because one isn't allowed to know about the filp > > behind the pageable object. It would also indicate some serious crack > > smoking by anyone who thinks open(2), pread(2), mmap(2), etc is ugly in > > comparison... > > I think the explanation for this got covered in other parts of the > thread, but drm_gem.c comments at the top also cover it. > > > So please, nobody who worked on that code is allowed to use ugly as an > > argument. Technical arguments are fine, so let's try to cover them.
I don't think anyone would argue that using normal system calls would be ugly, but there are several limitations with that approach, including the fact that some of our operations become slightly more difficult to do, along with the other limitations mentioned in drm_gem.c and in other threads. At this point I think we should go ahead and include Eric's earlier patchset into drm-next, and continue to refine the internals along the lines of what you've posted here in the post-2.6.28 timeframe. The ioctl based interfaces (there aren't too many) are something we can support going forward, so we should be able to rip up/clean up the implementation over time as the VM becomes more friendly to these sort of operations. Any objections? Dave, you can add my Acked-by (or S-o-b if Eric includes my GTT mapping stuff) to Eric's patchset; hope you can do that soon so we can get a libdrm with the new APIs released soon. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
