[Ce-android-mainline] binder re-implementation

[Arnd Bergmann]

On Thursday 26 January 2012, NeilBrown wrote:
> 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.

I was wondering about this, too. Other possible problems with weakly
defined semantics that I see are:

* Opening the binder multiple times from one process. I don't
think this is meaningful, but I don't know if it is harmless.

* Passing binder file descriptors through unix sockets while
passing the same unix socket through the binder in a different
thread. Is this race-free and deadlock-free?

> 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.

Agreed on both accounts.

Since we have the same question on a number of the android drivers,
my personal rule of thumb is:

- when dealing with an I/O device that can exist multiple times
in the system and needs fs level user permissions for controlling
access, use a chardev with ioctls, but

- when dealing with kernel functionality that is not related to hardware
and that is not restricted to a specific group of users, use system calls.

> 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:
>     https://lwn.net/Articles/466304/
> 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.

Sorry, I don't understand this part. Do you mean any struct file that
might be shared between two processes could be used to established a
binder socket, or what would be the way to identify it?

> 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.

I like this.
> 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.

What I've been thinking about before was to either extend the Posix mqueue
implementation or to add something similar to that, rather than a socket
family. Have you also considered this? As far as I can tell, both sockets
and mqueues could serve as the base for the binder kernel interface, but
I don't understand the binder requirements well enough to judge if there
are any fundamental differences that we can't work around in message queues.

	Arnd