lkml.org 
[lkml]   [2019]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Provide in-kernel headers for making it easy to extend the kernel
From
Date
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

\
 
 \ /
  Last update: 2019-03-07 18:39    [W:0.071 / U:34.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site