Hi Kees, On 8/29/25 7:01 PM, Kees Cook wrote: > During kernel option migrations (e.g. CONFIG_CFI_CLANG to CONFIG_CFI), > existing .config files need to maintain backward compatibility while > preventing deprecated options from appearing in newly generated > configurations. This is challenging with existing Kconfig mechanisms > because: > > 1. Simply removing old options breaks existing .config files. > 2. Manually listing an option as "deprecated" leaves it needlessly > visible and still writes them to new .config files. > 3. Using any method to remove visibility (.e.g no 'prompt', 'if n', > etc) prevents the option from being processed at all. > > Add a "transitional" attribute that creates symbols which are: > - Processed during configuration (can influence other symbols' defaults) > - Hidden from user menus (no prompts appear) > - Omitted from newly written .config files (gets migrated) > - Restricted to only having help sections (no defaults, selects, etc) > making it truly just a "prior value pass-through" option. > > The transitional syntax requires a type argument and prevents type > redefinition: > > config OLD_OPTION > transitional bool > help > Transitional config for OLD_OPTION migration. > > config NEW_OPTION > bool "New option" > default OLD_OPTION > > This allows seamless migration: olddefconfig processes existing > CONFIG_OLD_OPTION=y settings to enable CONFIG_NEW_OPTION=y, while > CONFIG_OLD_OPTION is omitted from newly generated .config files. > > Implementation details: > - Parser validates transitional symbols can only have help sections > - Symbol visibility logic updated: usable = (visible != no || transitional) > - Transitional symbols preserve user values during configuration > - Type safety enforced to prevent redefinition after transitional declaration > - Used distinct struct members instead of new flags for readability > - Documentation added to show the usage > > Signed-off-by: Kees Cook <kees@xxxxxxxxxx> > --- > With help from Claude Code to show me how to navigate the kconfig parser. Are you (implicitly?) saying that all previous attempts at transitional kconfig symbols have failed? If so, I just wasn't aware of that. Or is there some new prime directive that requires this? Thanks. -- ~Randy
