Keith Packard wrote: > >> and that's why TTM >> needs to manage a fake linear address space for the drm fd. >> > > Managing a fake linear address space just to match some existing > arbitrary API requirements is insane. Creating the right interface for > my UMA environment is my goal. I'm not sure precisely what that API > should be, but at least this one is obviously wrong. > I'm not sure I agree.
What we're discussing is really per buffer object address space or per device address space. With the current GEM implementation, the address space is per buffer object, and if this were done correctly you'd duplicate the shmemfs filesystem to make a drmfs filesystem where you have complete control over creation and mmap-ing and do not need to create special cases to work around the shmemfs implementation. It's not impossible that you can overload the shmemfs mmap / fault methods of the shmemfs filesystem, but what you're suggesting isn't really what I'd refer to as the cleanest and most natural interface. Since you were asking for comments, I'd strongly recommend avoiding trying to manipulate ptes from the driver. The other approach is to use one address space per device. An address space is obviously needed to be able to do unmap_mapping_range, read, write, seek etc. It's not an arbitrary API requirement. It's the linux file operations API requirement. Since the address space is per device it needs to be managed. I see nothing wrong with that, except you don't get a filesystem entry per buffer, and you need to be aware what the limitations are: that the address space may become fragmented and resizing becomes complicated. Given this, it's possible to make a choice what fits the driver best. A lightweight driver that needs to manipulate ptes to account for caching and placement would probably use the latter method, which is what TTM currently does. You've chosen the first and is faced with either 1) Hack ptes from the driver. 2) Try to overload the shmemfs mmap / fault methods. 3) Implement a new drmfs filesystem. /Thomas ------------------------------------------------------------------------- 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
