Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel

From: Karim Yaghmour <karim.yaghmour@opersys.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	atish patra <atishp04@gmail.com>,
	Daniel Colascione <dancol@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Guenter Roeck <groeck@chromium.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Kees Cook <keescook@chromium.org>,
	Android Kernel Team <kernel-team@android.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	linux-trace-devel@vger.kernel.org,
	Manoj Rao <linux@manojrajarao.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Qais Yousef <qais.yousef@arm.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Shuah Khan <shuah@kernel.org>, Yonghong Song <yhs@fb.com>
Subject: Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
Date: Sat, 9 Mar 2019 16:44:31 -0500	[thread overview]
Message-ID: <3e84e1ef-e266-e983-5874-6c26ac7f38b8@opersys.com> (raw)
In-Reply-To: <CAMuHMdV8+XTyGf1ZJ+gMf=zQpzqh3-+b7wgi+gAmXQ6HpUAw3A@mail.gmail.com>

Hi Geert,

On 3/9/19 2:26 PM, Geert Uytterhoeven wrote:
> Thanks for the explanation!

Happy this was useful :)

> So how does this work, with kernel images and kernel modules supplied
> by separate parties, not "bound" by the same kernel headers/API, as they
> can be replaced separately?

The thing with Android is that there isn't a "one size fits all". Google 
provides guidance, policies and at least one example implementation 
through the Pixel lines.

Each vendor however is allowed a great degree of latitude with regards 
to what they decide to do. Personally, if I was advising a team working 
on an Android device where Joel's patch was available as part of their 
kernel I would just recommend that they build it in -- i.e. not as a 
module. Hence, there would be no module chasing game.

With regards to Google's guidelines for manufacturers, though, Google 
states that CONFIG_MODVERSIONS needs to be enabled, see here:
https://source.android.com/devices/architecture/kernel/modular-kernels
FWIW, that doesn't mean that modules are actually used. Devices don't 
necessarily have to be using modules.

> Isn't the need for kernel headers for user-space tools something different,
> as this is limited to the uapi versions, which are less (almost not) subject
> to change, compared to the kernel headers needed for compiling kernel
> modules?

Sorry, I should've been clearer. I'm including eBPF/BCC into the 
"user-space tools" here. That was in fact my prime motivation in 
encouraging Joel at the last LPC to look at this. I've been integrating 
the teaching of eBPF into my AOSP debugging and performance analysis 
class (see CC courseware here: 
http://www.opersys.com/training/android-debug-and-performance), and it 
was pretty messy trying to show people how to benefit from such tools 
under Android. Joel's present set of patches would obviate this problem.

HTH,

-- 
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour