Messages in this thread | | | Date | Mon, 16 Oct 2023 11:45:38 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v4] x86/bugs: Add a separate config for each mitigation |
| |
* Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> On Fri, Oct 13, 2023 at 12:50:59PM +0200, Ingo Molnar wrote: > > > > * Josh Poimboeuf <jpoimboe@kernel.org> wrote: > > > > > On Thu, Oct 12, 2023 at 08:51:24PM +0200, Ingo Molnar wrote: > > > > > Another way to avoid ifdeffery: > > > > > > > > > > static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init = > > > > > IS_ENABLED(CONFIG_MITIGATION_RETBLEED) ? RETBLEED_CMD_AUTO : RETBLEED_CMD_OFF; > > > > > > > > I think we could make it a simple: > > > > > > > > static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init = IS_ENABLED(CONFIG_MITIGATION_RETBLEED); > > > > > > > > Because RETBLEED_CMD_AUTO && RETBLEED_CMD_OFF maps naturally to 1 and 0. > > > > Maybe add a comment to the enum to maintain this property in the future > > > > too. > > > > > > Hm, that both obfuscates the default and makes it fragile. The fact > > > that it would need a comment to try to prevent breaking it in the future > > > is a clue that maybe we shouldn't do it ;-) > > > > Can be enforced with BUILD_BUG_ON(). > > That replaces fragility with brittleness. If we change a default then > we have to go rearrange the corresponding enum, and update the > BUILD_BUG_ONs.
How realistic is that? A world in which an enum named '*_OFF' isn't zero and the most obvious second enum isn't 'auto' would be unconditionally sad IMO...
> More importantly, it's still less readable because the reader now has to > go read the enum values to cross-reference the hard-coded values of 0 and > 1 with the enums which are used everywhere else.
They'd have to do that anyway, to make sense of the enum jungle.
Thanks,
Ingo
| |