[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250508105502.GAaByNhlpwwdK6_ZyL@fat_crate.local>
Date: Thu, 8 May 2025 12:55:02 +0200
From: Borislav Petkov <bp@...en8.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
linux-efi@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>,
Dionna Amalie Glaze <dionnaglaze@...gle.com>,
Kevin Loughlin <kevinloughlin@...gle.com>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFT PATCH v2 00/23] x86: strict separation of startup code
On Wed, May 07, 2025 at 02:05:37PM +0200, Ard Biesheuvel wrote:
> So I'd actually argue for splitting this up even more rather than
> bundling it all together,
Splitting it into logically separated bits? Yes. Just because: no.
The SEV stuff is still largely in motion so once it starts settling down,
splitting it would be the first thing that irks me and I'll go do it.
> although the sev vs sev-internal distinction is a bit dubious - it would be
> better to split this across functional lines.
>
> I added sev-internal.h so that that single mother-of-all-source-files
> could be hacked up without exposing implementation details to external
> users that were hidden before. I.e., the high-level APIs that other
> callers need to use should be in sev.h, and the implementation of that
> API should be carved up meaningfully. For example, perhaps the #VC
> handling stuff (which now lives in a separate source file) could be
> exposed via sev-vc.h, and only included in places where that
> particular functionality is being used.
Right, please put those considerations in the commit messages - it helps a lot
with the review.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists