Hi Karim, On Sat, Mar 9, 2019 at 10:44 PM Karim Yaghmour <karim.yaghmour@xxxxxxxxxxx> 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 -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
