Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the
 kernel
To:     Joel Fernandes <joel@joelfernandes.org>
Cc:     Pavel Machek <pavel@ucw.cz>, hpa@zytor.com,
        Daniel Colascione <dancol@google.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>, ast@kernel.org,
        atishp04@gmail.com, Borislav Petkov <bp@alien8.de>,
        Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
        Jonathan Corbet <corbet@lwn.net>, karim.yaghmour@opersys.com,
        Kees Cook <keescook@chromium.org>, kernel-team@android.com,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Manoj Rao <linux@manojrajarao.com>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Randy Dunlap <rdunlap@infradead.org>, rostedt@goodmis.org,
        Thomas Gleixner <tglx@linutronix.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        yhs@fb.com
References: <20190118225543.86996-1-joel@joelfernandes.org>
 <20190119082532.GA9004@kroah.com> <20190119162754.GC231277@google.com>
 <CAKOZuet+7a4jdox6rebMN=kJtDn5RUYzvNjFh+Pzn2UkuP0Y8Q@mail.gmail.com>
 <20190119232503.GA149403@google.com>
 <78AACAF1-8EBF-4DF3-BE94-5B14E78BA791@zytor.com>
 <20190120155838.GA23827@google.com> <20190306230944.GB7915@amd>
 <742b4797-9954-fb54-cce8-47fcad750c69@metux.net>
 <20190307014802.GA193359@google.com>
From:   "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Organization: metux IT consult
Message-ID: <226424d3-d29f-2a83-2d04-81ad4aab1be2@metux.net>
Date:   Thu, 7 Mar 2019 18:37:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190307014802.GA193359@google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 07.03.19 02:48, Joel Fernandes wrote:
>> I'm confused.
> 
> Take a look at this thread: https://lkml.org/lkml/2019/2/28/634

Okay, replying to that mail:

> > > There's no linux-headers

That's the first fundamental problem. Actually, there's not even any
decent package management at all (no, apk seriously doesn't count as
that, not if you're used to apt+frieds for over 20 years)

> I have already been down that road. In the Android ecosystem, the
> Android teams only provide a "userspace system image" which goes on
> the system partition of the flash (and a couple other images are also
> provided but system is the main one).

These Android teams should learn how GNU/Linux distros and package
management works for over 20 years. Really, this is pretty trivial.

For such kind of general purpose devices, where users can install
arbitrary applications, I'd never come to the strange idea of deploying
whole operating system and applications in one image. (most likely not
even initially in the factory)

> The system image cannot contain GPL source code.

Why exactly ? Beacuse Big Manitu said so ?

Don't these folks that GPL doesn't prohibit shipping binaries on
disk/flash images ?

> It is also not possible to put kernel headers for every kernel version
> on the system images that ship and is not practical.

Of course not. They should only be deployed when needed, for the
versions needed.

> Android boots on 1000s of forked kernels.

Next big fundamental problem. Why all these forks in the first place ?

I'm not talking about the small patch queue ontop of mainline (or maybe
Andoid kernel baseline) - that's something we do all the day in embedded
world (of course we try to mainline as much as we can).

But what I usually see from the Andoid vendors are pretty much full
forks (full of horrible hacks) that quickly aren't maintained anymore.

If I'd be the responsible manager @google, that'd be one of the very
first things I'd care for: mainline first. (and, of course, ban all
proprietary binary-only kernel modules).

> Now for kernel modules, there's another image called the "vendor
> image" which is flashed onto the vendor parition, this is where kernel
> modules go.

Okay, then why not just putting a tarball there ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287