I've been lurking on this thread all day since I've been underwater on something else but I want to give some perspective on both things that we've done on Android in the past and where we are going in the future that's relevant to the fd's vs. "cookies" discussion here. I've owned the "memory manager" component on pretty much every android program the android team has been involved with directly, qualcomm's pmem was written by me, nvidia's nvmap was heavily modified, many of ti's things flowed through my fingers etc. As many of you know, we're also working on our own new solution -- yes I know we don't need one more from google, but really you already have several from google, we're trying to replace them with one that solves all the problems the others do.
As Arnd has pointed out, filedescriptors give us for free a lot of things we desperately need, especially lifetime management. This is probably the single biggest source of bugs around multimedia and graphics. Moving forward we are going to make it a requirement that buffers must exist in file descriptors while they are in userspace, so they automatically get reference counted correctly when they are passed between processes. Any solution that doesn't do that will not be compatible with Anrdoid's next generation gralloc api.
That being said, I think all the detractors of file descriptors can be easily worked around. My proposal is to only "promote" buffers into file descriptors while they are being passed or mmaped. This way, we can easily manage the number of fds required in the system. If you want to see how that might work, take a look at my first stab at an implementation for a new memory manager here:
I was waiting to post that until I had time to put together some cogent documentation for it, but it sounds like it's time has come. Comments are welcome there or by email. Keep in mind it's intended to implement the basic api without the machinery to manage the related hardware and it's still a work in progress.
Rebecca
On Wed, Apr 20, 2011 at 1:48 PM, Dave Airlie
<airlied@gmail.com> wrote:
> * Efficient lookup in system calls
> * Established ways to pass them around
> * Easy to mmap() -- if you want to map anything into user space, you
> need a file descriptor anyway
This isn't a great boon as we've seen with GEM and TTM.
The problem for GEM was we used shmem to back the fds, so the mmap
was a cached mapping, now when we had alternate mapping available
such as via the GTT we had to go and add code to mmap via that drm file
descriptor. Though probably could have gotten around that by changing the
mmap backing away from shmem.
Dave.