Message-ID: <548F30D5.9020109@nod.at>
Date:	Mon, 15 Dec 2014 20:04:53 +0100
From:	Richard Weinberger <richard@....at>
To:	Greg KH <gregkh@...uxfoundation.org>
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

Am 15.12.2014 um 19:44 schrieb Greg KH:
> On Mon, Dec 15, 2014 at 07:36:00PM +0100, Richard Weinberger wrote:
>>
>> Am 15.12.2014 um 19:30 schrieb Greg KH:
>>> On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
>>>> On Mon, Dec 15, 2014 at 6:55 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
>>>>> The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:
>>>>>
>>>>>   Linux 3.18-rc7 (2014-11-30 16:42:27 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.19-rc1
>>>>>
>>>>> for you to fetch changes up to 17d2c6439be65777245914be354c5a97c76ad246:
>>>>>
>>>>>   Staging: slicoss: Fix long line issues in slicoss.c (2014-12-02 16:54:43 -0800)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Staging patches for 3.19-rc1
>>>>>
>>>>> Here's the big staging tree pull request for 3.19-rc1.
>>>>>
>>>>> We continued to delete more lines than were added, always a good thing,
>>>>> but not at a huge rate this release, only about 70k lines removed
>>>>> overall mostly from removing the horrid bcm driver.
>>>>>
>>>>> Lots of normal staging driver cleanups and fixes all over the place,
>>>>> well over a thousand of them, the shortlog shows all the horrid details.
>>>>>
>>>>> The "contentious" thing here is the movement of the Android binder code
>>>>> out of staging into the "real" part of the kernel.  This is code that
>>>>> has been stable for a few years now and is working as-is in the tens of
>>>>> millions of devices with no issues.  Yes, the code is horrid, and the
>>>>> userspace api leaves a lot to be desired, but it's not going to change
>>>>> due to legacy issues that we have no control over.  Because so many
>>>>> devices and companies rely on this, and the code is stable, might as
>>>>> well promote it out of staging.
>>>>>
>>>>> This was all discussed at the Linux Plumbers conference, and everyone
>>>>> participating agreed that this was the best way forward.
>>>>>
>>>>> There is work happening to replace the binder code with something new
>>>>> that is happening right now, but I don't expect to see the results of
>>>>> that work for another year at the earliest.  If that ever happens, and
>>>>> Android switches over to it, I'll gladly remove this version
>>>>
>>>> I don't understand this kind of logic.
>>>> a) Binder is considered a piece of shite.
>>>
>>> A piece of "shite" that works for the domain it is in, and people rely
>>> on it.
>>
>> Using this argument we could merge every singe vendor tree too.
>> The crap they carry works for their domain too... ;-)
> 
> That's a false-argument, you know that.  This code falls into the
> "distros have been using it and it is proven to work" requirement that
> we have often made for new features.
> 
> 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.

>>>> b) Google is working on a (hopefully sane) replacement.
>>>
>>> I never said that Google was the one working on a replacement.
>>
>> Okay. Who is working on it?
> 
> Some other company, it's not my place to pre-announce projects, sorry.

Yeah, this is sad. :-\

>> Is there a change that Android will pick it up?
> 
> Yes.

So then wait until this happens and ignore binder.

>>>> Why moving it out of staging then? What is the benefit?
>>>> Keep it there for more 2-3 years and then remove it.
>>>
>>> Because code in staging either has to progress forward to be merged out
>>> of staging, or it gets deleted.  Just leaving it in staging for 2-4 more
>>> years doesn't mean anything different from moving it to
>>> drivers/android/, if I'm still maintaining it, right?  What it does say
>>> is that people rely on this thing, probably you do as well, so let's
>>> mark it as such.
>>>
>>>> If you move it now out of staging into the core kernel it will be considered ABI
>>>> and getting rid of it can be hard...
>>>
>>> It's already considered an "ABI" and removing it is hard, nothing has
>>> changed there.
>>
>> Since when is stuff in staging considered ABI?
> 
> 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.

I'm well a aware of the fact that there are a lot of android devices out there.
But why moving binder into the core kernel?
What is the benefit?
Does Google even care?

Thanks,
//richard
--
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/

Powered by blists - more mailing lists