linux-kernel - Re: [PATCH] staging: android: binder: move to the "real" part of the kernel

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: <20141017080101.GA20268@kroah.com>
Date:	Fri, 17 Oct 2014 10:01:01 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>, devel@...verdev.osuosl.org,
	Linux API <linux-api@...r.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Rebecca Schultz Zavin <rebecca@...roid.com>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Anup Patel <anup.patel@...aro.org>
Subject: Re: [PATCH] staging: android: binder: move to the "real" part of the
 kernel

On Thu, Oct 16, 2014 at 08:25:33PM -0700, John Stultz wrote:
> On Thu, Oct 16, 2014 at 4:12 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote:
> >> On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman
> >> <gregkh@...uxfoundation.org> wrote:
> >> > From: Greg Kroah-Hartman <gregkh@...uxfoundation.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. :)
> >
> > As no one noticed, it wasn't a "break" :)
> >
> >> > 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?
> >
> > Do we really need someone to do more work that has been done on it in
> > the past as an official "maintainer"?  I'll be glad to do it, as I doubt
> > it will require any time at all.
> 
> Ok. The only caution I have if Arve isn't involved is that we have in
> the past merged cleanup changes that introduced bugs, and it wasn't
> until Arve took at look at the new kernel that these were sorted out
> (see e194fd8a5d8e0a7eeed239a8534460724b62fe2d). So I think if at all
> possible getting his ack on things would be good.

I'll make sure to get his Ack on anything that could possibly cause a
problem.

> But yes, I'm fine with it going in. I'm just a bit surprised at how
> quickly thoughts change here.

Over the past year I've realized that code in staging needs to progress
either out of the kernel due to no need/use, or into the main part of
the kernel as people rely on it.  The android code is something that
people rely on, and this code is "stable", so it should be merged into
the main kernel tree.

So yes, this does seem to be a change in the public stance, but it's
something that I have been talking about with people at the zillion
conferences I go to around the world.

> This does raise the question if the same standard could be held to
> ashmem then?

Ah, you beat me to it, I was going to wait to talk to you in person
about this :)

> That's a *much* simpler and easier to maintain chunk of
> code, and is just as isolated, logic wise.  And while I think it would
> be ideal if the unpinning feature could be done more generically, if
> volatile ranges really doesn't have a future, then its maybe silly to
> hold ashmem out as well?

Yes, that was the second thing I was going to move, I'll send a patch
for that later today.

thanks,

greg k-h
--
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/