What to do with kconfig.socs?
summary
kconfig.socs currently holds five entries in kconfig.socs that try and drive dozens of drivers via select and imply, which breaks dependencies, overrides module choices, and causes silent boot regressions. Proposal: stop global selects, move platform symbols into arch Kconfig like ARM does, keep heavy drivers as modules and only force minimal built‑in essentials in defconfig, and test changes on real boards so regressions are caught. Reject imply and menu select abuse; prefer explicit depends and scrub defconfig cruft.
AI-written summary · about
chapters (12)
- 0:00Introduction and problem
- 1:03Current kconfig.socs setup
- 3:12Problems with current approach
- 5:00Better alternatives to selects
- 7:50Implications and imply keyword
- 9:16Historical context and naming
- 10:39Proposed solution for kconfig.socs
- 12:48Special cases and minimal kernels
- 15:00Testing and fallout handling
- 16:26Default conflicts and dev config
- 18:13Future-proofing and cleanup
- 20:00Q&A and wrap-up
related talks
03mIntroduction
44mConfigure Zephyr: Kconfigs and Devicetree in Simple Words
55mThe Embedded Linux Problem
36mLinux Kernel Developer Panel
50mHow Not to Write X86 Platform Drivers
28mBuild System Analysis for Kernel Development and Customization
30mSchism: Splitting RV32 from `arch/riscv` - - We Could Both... "Ruinland"
25mPreparing RISC-V Linux for RVA23