linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	devel@driverdev.osuosl.org,
	"Linux API" <linux-api@vger.kernel.org>,
	"Santosh Shilimkar" <santosh.shilimkar@ti.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Rebecca Schultz Zavin" <rebecca@android.com>,
	"Christoffer Dall" <christoffer.dall@linaro.org>,
	"Anup Patel" <anup.patel@linaro.org>
Subject: Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
Date: Thu, 16 Oct 2014 10:09:04 -0700	[thread overview]
Message-ID: <CALAqxLU05D8qQA47E77PiuuN7eVt66WEq1qn+PqdE-tpEUzFpw@mail.gmail.com> (raw)
In-Reply-To: <20141016124741.GA3832@kroah.com>

On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> The Android binder code has been "stable" for many years now.  No matter

Well, ignoring the ABI break that landed in the last year. :)

> what comes in the future, we are going to have to support this API, so
> might as well move it to the "real" part of the kernel as there's no
> real work that needs to be done to the existing code.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>
> This was discussed in the Android miniconf at the Plumbers conference.
> If anyone has any objections to this, please let me know, otherwise I'm
> queueing this up for 3.19-rc1

So my main concerns/thoughts here are:

Who is going to maintain this? Has Arve agreed?  Are the Android guys
comfortable with the ABI stability rules they'll now face?  Currently
in the android space no one but libbinder should use the kernel
interface. Can we enforce that no one use this interface out-side of
android (To ensure its one of those "if the abi breaks and no one
notices..." edge cases)?

I'm still hopeful that a libbinder over kdbus will eventually pan out.
I still see having two core IPC mechanisms (even if the use cases are
different in style) as a negative, and I worry this might reduce
motivation to unify things at the lower level. Granted, such work can
still continue, but the incentives do change.

thanks
-john

  parent reply	other threads:[~2014-10-16 17:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-16 12:47 [PATCH] staging: android: binder: move to the "real" part of the kernel Greg Kroah-Hartman
     [not found] ` <20141016124741.GA3832-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-10-16 14:18   ` Michael Kerrisk (man-pages)
2014-10-16 23:14     ` Greg Kroah-Hartman
2014-10-20 12:45       ` Dan Carpenter
2014-10-21 10:01       ` Pavel Machek
2014-10-20 17:06   ` Arnd Bergmann
2014-10-16 17:09 ` John Stultz [this message]
     [not found]   ` <CALAqxLU05D8qQA47E77PiuuN7eVt66WEq1qn+PqdE-tpEUzFpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-16 23:12     ` Greg Kroah-Hartman
     [not found]       ` <20141016231221.GA13592-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-10-17  3:25         ` John Stultz
2014-10-17  8:01           ` Greg Kroah-Hartman
2014-10-21 10:36         ` Pavel Machek
2014-10-21 14:12           ` Arnd Bergmann
2014-10-21 20:05             ` Pavel Machek
2014-10-18 21:36       ` One Thousand Gnomes
2014-10-19 22:01         ` Greg Kroah-Hartman
2014-10-17  9:26 ` Dan Carpenter
2014-10-19 22:05   ` Greg Kroah-Hartman
2014-10-20  9:20     ` Dan Carpenter
2014-10-20 23:32       ` Arve Hjønnevåg
     [not found]         ` <CAMP5Xgcm-sxd3rf3VA1ZO44bUT1+u_QG1AAdjzK39q0ynfsZGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-22  3:10           ` Rom Lemarchand
2014-10-22  3:16             ` Joe Perches
2014-10-24  5:00             ` Dan Carpenter
2014-10-17  9:43 ` Christoph Hellwig
2014-10-19 22:04   ` Greg Kroah-Hartman
     [not found]     ` <20141019220450.GB3780-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-10-21 10:46       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALAqxLU05D8qQA47E77PiuuN7eVt66WEq1qn+PqdE-tpEUzFpw@mail.gmail.com \
    --to=john.stultz@linaro.org \
    --cc=anup.patel@linaro.org \
    --cc=arve@android.com \
    --cc=christoffer.dall@linaro.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rebecca@android.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).