On Tue, 23 Sep 2008 12:21:26 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Nick Piggin wrote: > > Hi, > > > > So I promised I would look at this again, because I (and others) have some > > issues with exporting shmem_file_setup for DRM-GEM to go off and do things > > with. > > > > The rationale for using shmem seems to be that pageable "objects" are > > needed, > > and they can't be created by userspace because that would be ugly for some > > reason, and/or they are required before userland is running. > > > > I particularly don't like the idea of exposing these vfs objects to random > > drivers because they're likely to get things wrong or become out of synch > > or unreviewed if things change. I suggested a simple pageable object > > allocator > > that could live in mm and hide the exact details of how shmem / pagecache > > works. So I've coded that up quickly. > > > > Upon actually looking at how "GEM" makes use of its shmem_file_setup filp, I > > see something strange... it seems that userspace actually gets some kind of > > descriptor, a descriptor to an object backed by this shmem file (let's call > > it > > a "file descriptor"). Anyway, it turns out that userspace sometimes needs to > > pread, pwrite, and mmap these objects, but unfortunately it has no direct > > way > > to do that, due to not having open(2)ed the files directly. So what GEM does > > is to add some ioctls which take the "file descriptor" things, and derives > > the shmem file from them, and then calls into the vfs to perform the > > operation. > > > > 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... > > > > 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. > > > > > Nick, > From my point of view, this is exactly what's needed, although there > might be some different opinions among the > DRM developers. A question: > > Sometimes it's desirable to indicate that a page / object is "cleaned", > which would mean data has moved and is backed by device memory. In that > case one could either free the object or indicate to it that it can > release it's pages. Is freeing / recreating such an object an expensive > operation? Would it, in that case, be possible to add an object / page > "cleaned" function? > > /Thomas Also what about a uncached page allocator ? As some drivers might need them, there is no number but i think their was some concern that changing PAT too often might be costly and that we would better have a poll of such pages. Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
