OpenWrt Kernel Configuration

Contribution to the Linux Kernel, and patch management

Contribute defconfigs and all the devicetrees on OpenWrt to Linux.
- Create a Linux branch for that and maintain it.
- Submit pull requests to the Linux mailing list regularly to get them applied.
Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does.
Target specific patches for Linux should be about backporting DTs.
- Bugfix backporting should happen only after it's accepted by the maintainer of the relevant Linux subsystem. The patch must be identical to the commit on the Linux maintainer's tree.
- Feature backporting should be done only if it's thoroughly tested.
- An issue caused by feature backporting.

A defconfig for every target.
- The most basic options like SoC support, and network drivers should be built into the kernel.
- On Linux source code, do make target_defconfig, then compile normally with OpenWrt's kernel module packages. This way, there won't be a difference compared to the old way with the generic config.
- Don't backport defconfigs but use the one that's already on the kernel version being used. There's a possibility that the defconfig from a newer kernel may have changed symbols which may cause some drivers to be missed when using it for older kernel versions. This means it will take at least a year to start using the defconfigs.

Replace defconfigs with the generic kernel config. Only keep target configs on OpenWrt. The target configs will do changes specific to OpenWrt.
- Booting the image, CONFIG_CMDLINE, etc.
- Filesystem configuration, CONFIG_UBIFS_FS, CONFIG_SQUASHFS, CONFIG_JFFS2_FS, etc.
- Non-mainline drivers.
Turn the defconfig to a full config with make target_defconfig. Then, apply the target config on top of it, instead of the generic config. Keep the generic config as long as it's used by a target.
This should greatly simplify the kernel configs on OpenWrt. Make the booting and filesystem configuration, and non-mainline drivers more apparent. Most importantly, it will grant people outside of the OpenWrt environment to compile the kernel for their device.
This should reduce maintaining workload. Things like adding missing symbols to generic config, removing outdated symbols from generic config, and moving symbols from target config to generic config would already be handled when defconfig is being turned to a full config.
If a new device support needs to enable a driver that exists on Linux, likely a network driver, add it to the defconfig, submit it to mainline Linux, then backport it on OpenWrt.
The explanation of OpenWrt's kernel config system from Felix Fietkau.

Make a mode menu.
- Filesystem only.
  - OpenWrt only sets up a filesystem image.
  - Use the kernel headers from the current longterm kernel defined on the project.
- Full image.
  - OpenWrt compiles longterm kernel, sets up filesystem image, combines them together, makes the image bootable by the bootloader of the device, U-Boot, CFE, etc.
  - OpenWrt provides own kernel module packages. Make kernel module selection available to use only when the full image mode is selected.
Make a kernel selection menu where the user can choose to feed the kernel directory of their own or use the longterm one defined on OpenWrt. Add this as a suboption to the full image mode.
- Developer option. Some parts of the process, LZMA compression, etc, may not work depending on the kernel size.
- No kernel patches must be applied. There must be an option to disable all the kernel module packages if this option is being used.
- CONFIG_EXTERNAL_KERNEL_TREE is the closest existing option.