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@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to