Re: [PATCH 0/2] x86/fred: enable FRED by default

[Sohil Mehta <sohil.mehta@intel.com>]

On 3/24/2026 12:50 AM, H. Peter Anvin wrote:

Giving it one last try if I can change your mind :)

> On March 23, 2026 10:08:42 PM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote:
>> On 3/23/2026 8:52 PM, H. Peter Anvin wrote:
>>>>> Nit: Would it be better to compare with "off" rather than not on?
>>>>
>>>> +1 :)
>>>>
>>>
>>> It would change the meaning of something like "fred=0" though.
>>>
>>
>> I don't believe we have ever supported fred=0 or fred=1, did we?
>>
>> Also, I am not sure about letting userspace be creative with command
>> line parameters :) For example, fred=yes and fred=enable will both pass
>> the same check and cause FRED to be disabled.
> 
> Unfortunately right now we *are* being creative: anytime but the exact string "on" disables FRED. 

You are right, we are accepting invalid inputs today. There is a slight
difference though. The default right now is FRED disabled. So any
invalid input would not change the kernel default. Only fred=on enables
the feature.

With FRED proposed to be default on, I think we should match the above
and only let fred=off disable it. All other inputs should be ignored.

> This is a general problem. 

I agree. In general, we shouldn't even need special command line
parameters to *disable* features. clearcpuid=fred would have been
equivalent to fred=off if it didn't taint the kernel. I don't know the
exact history about why the taint is needed.

> In the kernel; overall I feel promoting foo= syntax for booleans, which was not the original style, was a mistake, but here we are.
> 
> Anyway, I don't have a strong preference and I think we can leave that policy decision to the maintainers. 
> 

Yes, that's completely fine with me. I won't push for it any further.