std: rework uefi allocators

[RossComputerGuy]

Split off from #22226 as suggested by @linusg. This reworks the allocators to be more friendly.

[linusg]

Thank you, this is the right size for a PR like this :)

Two high level concerns:

• All allocators, including platform-specific ones like WasmAllocator currently live in std.heap. If we're moving these around that should be where.
• Why are we adding additional abstractions on top of the UEFI-provided allocator functions? In general that's a good thing if it improves ergonomics of those APIs from a Zig perspective, but in this case no one but the allocator implementation should touch those, and I feel in that case the extra layer is not justified.

[RossComputerGuy]

• All allocators, including platform-specific ones like WasmAllocator currently live in std.heap. If we're moving these around that should be where.

Will do

• Why are we adding additional abstractions on top of the UEFI-provided allocator functions? In general that's a good thing if it improves ergonomics of those APIs from a Zig perspective, but in this case no one but the allocator implementation should touch those, and I feel in that case the extra layer is not justified.

I'm not 100% sure, this originally came from @truemedian.

[truemedian]

Why are we adding additional abstractions

Which additional abstractions are you referring to?

PageAllocator.resize requesting new pages at the end of the current allocation happens because it's essentially free and part of the UEFI page allocation interface

PoolAllocator exists because RawPoolAllocator cannot handle the full range of possible alignment values the Allocator interface requires

[linusg]

Which additional abstractions are you referring to?

The ones in boot_services.zig.

[truemedian]

Ah, thats because this came out of a branch where the goal was to make std.os.uefi a more idiomatic interface instead of just a loose C library binding.

[linusg]

Please rebase this after #22820 and provide a compelling use case for the custom layer in boot_services.zig or remove it.

[linusg]

The namespacing here is awkward, this ought to be a file-as-struct (UefiPageAllocator.zig).

[RossComputerGuy]

Why file as a struct when there's multiple allocators?

[linusg]

Because std.heap.UefiPageAllocator is much nicer than std.heap.uefi_allocators.PageAllocator (which violates https://ziglang.org/documentation/master/#Avoid-Redundant-Names-in-Fully-Qualified-Namespaces). Why do you want both allocators in the same file?

[RossComputerGuy]

Because std.heap.UefiPageAllocator is much nicer than std.heap.uefi_allocators.PageAllocator

Wouldn't std.heap.uefi.Page/Pool be nicer?

Why do you want both allocators in the same file?

Just so there isn't 3 more files that could fit into 1.

[RossComputerGuy]

Please rebase this after #22820

Already been rebased.

provide a compelling use case for the custom layer in boot_services.zig or remove it.

I don't have one unless @truemedian does. I think it just makes the API easier to use and it's already there. Shouldn't need additional maintenance since UEFI's API doesn't really change in that section. I probably will just remove it.

[linusg]

Already been rebased.

I see at least one reference to .LoaderData which has been renamed.

[RossComputerGuy]

I see at least one reference to .LoaderData which has been renamed.

Fixed, strange that one didn't get caught when I tried compiling lib/init.

[linusg]

I think it just makes the API easier to use and it's already there. Shouldn't need additional maintenance

For the most part Zig follows YAGNI principles.