[Ce-android-mainline] binder re-implementation
neilb at suse.de
Thu Jan 26 23:44:41 UTC 2012
On Thu, 26 Jan 2012 10:41:13 -0800 Tim Bird <tim.bird at am.sony.com> wrote:
> On 01/26/2012 04:37 AM, Arnd Bergmann wrote:
> > On Wednesday 25 January 2012, Tim Bird wrote:
> >> I don't know if anything will come of it, but someone has gone to the
> >> trouble of starting a project to re-implement the binder driver,
> >> apparently in an effort to improve SMP performance.
> >> See
> >> http://groups.google.com/group/android-kernel/browse_frm/thread/c57874670e4decb1
> >> It's too early to tell if this project will yield usable results,
> >> but I thought it was worth preserving a reference to, for anyone
> >> who ends up working on binder.
> > I've looked briefly at it, and it doesn't seem to change the
> > kernel to user space interface at all, which would be the most
> > important thing to get right before worrying about implementation
> > details. I have no way to tell if the work on the binder
> > re-implementation is a good thing or not, but it seems to be
> > orthogonal to the cleanup on the kernel interface that we need
> > to get binder graduated from staging to a proper subsystem.
> Since I don't have time to work on binder myself, I haven't
> pressed for details about what people would like to see changed
> in the kernel interfaces. However, maybe a thumbnail sketch
> would be good.
> Could you give us a quick rundown of the problems you see
> with the existing interfaces? I'm not really trying to start
> a technical discussion here (as I don't have enough experience
> with binder to make any judgements or evaluate the critique).
> The lack of response might give the impression that the issues
> are being dropped in the bit bucket. But I plan to at least
> record on the wiki the issues that may need addressing.
Where to begin....
I had a quick look at that alternate implementation and the email said
something about getting rid of the reference counts. That sounded very
dubious to me. I'm fairly sure they have an important role that it not
immediately obvious at first reading.. So I wouldn't be spending much time
looking further at that alternative.
One of the big problems with the current binder interface is that it creates
a strong tie between a file-descriptor and a process, without actually
enforcing that tie. So if you open the binder device and then fork, it will
almost certainly stop behaving correctly.
Another big problem - for me at least - is the use of a char device and
ioctls. This is "wrong" from a philosophical perspective, and we could of
course argue philosophy all day without getting anywhere so maybe that isn't
a useful observation.
Maybe a better way to look at it is that this approach effectively bolts
binder on the side of linux rather than integrating it properly. Thus you
lose the benefits of a uniform integrated whole.
When I was researching binder for my lwn article:
I spent a while trying to come up with a "good" interface for the same
functionality but was never really satisfied with anything I came up with.
However I'm tempted to try again .... maybe.
Anyway, my thumbnail sketch would be something like this:
1/ A new 'address family' to be used with sockets. Addresses in this family
are comprised of 1 or 2 'cookies' which are either file descriptors or
an internal 'object descriptor'.
Thus if you open a file and bind(2) to that descriptor, anyone else who
can open the same file can send you a message.
Also you can send a message containing an 'object reference' and it arrives
at the other end as an 'object descriptor' which can be used in addresses.
This roughly matches the addressing used in binder.
The optional second 'cookie' is just an object reference but it identifies
a 'transaction' which supports the transaction handling that is implicit in
the current binder.
2/ New 'control messages' that can be sent with sendmsg and received with
recvmsg which pass 'object' references
3/ A normal code path where a writer blocks until a reader is also ready,
and then the message is copied from the writers iovec into the readers
iovec without ever living in a kernel buffer.
4/ An extension to aio so that sendmsg/recvmsg messages can be sent async
too. Then this would be used for async communication.
There are lots more details which I don't recall very clearly at the moment
but I'm sure they can be worked out.
One of the biggest differences (apart from the obvious sockets-vs-chardevice
difference) is that I wouldn't have any reference counting on object
references (I know I said above that they are important .. but bear with me).
With binder, if you get sent a reference to an object that you already hold a
reference to, then you get given the same reference. i.e. the same number.
So the kernel keeps a count of the number of times it has given you a
This is important as one thread could be freeing references while another
thread is adding them and there are possible races there which a refcount can
Note that this is different from sending file descriptors, both with binder
and with Unix domain sockets. If you are sent a file descriptor when you
already own a descriptor on that file, you still get a new file descriptor.
So in my thumb-nail-sketch, every object reference comes through as a new
references. The objects keep a count of the active references, but the
references themselves don't have counters.
So if you hold 12 references to the one object, they will be twelve distinct
numbers that you hold.
One problem with this is that I believe Android uses presentation of a
reference and proof of permission for some things. i.e. an object is used as
a credential (a 'capability'??).
So code needs to be able to ask 'are these two references for the same
object?'. In android this simply a numeric comparison.
In my scheme you would need to ask the kernel to compare two 'addresses'.
Some sort of 'setsockopt' might do it.
I appreciate that some of the things that I am suggesting we do to sockets
are quite a deviation from the norm and you might argue that I am mis-using
sockets just as much as the current binder is mis-using char devices. You
might even be right: I am not objective enough to comment.
If there is interest in this (and maybe even if there isn't) I'll try to find
time to make it all more concrete and detailed so we can ask some independent
by-stander to comment.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: not available
More information about the Ce-android-mainline