[Ce-android-mainline] binder re-implementation

Brian Swetland swetland at google.com
Thu Feb 9 18:53:49 UTC 2012


On Thu, Jan 26, 2012 at 3:44 PM, NeilBrown <neilb at suse.de> wrote:
> On Thu, 26 Jan 2012 10:41:13 -0800 Tim Bird <tim.bird at am.sony.com> wrote:
>> 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.

Agreed -- the reference counting and object lifetime management is
pretty essential to the service the binder is providing.

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

Also agreed.  There is no specific need for a char device + ioctl
interface and they do present some headaches.  I believe the userspace
binder layer sets binder fds to close on exec -- supporting it
post-fork is not expected there.

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

This was actually intentional (doing it as a bolt-on) for
maintainability purposes.  The expectation was that the binder would
be undesirable to mainline linux (perhaps that assumption is less
correct now) and that a less invasive implementation (confined to a
single char driver) would be easier to maintain going forward.

Your summary of the features of the binder (later in this thread)
looks pretty spot on to me.

cc'ing Arve (who wrote and maintains the driver) in hopes that he can
provide some useful commentary on that as well.

Brian


More information about the Ce-android-mainline mailing list