Am Mittwoch, 4. Januar 2023, 16:21:53 CET schrieb Andrew Jones: > On Fri, Dec 02, 2022 at 05:37:16PM +0100, Ard Biesheuvel wrote: > > On Thu, 1 Dec 2022 at 23:39, Heiko Stübner <heiko@xxxxxxxxx> wrote: > > > > > > Hi Ard, > > > > > > Am Donnerstag, 1. Dezember 2022, 21:57:00 CET schrieb Ard Biesheuvel: > > > > On Thu, 1 Dec 2022 at 20:35, Andrew Jones <ajones@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Nov 30, 2022 at 11:56:12PM +0100, Heiko Stuebner wrote: > > > > > > From: Heiko Stuebner <heiko.stuebner@xxxxxxxx> > > > > > > > > > > > > We may want to runtime-optimize some core functions (str*, mem*), > > > > > > but not have this leak into libstub and cause build issues. > > > > > > Instead libstub, for the short while it's running, should just use > > > > > > the generic implementation. > > > > > > > > > > > > So, to be able to determine whether functions, that are used both in > > > > > > libstub and the main kernel, are getting compiled as part of libstub or > > > > > > not, add a compile-flag we can check via #ifdef. > > > > > > > > > > > > Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > > > > > > Signed-off-by: Heiko Stuebner <heiko.stuebner@xxxxxxxx> > > > > > > > > I think it would be better to update arch/riscv/kernel/image-vars.h so > > > > that only these generic implementations are exposed to the stub in the > > > > first place. > > > > > > > Actually, all references to string and memory functions are going away > > from the stub. This is already in -next. > > > > EFI now has zboot support, which means you can create a EFI bootable > > kernel image that carries the actual kernel in compressed form rather > > than as a hybrid EFI/bare metal image. > > While chatting about EFI stub string functions again in the context of [1] > we recalled this comment that states the references should be going away > anyway. I'm just replying here with interested parties on CC to try and > bring it back to the forefront. > > [1] https://lore.kernel.org/all/20221216162141.1701255-5-alexghiti@xxxxxxxxxxxx/ I'm currently following Ard's other suggestion and am using a more traditional model for str* functions (aka non-inline). One thing I found on the new EFI parts was that while it provides it's own implementations, it does not provide it's own prototype. On the real kernel-side all the HAVE_ARCH_* blocks do wrap around both the generic implementation as well as the prototype in string.h, and there _are_ other implementations of str* or mem* functions done as inline, on other arches. So that may be something that might need fixing on the EFI-side. Heiko
