std.os.uefi.tables: ziggify boot and runtime services #23441

dotcarmen · 2025-04-02T17:18:14Z

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

dotcarmen · 2025-04-02T17:18:59Z

@linusg

linusg · 2025-04-02T17:21:40Z

another-one.png

It is appreciated! :^)

linusg

Not a thorough review, LGTM at a high level

lib/std/os/uefi.zig

lib/std/os/uefi/tables/boot_services.zig

dotcarmen · 2025-04-02T17:27:55Z

lib/std/os/uefi/tables/boot_services.zig


    /// Returns the current memory map.
-    getMemoryMap: *const fn (mmap_size: *usize, mmap: ?[*]MemoryDescriptor, map_key: *usize, descriptor_size: *usize, descriptor_version: *u32) callconv(cc) Status,
+    _getMemoryMap: *const fn (mmap_size: *usize, mmap: [*]MemoryDescriptor, map_key: *MemoryMapKey, descriptor_size: *usize, descriptor_version: *u32) callconv(cc) Status,


i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

lib/std/os/uefi/tables/boot_services.zig

dotcarmen · 2025-04-02T17:46:22Z

lib/std/os/uefi/tables/boot_services.zig

+        interfaces: anytype,
+    ) InstallProtocolInterfacesError!Handle {
+        var hdl: ?Handle = handle;
+        const args_tuple = protocolInterfaces(&hdl, interfaces);


i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

dotcarmen · 2025-04-02T17:47:35Z

lib/std/os/uefi/tables/boot_services.zig

 };
+
+fn protocolInterfaces(


this function is kinda gross :/ suggestions are welcome

lib/std/os/uefi/tables/boot_services.zig

truemedian

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

lib/std/os/uefi/tables/boot_services.zig

lib/std/os/uefi/tables.zig

dotcarmen · 2025-04-03T15:09:03Z

lib/std/os/uefi/tables/boot_services.zig

-    raiseTpl: *const fn (new_tpl: usize) callconv(cc) usize,
+    raiseTpl: *const fn (new_tpl: TaskPriorityLevel) callconv(cc) TaskPriorityLevel,

    /// Restores a task's priority level to its previous value.
-    restoreTpl: *const fn (old_tpl: usize) callconv(cc) void,
+    restoreTpl: *const fn (old_tpl: TaskPriorityLevel) callconv(cc) void,


doesn't make sense to define wrappers for these functions imo

lib/std/os/uefi/tables/boot_services.zig

dotcarmen · 2025-04-03T15:15:33Z

lib/std/os/uefi/tables/boot_services.zig


-    /// Opens a protocol with a structure as the loaded image for a UEFI application
-    pub fn openProtocolSt(self: *BootServices, comptime protocol: type, handle: Handle) !*protocol {


this function is now basically the handleProtocol function

lib/std/os/uefi/tables.zig

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi/tables/boot_services.zig

lib/std/Thread.zig

lib/std/os/uefi/pool_allocator.zig

dotcarmen · 2025-04-04T16:33:13Z

lib/std/debug.zig

@@ -639,7 +639,8 @@ pub fn defaultPanic(
                // ExitData buffer must be allocated using boot_services.allocatePool (spec: page 220)
                const exit_data: []u16 = uefi.raw_pool_allocator.alloc(u16, exit_msg.len + 1) catch @trap();
                @memcpy(exit_data, exit_msg[0..exit_data.len]); // Includes null terminator.
-                _ = bs.exit(uefi.handle, .aborted, exit_data.len, exit_data.ptr);


afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

dotcarmen · 2025-04-04T16:33:55Z

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

dotcarmen · 2025-04-04T18:15:28Z

lib/std/os/uefi/tables/boot_services.zig

@@ -134,7 +134,7 @@ pub const BootServices = extern struct {
    _setWatchdogTimer: *const fn (timeout: usize, watchdog_code: u64, data_size: usize, watchdog_data: ?[*]const u16) callconv(cc) Status,

    /// Connects one or more drives to a controller.
-    _connectController: *const fn (controller_handle: Handle, driver_image_handle: ?[*:null]Handle, remaining_device_path: ?*const DevicePathProtocol, recursive: bool) callconv(cc) Status,


really feels like [*:null]*anyopaque should work :(

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi.zig

lib/std/os/uefi/pool_allocator.zig

lib/std/os/uefi/tables.zig

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi.zig

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi/tables/boot_services.zig

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi/tables/boot_services.zig

dotcarmen · 2025-04-10T17:03:27Z

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

dotcarmen

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

dotcarmen · 2025-04-13T19:04:02Z

lib/std/os/uefi.zig

 /// A handle to an event structure.
 pub const Event = *opaque {};

+pub const EventRegistration = opaque {};


I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

lib/std/os/uefi/tables/boot_services.zig

dotcarmen · 2025-04-14T13:22:42Z

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

truemedian · 2025-04-17T19:35:24Z

lib/std/os/uefi.zig

 /// A handle to an event structure.
 pub const Event = *opaque {};

+pub const EventRegistration = opaque {};


The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

lib/std/os/uefi/tables.zig

lib/std/os/uefi/tables/runtime_services.zig

dotcarmen

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

dotcarmen · 2025-04-18T15:08:09Z

lib/std/os/uefi/tables.zig

+    pub const InvalidValue = math.IntFittingRange(
+        @intFromEnum(MemoryType.invalid_start),
+        @intFromEnum(MemoryType.invalid_end),
+    );
+    pub const OemValue = math.IntFittingRange(
+        @intFromEnum(MemoryType.oem_start),
+        @intFromEnum(MemoryType.oem_end),
+    );
+    pub const VendorValue = math.IntFittingRange(
+        @intFromEnum(MemoryType.vendor_start),
+        @intFromEnum(MemoryType.vendor_end),
+    );


define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

dotcarmen · 2025-04-18T15:08:52Z

lib/std/os/uefi/tables.zig

+    pub fn invalid(value: InvalidValue) MemoryType {
+        const invalid_start = @intFromEnum(MemoryType.invalid_start);
+        return @enumFromInt(invalid_start + value);
+    }


function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

dotcarmen · 2025-04-18T15:09:25Z

lib/std/os/uefi/tables.zig

+    pub fn getInvalid(memtype: MemoryType) ?InvalidValue {
+        const as_int = @intFromEnum(memtype);
+        const invalid_start = @intFromEnum(MemoryType.invalid_start);
+        if (as_int < invalid_start) return null;
+        if (as_int > @intFromEnum(MemoryType.invalid_end)) return null;
+        return @truncate(as_int - invalid_start);
+    }


function for retrieving the value relative to the range's start

kouosi · 2025-04-18T16:28:42Z

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

truemedian · 2025-04-18T16:34:32Z

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

kouosi · 2025-04-18T17:04:15Z

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

This backs out commit cdd9bd6.

dotcarmen · 2025-07-02T11:15:33Z

rebased to latest master :)

linusg

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

lib/std/os/uefi/tables.zig

lib/std/os/uefi.zig

lib/std/os/uefi/tables/boot_services.zig

lib/std/os/uefi/tables/configuration_table.zig

lib/std/os/uefi/tables/runtime_services.zig

lib/std/os/uefi/tables.zig

dotcarmen · 2025-07-11T19:44:23Z

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

linusg · 2025-07-12T10:48:50Z

CI is failing

dotcarmen · 2025-07-12T10:49:51Z

yup, just saw that lol, looking into it now

linusg · 2025-07-12T11:40:17Z

Thanks for your patience with this! Let's merge 🎉

RossComputerGuy · 2025-07-12T17:21:37Z

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

* std.os.uefi.tables: ziggify boot and runtime services * avoid T{} syntax Co-authored-by: linusg <[email protected]> * misc fixes * work * self-review quickfixes * dont make MemoryMapSlice generic * more review fixes, work * more work * more work * review fixes * update boot/runtime services references throughout codebase * self-review fixes * couple of fixes i forgot to commit earlier * fixes from integrating in my own project * fixes from refAllDeclsRecursive * Apply suggestions from code review Co-authored-by: truemedian <[email protected]> * more fixes from review * fixes from project integration * make natural alignment of Guid align-8 * EventRegistration is a new opaque type * fix getNextHighMonotonicCount * fix locateProtocol * fix exit * partly revert 7372d65 * oops exit data_len is num of bytes * fixes from project integration * MapInfo consistency, MemoryType update per review * turn EventRegistration back into a pointer * forgot to finish updating MemoryType methods * fix IntFittingRange calls * set uefi.Page nat alignment * Back out "set uefi.Page nat alignment" This backs out commit cdd9bd6. * get rid of some error.NotFound-s * fix .exit call in panic * review comments, add format method * fix resetSystem data alignment * oops, didnt do a final refAllDeclsRecursive i guess * review comments * writergate update MemoryType.format * fix rename --------- Co-authored-by: linusg <[email protected]> Co-authored-by: truemedian <[email protected]>

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch from ee41a75 to e4487d5 Compare April 2, 2025 17:22

linusg reviewed Apr 2, 2025

View reviewed changes

linusg mentioned this pull request Apr 2, 2025

std: rework uefi allocators #22818

Open

dotcarmen commented Apr 2, 2025

View reviewed changes

truemedian reviewed Apr 2, 2025

View reviewed changes

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch from e4487d5 to 5ad806e Compare April 2, 2025 18:35

dotcarmen mentioned this pull request Apr 2, 2025

std.os.uefi.protocol.File: fix some typed definitions #23443

Merged

dotcarmen commented Apr 3, 2025

View reviewed changes

truemedian reviewed Apr 3, 2025

View reviewed changes

lib/std/os/uefi/tables.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables/runtime_services.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables/boot_services.zig Outdated Show resolved Hide resolved

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch from 50823da to 0733531 Compare April 4, 2025 14:02

dotcarmen commented Apr 4, 2025

View reviewed changes

lib/std/os/uefi/tables/runtime_services.zig Show resolved Hide resolved

truemedian reviewed Apr 4, 2025

View reviewed changes

truemedian reviewed Apr 5, 2025

View reviewed changes

lib/std/os/uefi.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables/runtime_services.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables/boot_services.zig Outdated Show resolved Hide resolved

lib/std/os/uefi/tables/runtime_services.zig Show resolved Hide resolved

bnuuydev reviewed Apr 6, 2025

View reviewed changes

lib/std/os/uefi/tables/boot_services.zig Outdated Show resolved Hide resolved

bnuuydev reviewed Apr 6, 2025

View reviewed changes

lib/std/os/uefi/tables/boot_services.zig Outdated Show resolved Hide resolved

dotcarmen commented Apr 13, 2025

View reviewed changes

bnuuydev reviewed Apr 13, 2025

View reviewed changes

lib/std/os/uefi/tables/boot_services.zig Outdated Show resolved Hide resolved

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch from 46d8e68 to d37be42 Compare April 13, 2025 21:45

truemedian reviewed Apr 17, 2025

View reviewed changes

dotcarmen commented Apr 18, 2025

View reviewed changes

dotcarmen added 11 commits July 2, 2025 13:09

MapInfo consistency, MemoryType update per review

b2e35f4

turn EventRegistration back into a pointer

99d7a34

forgot to finish updating MemoryType methods

2fff399

fix IntFittingRange calls

cefa6cd

set uefi.Page nat alignment

1027e0d

Back out "set uefi.Page nat alignment"

3f32679

This backs out commit cdd9bd6.

get rid of some error.NotFound-s

0ecda35

fix .exit call in panic

9f1bd86

review comments, add format method

e13de1c

fix resetSystem data alignment

6cc6434

oops, didnt do a final refAllDeclsRecursive i guess

819a6c6

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch from 51ed5dc to 819a6c6 Compare July 2, 2025 11:10

linusg reviewed Jul 2, 2025

View reviewed changes

linusg reviewed Jul 10, 2025

View reviewed changes

lib/std/os/uefi/tables.zig Outdated Show resolved Hide resolved

review comments

a6c60c3

dotcarmen force-pushed the ziggify-uefi-boot-runtime-services branch 3 times, most recently from 3065959 to 819a6c6 Compare July 11, 2025 19:42

dotcarmen added 2 commits July 11, 2025 21:47

merge latest master

2517ac7

writergate update MemoryType.format

cc6f15a

fix rename

8676b6a

linusg enabled auto-merge (squash) July 12, 2025 11:40

linusg merged commit 5b4e982 into ziglang:master Jul 12, 2025
12 checks passed


		/// Opens a protocol with a structure as the loaded image for a UEFI application
		pub fn openProtocolSt(self: BootServices, comptime protocol: type, handle: Handle) !protocol {

Uh oh!

std.os.uefi.tables: ziggify boot and runtime services #23441

std.os.uefi.tables: ziggify boot and runtime services #23441

Uh oh!

Conversation

dotcarmen commented Apr 2, 2025

Uh oh!

dotcarmen commented Apr 2, 2025

Uh oh!

linusg commented Apr 2, 2025

Uh oh!

linusg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

truemedian left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotcarmen commented Apr 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dotcarmen commented Apr 4, 2025 •

edited

Loading

dotcarmen commented Apr 14, 2025 •

edited

Loading

dotcarmen Apr 18, 2025 •

edited

Loading

kouosi commented Apr 18, 2025 •

edited

Loading