From: Jarod Wilson on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3592#note_2297199662 Okay, I may ramble a little here... I think overlaying the automotive configs on the base RHEL configs like this is the right way to go, at least for now. Generally speaking, it'll inherit the base RHEL configs, but for very specific cases, it can be certain that it will never enable something if it's explicitly configured off in the overlay configs, even if RHEL eventually decides to turn it on for some reason. Part of the problem hopefully goes away if we stop having automotive in a separate branch like the old RT days, and move it back into the main branch like RT is now, and then it'd be safer to rely on a single file setting everything to off across all variants, since it'd be clearer when trying to enable it for one kernel that it was also being enabled for another. Either way, probably just about every config knob change probably needs automotive review, which does sort of suggest there's some merit in maintaining a completely separate config for it, but then we'd need two separate MRs to propose turning on the same config knob for kernel/kernel-rt and for automotive, which isn't exactly optimal either. I think you want that common ancestry to really ensure it's "RHEL-based" and core subsystem changes/enablements are getting reviewed by the right people, for functional safety reasons, etc. So yeah, after talking myself in circles, I think I still think this is the right thing to do right now. Start with the base kernel config, overlay RT changes, then overlay automotive changes, and that's your automotive kernel config. And if there are things you KNOW you never want on, then it doesn't really hurt to have a redundant disabling (or vice versa) overlay to prevent accidental config changes via inheritance. In theory, there shouldn't be too many of those, but... who knows. -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
