linux-kernel - Re: [PATCH 4/7] EDAC/{skx_common,imh}: Add EDAC driver for Intel Diamond Rapids servers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251119152430.GEaR3hLonaUag36pFg@fat_crate.local>
Date: Wed, 19 Nov 2025 16:24:30 +0100
From: Borislav Petkov <bp@...en8.de>
To: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
Cc: Tony Luck <tony.luck@...el.com>, Yi Lai <yi1.lai@...el.com>,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/7] EDAC/{skx_common,imh}: Add EDAC driver for Intel
 Diamond Rapids servers

On Wed, Nov 19, 2025 at 09:41:28PM +0800, Qiuxu Zhuo wrote:
> 2) Validation processes are costly. Modifications to i10nm_edac would
>    require extensive validation checks against multiple platforms,
>    including Ice Lake, Sapphire Rapids, Emerald Rapids, Granite Rapids,
>    Sierra Forest, and Grand Ridge.

Isn't that what we do all the time anyway? Make sure the kernel works on new
hardware and so on.

I'd understand if adding this new support would mean uglifying i10nm_edac but
just because you can't test it on old hw sounds a bit iffy. By that logic we
should simply spit out a new driver for every new hw generation and in the
end, that strategy will come back to bite you because you'll end up
maintaining a pile of duplicated drivers.

So I hope there are more valid reasons justifying a new driver than just
"validation."

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette