Varied and inconsistent implementation of kernel options
Description
Environment
Activity
Tom Rini November 27, 2017 at 1:15 PM
This has been resolved with https://gerrit.automotivelinux.org/gerrit/12063 being merged.
Jan-Simon Moeller October 13, 2017 at 8:07 AMEdited
IIRC the mechanisms for config-fragments have been moved from linux-yocto only to all kernel recipes. So from the fragment point of view, this can be resolved meanwhile by refactoring the fragments (or whatever homebrew mechanism was used).
Yes, the linux-%.bbappend should be redone asap.
We might resolve to a common inc file and linux-"foo"_%.bbappend instead.
Tom Rini October 11, 2017 at 3:39 PM
At the high level, what I would like to propose is making the use of recipes-kernel/linux/linux-agl.inc mandatory and ensuring that our config fragments are sufficient to ensure that a given, required, option is found and enabled. All BSPs that we use today support merge_config.sh in some form or another and that feels like a low enough hurdle for adding new BSPs that the benefits of using it (security will be correct, expected peripherals will be functional) outweigh any downside of adding an arbitrary BSP that does not already leverage this. It's already a de-facto requirement given the number of cfg fragments we use today.
Depending on the BSP we have different Linux Kernel versions and recipes used. This is expected and something we have designed around. However, we have multiple and inconsistent mechanisms being used to enforce various required kernel options (such as smack and various I/O devices). This in turn makes adding new BSPs as well as maintaining existing BSPs difficult (see recent regressions about touchscreen, issues found when fixing iMX support). A unified solution is required that does not impact other recipes (for example, linux-%.bbappend causes a rebuild of linux-libc-headers, and in turn, much of the 'world', when we tweak a cfg there).