On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m <tho...@shipmail.org> wrote:
> >> Sounds right to me. The offsets are just handles, not real file objects > >> or > >> backing store addresses. We use them to take advantage of all the inode > >> address mapping helpers, since they track stuff for us. > >> > >> That said, unmap_mapping_range may not be the best way to do this; > >> basically > >> we need a way to invalidate a given processes' mapping of a GTT range > >> (which > >> in turn is backed by real RAM). If there's some other way we should be > >> doing > >> this I'm all ears. > >> > > > > Well, we'd need to call in the big guns on this one - I've already > > stirred Hugh ;) > > > > unmap_mapping_range() is basically a truncate thing - it shoots down > > all mappings of a range of a *file*. Across all processes in the > > machine which map that file. > > > > If that isn't what you want to do (and it sounds that way) then you'd > > want to use something which is mm_struct (or vma) centric, rather than > > file-centric. zap_page_range(), methinks. > > > > > I guess I was the one starting to use this function, so some explanation: > > When the drm device is used to provide address space for buffers, > user-space actually see it as a file with a distinct offset where > buffers are laid out in a linear fashion, To access a certain buffer you > need to lseek() to the correct offset and then read() write() or, the > more common use, mmap / munmap. > > When looking through its implementation, unmap_mapping_range() seemed to > do exactly the thing I wanted, namely to kill all user-space mappings of > all vmas of all processes mapping a part of the device address space. That's different from what Jesse said. That _is_ a more appropriate use of unmap_mapping_range(). Although all the futzing that function does with truncate_count is now looking inappropriately-placed. > And it saves us from storing a list of all vmas mapping the device > within the drm device. > > What makes usage of unmap_mapping_range() on a device node with a well > defined offset-to-data mapping different from using it on a file? umm, nothing I guess, if the driver sufficiently imitates a regular file. It's unexpected (by me). I don't think we wrote that code with this application in mind ;) ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
