On 19.02.25 17:55, 'Raphael Lisicki' via EFI Boot Guard wrote: > > > On 19.02.25 17:49, Jan Kiszka wrote: >> On 19.02.25 17:30, 'Raphael Lisicki' via EFI Boot Guard wrote: >>> Hi Jan, >>> >>> On 19.02.25 16:56, Jan Kiszka wrote: >>>> >>>> We can simply make that usage of ebg_env_getglobalstate with NULL as >>>> parameter official. It was and it will be never used because that >>>> "global" in this function implies that a single, externally managed env >>>> cannot contribute anything to the call. >>>> >>> >>> At least in version 0.15-1 directly calling ebg_env_getglobalstate did not >>> work. It appeared to work but the returned result was always the same. >>> That's why Bjoerns snippet still contains ebg_env_open_current allthough >>> its return value is not used. >>> >>> ebg_env_open_current and others do some internal initialization (not >>> referenced by their returned handle) that is needed as well. >>> >> >> That seems even more weird. All that should still be needed is bgenv_init. > > I don't remember which function it was, maybe that one. I only remember that > the function was not declared in a system header. Linking by implicit > declaration worked, but seemed worse than the lone ebg_env_open_current. >
Ouch, yes, bgenv_init is only indirectly called, either via ebg_env_create_new or ebg_env_open_current. We could also call it in ebg_env_getglobalstate, though. >> >> Can you reproduce with the latest version as well? > > I can try again tomorrow. > No need to, no difference there, unfortunately. Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/efibootguard-dev/e4ed8350-d76b-4fde-8de6-3173a80d2a72%40siemens.com.
