On Wednesday 20 April 2011, Rebecca Schultz Zavin wrote:
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.
I think people have stopped being bothered by code in the Android kernel that doesn't go upstream and have accepted the fact that each release is just a fork of Linux that gets thrown away with the next release.
IMO it's a very welcome change that you are now sharing your experience and work together with us. If we get it right this time, we might end up with an allocator that works for both Linux and Android.
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:
https://review.source.android.com/#change,22239
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.
The user interface looks nice and simple. Please go ahead and post the patch for review, even without the documentation.
My main concern with the code is that it tries to do something very generic, but is still linked very closely to a single device driver, which makes it unnecessarily hard to do a second driver using the same code.
Integrating the buffer management into DRM, next to GEM, would probably be one way to handle that more nicely if you find that GEM cannot do what you need. If DRM is found to be completely useless for embedded graphics, I think it would still be better to have a new framework for these and plug the ION driver into that, rather than having the buffer management code inside of that one driver.
Arnd