Hi Karim,
On Sat, Mar 9, 2019 at 10:44 PM Karim Yaghmour karim.yaghmour@opersys.com wrote:
On 3/9/19 2:26 PM, Geert Uytterhoeven wrote:
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.
OK, that makes sense, if kernel and modules are separate. So kernel size increase due to including the headers does matter.
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.
Personally, I had mixed experiences with CONFIG_MODVERSIONS. But that was a looong time ago, before Android. Things may have improved.
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.
OK.
Now about the actual solution: what is your opinion on embedding e.g. a squashfs image in the kernel instead, which would be a more generic solution, not adding more ABI to /proc?
Thanks!
Gr{oetje,eeting}s,
Geert