[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240122131910.GRZa5rTpEda4I1YfUX@fat_crate.local>
Date: Mon, 22 Jan 2024 14:19:10 +0100
From: Borislav Petkov <bp@...en8.de>
To: Xin Li <xin3.li@...el.com>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-edac@...r.kernel.org, linux-hyperv@...r.kernel.org,
kvm@...r.kernel.org, xen-devel@...ts.xenproject.org,
tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, luto@...nel.org, pbonzini@...hat.com,
seanjc@...gle.com, peterz@...radead.org, jgross@...e.com,
ravi.v.shankar@...el.com, mhiramat@...nel.org,
andrew.cooper3@...rix.com, jiangshanlai@...il.com,
nik.borisov@...e.com, shan.kang@...el.com
Subject: Re: [PATCH v13 08/35] x86/fred: Disable FRED by default in its early
stage
On Tue, Dec 05, 2023 at 02:49:57AM -0800, Xin Li wrote:
> Warning: use of this parameter will taint the kernel
> and may cause unknown problems.
>
> + fred [X86-64]
> + Enable flexible return and event delivery
Let's make it accept multiple options from the get-go:
fred=on,disable-when,foo,bar,bla...
in case we need to tweak its behavior.
If it is only "fred" it will propagate this way downstream and it'll
lead to confusion later when people have to update their scripts and
config files when "fred" alone doesn't do what they're expecting
anymore.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists