[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ada6062-d9f1-867e-828b-2796fb8d0a66@zytor.com>
Date: Wed, 6 Mar 2019 15:35:05 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Pavel Machek <pavel@....cz>,
Joel Fernandes <joel@...lfernandes.org>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, ast@...nel.org,
atishp04@...il.com, Borislav Petkov <bp@...en8.de>,
dancol@...gle.com, gregkh@...uxfoundation.org,
Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.cz>,
Jonathan Corbet <corbet@....net>, karim.yaghmour@...rsys.com,
Kees Cook <keescook@...omium.org>, kernel-team@...roid.com,
linux-doc@...r.kernel.org, Manoj Rao <linux@...ojrajarao.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
paulmck@...ux.vnet.ibm.com,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
rdunlap@...radead.org, rostedt@...dmis.org,
Thomas Gleixner <tglx@...utronix.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
yhs@...com
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the
kernel
On 3/6/19 3:09 PM, Pavel Machek wrote:
> On Fri 2019-01-18 17:55:43, Joel Fernandes wrote:
>> From: "Joel Fernandes (Google)" <joel@...lfernandes.org>
>>
>> Introduce in-kernel headers and other artifacts which are made available
>> as an archive through proc (/proc/kheaders.tgz file). This archive makes
>> it possible to build kernel modules, run eBPF programs, and other
>> tracing programs that need to extend the kernel for tracing purposes
>> without any dependency on the file system having headers and build
>> artifacts.
>>
>> On Android and embedded systems, it is common to switch kernels but not
>> have kernel headers available on the file system. Raw kernel headers
>> also cannot be copied into the filesystem like they can be on other
>> distros, due to licensing and other issues. There's no linux-headers
>
> If your licensing prevents you from having headers on the
> filesystem... then I guess you should fix the licensing.
>
> I agree with Christoph, this looks pretty horrible.
> Pavel
>
The argument that "it can be a module" is basically an admission of
failure - if it isn't part of the kernel image itself there is no
benefit over where the modules are stored, which will be *somewhere* in
the filesystem.
What I *do* think makes sense is to create an archive with this
information and stuff it in the same place as the modules. It reduces
the amount it is possible to muck it up.
-hpa
Powered by blists - more mailing lists