Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751996Ab0FGXhP (ORCPT ); Mon, 7 Jun 2010 19:37:15 -0400 Received: from smtp-out.google.com ([216.239.44.51]:9729 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834Ab0FGXhN (ORCPT ); Mon, 7 Jun 2010 19:37:13 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=sLkdlFdM/5QlJqKgA/a0+NV5uI1HLnqROWFfQFeFaPp1I30kAx1rlbrbfm3BiSiLQ /YXTkHSF0KVRsEbS6o/1w== MIME-Version: 1.0 In-Reply-To: References: <1275834706.7227.545.camel@mulgrave.site> <1275844114.7227.552.camel@mulgrave.site> <20100606190525.GA20517@infradead.org> <20100606192405.GA7559@infradead.org> <1275916830.1645.566.camel@laptop> Date: Mon, 7 Jun 2010 16:37:07 -0700 Message-ID: Subject: Re: [linux-pm] suspend blockers & Android integration From: Brian Swetland To: Linus Walleij Cc: Peter Zijlstra , Christoph Hellwig , James Bottomley , Thomas Gleixner , Alan Cox , Florian Mickler , Vitaly Wool , "Arve Hj?nnev?g" , Arjan van de Ven , tytso@mit.edu, "H. Peter Anvin" , LKML , Neil Brown , Linux PM , Ingo Molnar , Linux OMAP Mailing List , Linus Torvalds , Felipe Balbi , hackbod@android.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2956 Lines: 58 On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij 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-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/