Messages in this thread | | | Date | Thu, 25 Jun 2009 02:01:06 +0200 | Subject | Re: [PATCH 1/6] staging: android: binder: Remove some funny && usage | From | Linus Walleij <> |
| |
2009/6/25 Brian Swetland <swetland@google.com>: > 2009/6/24 Daniel Walker <dwalker@fifo99.com>: >> 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.
What is nice about binder is that is steps in an fills the gap for rapid buffer-passing IPC, is it really not possible to find common ground with a D-Bus in-kernel IPC driver now that you're anyway using both mechanisms and benefiting to both ends?
What I really want to know, is how this relates to the vmsplice() and other zero-copy buffer passing schemes already in the kernel. I was sort of dreaming that D-Bus and other IPC could be accelerated on top of that.
Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |