Re: [PATCH 1/6] staging: android: binder: Remove some funny && usage

[Brian Swetland]

2009/6/24 Daniel Walker <dwalker@xxxxxxxxxx>:
> On Fri, 2009-06-19 at 17:13 -0700, Arve HjÃnnevÃg wrote:
>>
>> These are mostly questions for the framework team. The binder driver
>> is there to support our user space code. At some point we used the
>> driver from www.open-binder.org, but we ran into, and fixed, a lot of
>> bugs (especially when processes died), so we determined it would be
>> faster to rewrite the driver from scratch.
>
> Is there someone in your framework team that would be willing to respond
> to these questions ? (I know you added hackbod to the CC, but they
> aren't responding..)

I guess it depends on the questions -- for good or ill, it's what is
in use and replacing it with a different mechanism would be a pretty
huge effort that there's unlikely to be time for in the near future.
Quite a bit of the userspace framework depends on the binder handling
the remote reference counting, object lifespan, etc, stuff and it's
subtle and hairy to debug.  Moving to a different transport is
possible (it's just software, as they say), but there's a lot of code
that depends on the behavior that exists today.

If the binder is absolutely unacceptable as something to be included
in the linux kernel (that's a message that I seem to be getting here),
I think the best thing for us to do is maintain it in our tree for now
and focus on stuff that is far less controversial.

For example the msm7k SoC code may need some various cleanup, but I
think at the end of the day adding support for a new ARM based SoC and
peripherals is not going to be that contentious.  The
wakelock/suspendblock stuff is a bit further out there, but there
seemed to be some good progress on getting it reviewed and revised on
the linux-pm list, last I saw.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/