linux-kernel - Re: [GIT PULL] Staging driver patches for 3.19-rc1

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]

Date:	Mon, 15 Dec 2014 11:32:22 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Richard Weinberger <richard@....at>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: Re: [GIT PULL] Staging driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 08:04:53PM +0100, Richard Weinberger wrote:
> > Fact is, this is useful code, in this area.  In the domain it is used
> > in, it works properly, and the abi is sufficient.  Yes, it's ugly in
> > spaces, and insecure if used outside of Android, but that's ok for the
> > users of the code.
> 
> Let's discuss this while having a few beers.
> It is going to be philosophic.

I'm all for beers and philosopic talk, sounds good :)

> >> Is there a change that Android will pick it up?
> > 
> > Yes.
> 
> So then wait until this happens and ignore binder.

I have been, for years now.

But the issue is, drivers/staging/ should not just be a "dumping ground"
for code.  Code in there needs to either move forward in being cleaned
up and accepted, or it needs to be deleted.

This is the reason why I deleted the binder code from the tree a few
years ago.  Turns out, that's the first commit vendors revert when they
make an android product.  Then they add on a mis-match of patches on top
of it, bringing the code kind-of-up-to-date with the newer kernel, and
ship it.  That has caused problems by people not knowing what to apply
and fix in order to handle abi changes.

So the code went back into staging, and got fixed up, and now that's as
far as I can take it without either deleting it, or moving it out of
staging.  So I'm trying to move it out of staging.

Now I know this is a "special case" for stuff that might be "ugly".
Fact is, we are stuck with this user api due to ignoring this code for
many years on the community side, as well as Google not taking the time
and effort originally to push it upstream.  There is fault on both sides
here, I agree.

And because of that, I'm willing to maintain this on our side.  I have
confirmation that Google employees will also co-maintain it as well.
But the userspace api is something that we just have to live with, as
ugly as it is, until someone, who has the ability to commit to the
Android userspace side, does the work.

> > Since a few hundred million devices use it and we have userspace code
> > that relies on it and can't be changed?
> 
> It is news to me that these devices use a mainline kernel.

They always start with a mainline kernel, and then usually add bsp
support on top of it.  The non-bsp code in the Android tree these days
is very low.

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/