I'm sorry for postponing this further, but I'm unsure regarding the API. Here, we panic and return aNonNull.system_table_boot() and system_table_runtime() below returnOptions. Is this consistent? Or is it fine to have this difference between internal and public API?

No worries, happy to discuss API decisions. I think having both panicking and non-panicking variants is useful, depending on the circumstances. The function that gets the raw system table should essentially never fail -- the panic can only be reached if the table pointer is null, which means the user isn't using theentry macro, or has anunsafe call toset_system_table(null).

In the high-level API, we could (for example) changesystem::firmware_vendor to return aResult, with an error if the system table is null. But in practice, I think it's likely that users would simplyunwrap the result anyway.

If we accept the above argument, that means will have a decent number of places where we want to panic internally if the system table isn't set. And for each of those places we want to useexpect with a clear error message rather thanunwrap, so if that panic is ever hit it's clear why. And since we don't want to write out.expect("global system table pointer is not set") in multiple places, we end up with this shared function.

I'll also note that I see thesystem_table_boot andsystem_table_runtime functions as transitional APIs. Once thesystem,boot, andruntime modules are in place, I want to markSystemTable,BootServices, andRuntimeServices as deprecated, and then after a release or two we can remove those deprecated APIs entirely.

Now, with all that said, we might want a non-panicking variant in the future as well (e.g. for functions that already return aResult), so I've pushed a change to rename it tosystem_table_raw_panicking.

But in practice, I think it's likely that users would simply unwrap the result anyway.

Agree

I'll also note that I see the system_table_boot and system_table_runtime functions as transitional API

got it

I want to mark SystemTable, BootServices, and RuntimeServices as deprecated, and then after a release or two we can remove those deprecated APIs entirely.

Is there already a todo anywhere for that?

Generally, I think panicking at a core function is perfectly fine. Especially, as this will never fail, if people properly use the#[entry] macro.

Is there already a todo anywhere for that?

Added a new summary comment here:#893 (comment)

nit: In a follow-up: We might should add a[new api] "tag" for that in the changelog - this might ease consumers to understand what's going on

Agreed, I was thinking maybe just add a short paragraph between# uefi and## Added .