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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1245586176.15367.62.camel@violet>
Date:	Sun, 21 Jun 2009 14:09:36 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Brian Swetland <swetland@...gle.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Greg Kroah-Hartman <greg@...ah.com>,
	linux-kernel@...r.kernel.org, hackbod@...roid.com
Subject: Re: [PATCH 1/6] staging: android: binder: Remove some funny &&
 usage

Hi Daniel,

> > > Also are there any userspace test cases
> > > that Google used to test the performance of this interface. Or test
> > > cases to compare the binder with something like sockets, or any other
> > > type of IPC?
> > >
> > > If Google believes the binder is the right solution for IPC, how was
> > > that conclusion formed?
> > >
> > > Daniel
> > 
> > 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.
> 
> Most of these questions related to the fact that I don't think an
> interface like this just slips into the kernel as a driver. Since it's
> IPC, it's totally generic, and it's not part of a standard (i.e. POSIX),
> we need to have some better and more specific information about it (or
> atleast I do). 

at this point of time we are using D-Bus quite successfully for mostly
every userspace application. And embedded devices like Nokia 810 or even
the new Palm Pre seems to be very happy with it. Even the Android
platform contains D-Bus support (even though limited for BlueZ).

The only downside with D-Bus right now is that you can't really copy
large amount of data over its IPC. And that is purely for performance
reason and memory constraints. However it is actually an implementation
detail since D-Bus as of now uses Unix sockets underneath. Switching to
shared memory or implementing dbus-daemon as AF_DBUS inside the kernel
would solve these.

For the problem of not being able to pass file descriptors over D-Bus we
have patches that are currently under review and are most likely to get
merged for the next release. This would also remove the limitation of
the direct data communication since you could just give the file
descriptor of the data plane to the other process.

> If for instance the main reason for Google using this interface is cause
> a large number of android people once worked at Palm or BeOS, that's not
> reason enough for it to go into the kernel. Or if this binder interface
> really fits well with Java or C++ people and they just love it, that's
> not really acceptable either..

It is a Google only thing. Everybody else uses D-Bus and is actually
happy with it.

Regards

Marcel

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