On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij <linus.ml.walleij@xxxxxxxxx> wrote: > > So I would really like to know from the Android people why the > binder is in the kernel, after all. Could it *theoretically* be in > userspace, on top of some unix domain sockets, running as a > real-time scheduled daemon or whatever, still yielding the same > performance? Or is there some discovered limitation with current > interfaces, that everybody ought to know? Especially authors of > D-Bus and TAO etc would be very interested in this I believe. > > It's not like I don't understand that it would be hard to move this > thing to userspace, it's more that I'd like to know how you think it > would be impacted by that. Fundamentally, yes, you should be able to replicate the functionality in userspace. We considered this during 1.0 development, but it ended up being a lot of risk (at the point when it was discussed) compared to using the existing driver that we had. You almost certainly would need a central daemon to do some state and permission management as well as track some of the refcounting, you could use EPIPE on local sockets to detect remote process termination. You could even just use local sockets for high level control and use shared memory for actual message transport to avoid copy-in-copy-out overhead (another binder driver feature). That said, the userspace environment was built up around the binder, relies on it heavily for all ipc (except for dbus which we use for bluez because it just hasn't been worth the headache to maintain alternate ipc patches for bluez), and is performance sensitive (it's possible that you could achieve similar performance with a suitably clever userspace implementation making use of shared memory, of course), and the frameworks/apps folks are happy with it as is (so talking them into replacing it may be a nontrivial exercise). I wouldn't mind not having to maintain the kernel driver (well, not having Arve have to maintain the kernel driver...) but building a pure-userspace replacement would be a pretty huge undertaking, especially given all the other work we have just with general kernel development, bringup, etc. Since all binder comms in userspace bottlenecks through two small libraries (one C++, one lighter weight C), in theory you could build a drop-in replacement and then prove it out, verify correctness and performance, and make the argument for replacing the existing implementation. Debugging binder implementation issues under a full system using many binder services and patterns like "client A calls service B which returns and object in service C", is a bit of a nightmare. I try to stay far away from it, myself. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
