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

Co-authored-by: linusg <[email protected]>

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 :(

dotcarmen · 2025-04-04T20:01:59Z

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

+
+        services: *const RuntimeServices,
+        buffer: []u16,
+        guid: Guid,


i'm working on fixing all errors from refAllDeclsRecursive and running into a problem here because guid isn't guaranteed to be 8-aligned. does anybody know if that's a requirement for getNextVariableName??? i can't find anything on the internet anywhere, and it seems like uefi-rs does the same thing but also the spec says that EFI_GUID* must be 8-aligned unless otherwise specified, and it's not specified for getNextVariableName 😭

I committed the change to getNextVariableName not requiring vendor_guid to be 8-aligned, but if that's not correct i can fix it another way 😅

If you make the first field of Guid align(8) you increase its natural alignment to 8 and you no longer have to think about it. The only place that Guid is ever unaligned in the base specification is in a DevicePath (where everything is unaligned).

omg you can aligned fields! it's not documented and all the syntax options i'd tried were causing parse errors 😅

i don't want to force Guid to be 8-aligned specifically for the case of DevicePath (so you can cast the pointer and it'll 'just work'). this is fixed by making the guid field 8-aligned :)

Making the natural alignment 8 does not force it to be 8-aligned, you can always override alignment with *align(1) etc. GUIDs in the device path are already align(1), so changing the natural alignment serves only to make every *align(8) Guid into just a *Guid.

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

Co-authored-by: truemedian <[email protected]>

truemedian · 2025-04-05T13:22:09Z

lib/std/os/uefi.zig

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

+pub const EventRegistration = *const anyopaque;


An event registration is not arbitrary data (as opposed to say, a notify context which is user-controlled), it refers to a specific opaque structure

Suggested change

pub const EventRegistration = *const anyopaque;

pub const EventRegistration = *const opaque{};

truemedian · 2025-04-05T13:25:50Z

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

+        self: *const RuntimeServices,
+        count: u32,
+    ) GetNextHighMonotonicCountError!u32 {
+        var cnt = count;


count is an out-parameter, the input is clobbered and doesn't matter.

truemedian · 2025-04-05T13:27:09Z

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


    /// Returns the first protocol instance that matches the given protocol.
-    locateProtocol: *const fn (protocol: *align(8) const Guid, registration: ?*const anyopaque, interface: *?*anyopaque) callconv(cc) Status,
+    _locateProtocol: *const fn (protocol: *align(8) const Guid, registration: ?*const anyopaque, interface: ?*?EventRegistration) callconv(cc) Status,


Was the type of these parameters flipped?

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

bnuuydev · 2025-04-06T17:48:38Z

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

+    /// `data` may be a [*:0]const u16 immediately following additional data of
+    /// any format. The string is a description that the caller may use to further
+    /// indicate the reason for the image’s exit. `data` is only valid if `status`
+    /// is something other than `.success`.
+    pub fn exit(
+        self: *BootServices,
+        handle: Handle,
+        status: Status,
+        data: ?[]const u8,
+    ) ExitError!void {
+        switch (self._exit(
+            handle,
+            status,
+            if (data) |d| d.len else 0,
+            if (data) |d| @alignCast(@ptrCast(d.ptr)) else null,
+        )) {
+            .success => {},
+            .invalid_parameter => return error.InvalidParameter,
+            else => |exit_status| return uefi.unexpectedStatus(exit_status),
+        }
+    }


Could this guarantee alignment safety at compile-time?

Suggested change

/// `data` may be a [*:0]const u16 immediately following additional data of

/// any format. The string is a description that the caller may use to further

/// indicate the reason for the image’s exit. `data` is only valid if `status`

/// is something other than `.success`.

pub fn exit(

self: *BootServices,

handle: Handle,

status: Status,

data: ?[]const u8,

) ExitError!void {

switch (self._exit(

handle,

status,

if (data) |d| d.len else 0,

if (data) |d| @alignCast(@ptrCast(d.ptr)) else null,

)) {

.success => {},

.invalid_parameter => return error.InvalidParameter,

else => |exit_status| return uefi.unexpectedStatus(exit_status),

}

}

/// `data` may be a [*:0]const u16 immediately following additional data of

/// any format. The string is a description that the caller may use to further

/// indicate the reason for the image’s exit. `data` is only valid if `status`

/// is something other than `.success`.

pub fn exit(

self: *BootServices,

handle: Handle,

status: Status,

data: ?[]const align(2) u8,

) ExitError!void {

switch (self._exit(

handle,

status,

if (data) |d| d.len else 0,

if (data) |d| @ptrCast(d.ptr) else null,

)) {

.success => {},

.invalid_parameter => return error.InvalidParameter,

else => |exit_status| return uefi.unexpectedStatus(exit_status),

}

}

Additionally, I'm not really sure that I like that this interface uses a slice of bytes rather than u16, when the principal use of this is to return the string, since it makes this sort of invocation of this API use a @ptrcast. However, since you can pass binary data after the null-terminated string, I guess that makes sense? The only alternative I can see would be to split into exit (taking [:0]const u16) and exitBytes ([]const align(2) u8), which is not really ideal either.

bnuuydev · 2025-04-06T17:58:03Z

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


    /// Terminates a loaded EFI image and returns control to boot services.
-    exit: *const fn (image_handle: Handle, exit_status: Status, exit_data_size: usize, exit_data: ?*const anyopaque) callconv(cc) Status,
+    _exit: *const fn (image_handle: Handle, exit_status: Status, exit_data_size: usize, exit_data: ?*const u16) callconv(cc) Status,


Slightly pedantic, but this should really be [*]const u16, no?

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 and others added 9 commits April 4, 2025 16:01

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

5027adc

avoid T{} syntax

221ad47

Co-authored-by: linusg <[email protected]>

misc fixes

d7226bb

work

8712c5a

self-review quickfixes

7b062e4

dont make MemoryMapSlice generic

43e2e61

more review fixes, work

a78748c

more work

40394f2

more work

0733531

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

dotcarmen added 3 commits April 4, 2025 16:06

review fixes

4be853e

update boot/runtime services references throughout codebase

b988c81

self-review fixes

47ca468

dotcarmen commented Apr 4, 2025

View reviewed changes

dotcarmen added 2 commits April 4, 2025 19:47

couple of fixes i forgot to commit earlier

43ff0bf

fixes from integrating in my own project

90f8a58

dotcarmen commented Apr 4, 2025

View reviewed changes

fixes from refAllDeclsRecursive

13a8a41

truemedian reviewed Apr 4, 2025

View reviewed changes

dotcarmen and others added 3 commits April 5, 2025 02:00

Apply suggestions from code review

694a4a1

Co-authored-by: truemedian <[email protected]>

more fixes from review

e1ec640

fixes from project integration

1fadc88

truemedian reviewed Apr 5, 2025

View reviewed changes

bnuuydev reviewed Apr 6, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

dotcarmen commented Apr 2, 2025

dotcarmen commented Apr 2, 2025

linusg commented Apr 2, 2025

linusg left a comment

dotcarmen Apr 2, 2025

dotcarmen Apr 2, 2025

dotcarmen Apr 2, 2025

truemedian left a comment

dotcarmen Apr 3, 2025

dotcarmen Apr 3, 2025

dotcarmen Apr 4, 2025

dotcarmen commented Apr 4, 2025 •

edited

Loading

dotcarmen Apr 4, 2025

dotcarmen Apr 4, 2025

dotcarmen Apr 4, 2025

truemedian Apr 4, 2025

dotcarmen Apr 5, 2025

truemedian Apr 5, 2025

truemedian Apr 5, 2025

truemedian Apr 5, 2025

truemedian Apr 5, 2025

bnuuydev Apr 6, 2025

bnuuydev Apr 6, 2025

bnuuydev Apr 6, 2025


		/// 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 {

	pub const EventRegistration = *const anyopaque;
	pub const EventRegistration = *const opaque{};

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

Are you sure you want to change the base?

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

Conversation

dotcarmen commented Apr 2, 2025

dotcarmen commented Apr 2, 2025

linusg commented Apr 2, 2025

linusg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

truemedian left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dotcarmen commented Apr 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dotcarmen commented Apr 4, 2025 •

edited

Loading