std: implement basic io for UEFI by RossComputerGuy · Pull Request #22226 · ziglang/zig

RossComputerGuy · 2024-12-13T09:04:45Z

Largely based on #19486, this PR marks me starting to work on UEFI support in Zig again. This time, there will be multiple PR's instead of one so it becomes easier to manage. This PR simply makes the zig init example build.

I tested this in QEMU by loading in OVMF, entering the UEFI shell, loading FS0:\bin\$.efi. The zig-out can be shared by adding: -drive file=fat:rw:zig-out.

alexrp · 2024-12-13T15:39:49Z

@@ -1,5 +1,7 @@
 const std = @import("../std.zig");

+pub const posix = @import("uefi/posix.zig");


Last I talked with Andrew about the future of std.posix, one thing we agreed on is that probably all Windows code in std.posix should be deleted. I would expect that the exact same thing is true of UEFI, as it is also not a POSIX platform in any meaningful sense?

Yeah, I agree. The UEFI POSIX stuff is just a POSIX wrapper around the UEFI protocols. We can always ditch it. UEFI is close to Windows so I think whatever we do for Windows and POSIX, it would apply to UEFI.

alexrp · 2024-12-13T15:43:05Z

 }

-const Impl = if (builtin.single_threaded)
+const Impl = if (builtin.single_threaded or builtin.os.tag == .uefi)


Should UEFI be treated as a proper single-threaded target?
zig/src/target.zig
Lines 66 to 81 in 82f35c5
pubfnalwaysSingleThreaded(target: std.Target) bool {
_=target;
returnfalse;
}
pubfndefaultSingleThreaded(target: std.Target) bool {
switch (target.cpu.arch) {
.wasm32, .wasm64=>returntrue,
else=> {},
}
switch (target.os.tag) {
.haiku=>returntrue,
else=> {},
}
returnfalse;
}

Yes, I just didn't know where the source was which defined that heh.

I've updated this and changed the defaultSingleThreaded for UEFI.

Out of curiosity, is UEFI not always single threaded instead of just default single threaded?

You technically could implement a form of multithreading, just like with wasm. It's just builtin.single_threaded will default to true when single_threaded is not changed in your build. You probably could write a custom scheduler + mutltithreading stuff and use root.os stuff to get it working but no implementation will be made for upstream.

I learned somewhat recently that UEFI does have EFI_MP_SERVICES_PROTOCOL so there is a way to do multiprocessing but not multithreading but likely is still out of the scope.

linusg · 2024-12-19T11:08:15Z

 /// no particular encoding.
 pub const max_path_bytes = switch (native_os) {
- .linux, .macos, .ios, .freebsd, .openbsd, .netbsd, .dragonfly, .haiku, .solaris, .illumos, .plan9, .emscripten, .wasi => posix.PATH_MAX,
+ .linux, .macos, .ios, .freebsd, .openbsd, .netbsd, .dragonfly, .haiku, .solaris, .illumos, .plan9, .emscripten, .wasi, .uefi => posix.PATH_MAX,


This looks wrong, I'd assume it needs to use similar logic as windows

I think this ties in with #22226 (comment)

linusg · 2024-12-19T11:10:15Z

+
+ pub fn next(self: *Self) Error!?Entry {
+ _ = self;
+ return null;


Not sure if turning a compile error into a non-functional stub is that useful? Most people will assume the standard library functions work for a certain target if they compile.

Yeah, I hadn't figured out how to implement it just yet. I'll leave it out of this PR and work on it later on.

linusg · 2024-12-19T11:13:49Z

+/// Allocates memory in pages.
+///
+/// This allocator is backed by `allocatePages` and is therefore only suitable for usage when Boot Services are available.
+pub const PageAllocator = struct {


std.os.uefi.allocator.{Page,Pool}Allocator violates https://ziglang.org/documentation/master/#Avoid-Redundant-Names-in-Fully-Qualified-Namespaces

I have changed it now, hopefully it doesn't violate the fully qualified namespace stuff.

linusg · 2024-12-19T11:16:26Z

+ if (@errorReturnTrace()) |trace| {
+ std.debug.dumpStackTrace(trace.*);
+ }
+ std.time.sleep(5 * std.time.ns_per_s);


Magic sleep needs a comment

This part of the code is based on what @truemedian did. I'm not sure either so CC'ing them for some information.

Magic sleep here was a debugging aid to prevent the uefi firmware from clearing the screen before I could read the any output because once EfiMain returns it will go to the next boot loader. Not necessary at all, unless that window to eead the error is desired.

Ok, I likely will remove it and it'll be up to the program to do that if they want to.

linusg

I'll have to ask you to split this up even more - there are number of changes in here that need more discussion or simply won't be merged as-is. I think the allocator improvements should be their own PR, not touching anything unrelated.

The changes around threading are nonsensical - UEFI is by definition single threaded, so alwaysSingleThreaded() ought to be the function that gets modified, which in turn means the panic handler doesn't need a stub for std.Thread.getCurrentId().

RossComputerGuy · 2025-02-08T02:36:30Z

I'll have to ask you to split this up even more - there are number of changes in here that need more discussion or simply won't be merged as-is. I think the allocator improvements should be their own PR, not touching anything unrelated.

Will do

The changes around threading are nonsensical - UEFI is by definition single threaded, so alwaysSingleThreaded() ought to be the function that gets modified, which in turn means the panic handler doesn't need a stub for std.Thread.getCurrentId().

Welll, kinda. The UEFI PI spec does mention a way to do multiprocessing which in turn can lead to multithreading.

linusg · 2025-02-08T02:45:12Z

Welll, kinda. The UEFI PI spec does mention a way to do multiprocessing which in turn can lead to multithreading.

You don't even need to run code on another core for "threading", but from the standard library's point of view we always have a single thread. Preparing for a scenario that is unlikely to ever be useful and only creates the need for more stub code isn't desirable, let's start small :)

RossComputerGuy · 2025-02-08T04:33:39Z

I found out while slicing this PR that we actually do have to mock threading.

/home/ross/zig/lib/std/Thread.zig:558:9: error: Unsupported operating system uefi
@compileError("Unsupported operating system " ++ @tagName(native_os));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
getCurrentId: /home/ross/zig/lib/std/Thread.zig:533:27
getCurrentId: /home/ross/zig/lib/std/Thread.zig:354:29
lock: /home/ross/zig/lib/std/Thread/Mutex/Recursive.zig:50:54
lockStdErr: /home/ross/zig/lib/std/Progress.zig:545:22
lockStdErr: /home/ross/zig/lib/std/debug.zig:198:28
print__anon_1981: /home/ross/zig/lib/std/debug.zig:208:15
main: src/main.zig:7:20
EfiMain: /home/ross/zig/lib/std/start.zig:223:37
comptime: /home/ross/zig/lib/std/start.zig:75:58
start: /home/ross/zig/lib/std/std.zig:97:27
comptime: /home/ross/zig/lib/std/std.zig:168:9

RossComputerGuy · 2025-02-08T04:53:07Z

Ok, things are split up now. I went through and dropped changes which were not necessary to make this work:

$ zig init
$ zig build -Dtarget=$(uname -m)-uefi

RossComputerGuy · 2025-02-08T17:30:14Z

I think the allocator improvements should be their own PR, not touching anything unrelated.

Going to do this right now since the UEFI allocators fix PR got merged.

RossComputerGuy · 2025-02-08T17:38:53Z

Allocator stuff is now in #22818

Vexu · 2025-02-08T19:06:48Z

+ // rudimentary utf16 writer
+ var index: usize = 0;
+ var utf16: [256]u16 = undefined;
+ while (iter.nextCodepoint()) |rune| {


Probably better to avoid the term rune.

Is codepoint a better name?

Renamed to codepoint

codepoint is a good name, it is coming from nextCodepoint after all.

RossComputerGuy · 2025-02-10T05:18:19Z

Rebased

RossComputerGuy · 2025-04-10T07:13:38Z

Rebased

dotcarmen

lgtm on first glance, my primary concern is around the change to OpenMode. haven't otherwise read through the posix implementation details which i'll do soon

dotcarmen · 2025-07-14T14:23:39Z

+ .handle = blk: {
+ if (is_windows) break :blk windows.peb().ProcessParameters.hStdOutput;
+ if (is_uefi) break :blk .{ .simple_output = std.os.uefi.system_table.con_out.? };
+ break :blk posix.STDOUT_FILENO;
+ },


nitpicky but can you do this instead and below:
Suggested change
.handle=blk: {
if (is_windows) break :blkwindows.peb().ProcessParameters.hStdOutput;
if (is_uefi) break :blk .{ .simple_output=std.os.uefi.system_table.con_out.? };
break :blkposix.STDOUT_FILENO;
},
.handle=if (is_windows)
windows.peb().ProcessParameters.hStdOutput
elseif (is_uefi)
.{ .simple_output=std.os.uefi.system_table.con_out.? }
else
posix.STDOUT_FILENO,
it simplifies the control flow and is easier to read

dotcarmen · 2025-07-14T14:37:11Z

+fn unexpectedError(err: anyerror) error{Unexpected} {
+ std.log.err("unexpected error: {}\n", .{err});
+ return error.Unexpected;
+}


can you colocate this with std.os.uefi.unexpectedStatus and change the param to err: uefi.Error?

dotcarmen · 2025-07-14T14:43:16Z

- // 0x8000000000000000
- create: bool = false,
- };
+ pub const OpenMode = packed struct(u64) {


OpenMode only selects 3 options according to UEFI which is why it's an enum. why lift the bits struct?
alternatively you can make this enum open (_) and add toBits and fromBits methods. IMO that's preferred because it's a signal to the user "this is an unsupported value, you probably don't want this"

dotcarmen · 2025-07-14T15:00:54Z

+ const fd = p.open(path_buffer[0..len :0], .{
+ .read = true,
+ .write = flags.CREAT or flags.TRUNC or flags.ACCMODE != .RDONLY,
+ .create = flags.CREAT,
+ }, .{}) catch |err| switch (err) {


to avoid creating an invalid OpenMode you can do something like:
constopen_mode: OpenMode=if (flags.CREAT) mode: { if (!flags.TRUNCorflags.ACCMODE==.RDONLY) { // UEFI doesn't allow create without write flagsreturnerror.PermissionDenied; break :mode.read_write_create; } elseif (flags.TRUNCorflags.ACCMODE!=.RDONLY) .read_writeelse.read;

dotcarmen · 2025-07-14T15:46:41Z

so alwaysSingleThreaded() ought to be the function that gets modified, which in turn means the panic handler doesn't need a stub for std.Thread.getCurrentId().
do we need this stub still?

linusg · 2025-07-14T16:30:44Z

+ switch (@TypeOf(result)) {
+ void => return 0,
+ u8, usize => {
+ return result;
+ },
+ uefi.Status => {
+ return @intFromEnum(result);
+ },
+ else => @compileError(bad_efi_main_ret),
+ }


We're not reintroducing untyped u8/usize return values. Keep this as is and only touch the existing switch (err) {}.

linusg · 2025-07-14T16:36:37Z

Fundamentally opposed to this, anything that uses std.posix as a generic fallback impl should have a dedicated UEFI impl instead. std.posix's days are numbered anyway: #24329 (comment)

linusg · 2025-07-14T16:36:47Z

+ return path;
+}
+
+pub fn realpath(pathname: []const u8, out_buffer: *[PATH_MAX]u8) std.posix.RealPathError![]u8 {


andrewrk · 2025-07-14T17:08:27Z

Self-requesting a review to block this from landing until I take a look at it. I think this will likely need to be redone differently depending on how this Io interface shakes out.

andrewrk · 2025-11-27T02:51:29Z

This pull request is not ready for review because:

It has conflicts that must be resolved via rebasing against latest origin/master.

Since we have moved development to Codeberg, please open your pull request there if you would like to continue these efforts.

alexrp reviewed Dec 13, 2024
View reviewed changes

RossComputerGuy force-pushed the feat/uefi-zig-init branch from 87beafb to 2a2c072Compare December 13, 2024 23:02

linusg reviewed Dec 19, 2024
View reviewed changes

RossComputerGuy force-pushed the feat/uefi-zig-init branch 2 times, most recently from cb18f91 to 74b7013Compare December 19, 2024 19:09

RossComputerGuy force-pushed the feat/uefi-zig-init branch 2 times, most recently from 372c006 to ce7569cCompare February 7, 2025 22:57

This was referenced Feb 7, 2025
Several allocators in std no longer compile #22806
Closed
UEFI keeps regressing due to lack of CI build coverage #22809
Open
std.os.uefi: fix allocators compiling #22810
Merged

RossComputerGuy force-pushed the feat/uefi-zig-init branch from ce7569c to ce1a302Compare February 8, 2025 01:32

linusg requested changes Feb 8, 2025
View reviewed changes

RossComputerGuy force-pushed the feat/uefi-zig-init branch 2 times, most recently from 31ebae5 to 3d3cfa3Compare February 8, 2025 04:47

RossComputerGuy force-pushed the feat/uefi-zig-init branch from 9220214 to dad2aa7Compare February 8, 2025 17:29

RossComputerGuy force-pushed the feat/uefi-zig-init branch from dad2aa7 to 4e3e840Compare February 8, 2025 17:37

RossComputerGuy changed the title ~~std: implement basic io and improve alloc in uefi~~std: implement basic ioFeb 8, 2025

RossComputerGuy mentioned this pull request Feb 8, 2025
std: rework uefi allocators #22818
Open

Vexu reviewed Feb 8, 2025
View reviewed changes

RossComputerGuy force-pushed the feat/uefi-zig-init branch 2 times, most recently from a3461b7 to 5208154Compare February 10, 2025 05:15

andrewrk changed the title ~~std: implement basic io~~std: implement basic io for UEFIFeb 23, 2025

RossComputerGuy force-pushed the feat/uefi-zig-init branch from 5208154 to 451dc36Compare March 5, 2025 03:26

linusg mentioned this pull request Mar 13, 2025
std.os.uefi.protocol: ziggify function signatures #23214
Merged

RossComputerGuy force-pushed the feat/uefi-zig-init branch 2 times, most recently from 2ce0eb2 to 2234f1dCompare March 16, 2025 05:28

RossComputerGuy force-pushed the feat/uefi-zig-init branch from 2234f1d to d5c9358Compare April 10, 2025 07:13

RossComputerGuy mentioned this pull request Jul 12, 2025
std.os.uefi.tables: ziggify boot and runtime services #23441
Merged

RossComputerGuy added 10 commits July 12, 2025 21:14

std.start: handle errors with efi main
fe1a1b7

std.os.uefi.protocol.file: use packed struct for open mode
46fd94f

std.os.uefi: add posix compatibility layer
616c689

std.Thread: fake process id on uefi
ec369ba

std.fs.File: disable ansi on uefi
dc3f079

std.fs.File: add stdio for uefi
d60ed80

std.debug: add module lookup function prototype for uefi
14fdfe2

std.fs.Dir: no flock when not defined
50ffcd3

uefi: mark as always single threaded
ed3009a

lib/compiler/test_runner.zig: use simple tests on uefi
5d41a4f

RossComputerGuy force-pushed the feat/uefi-zig-init branch from d5c9358 to 5d41a4fCompare July 13, 2025 04:23

dotcarmen reviewed Jul 14, 2025
View reviewed changes

linusg reviewed Jul 14, 2025
View reviewed changes

andrewrk self-requested a review July 14, 2025 17:07

andrewrk closed this Nov 27, 2025

		@@ -1,5 +1,7 @@
		const std = @import("../std.zig");

		pub const posix = @import("uefi/posix.zig");

	pubfnalwaysSingleThreaded(target: std.Target) bool {
	_=target;
	returnfalse;
	}

	pubfndefaultSingleThreaded(target: std.Target) bool {
	switch (target.cpu.arch) {
	.wasm32, .wasm64=>returntrue,
	else=> {},
	}
	switch (target.os.tag) {
	.haiku=>returntrue,
	else=> {},
	}
	returnfalse;
	}

- .handle=blk: {
-if (is_windows) break :blkwindows.peb().ProcessParameters.hStdOutput;
-if (is_uefi) break :blk .{ .simple_output=std.os.uefi.system_table.con_out.? };
-break :blkposix.STDOUT_FILENO;
- },
+ .handle=if (is_windows)
+windows.peb().ProcessParameters.hStdOutput
+elseif (is_uefi)
+ .{ .simple_output=std.os.uefi.system_table.con_out.? }
+else
+posix.STDOUT_FILENO,

Uh oh!

Uh oh!

Conversation

RossComputerGuy commented Dec 13, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linusgDec 19, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linusg left a comment

Choose a reason for hiding this comment

Uh oh!

RossComputerGuy commented Feb 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linusg commented Feb 8, 2025

Uh oh!

RossComputerGuy commented Feb 8, 2025

Uh oh!

RossComputerGuy commented Feb 8, 2025

Uh oh!

RossComputerGuy commented Feb 8, 2025

Uh oh!

RossComputerGuy commented Feb 8, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RossComputerGuy commented Feb 10, 2025

Uh oh!

RossComputerGuy commented Apr 10, 2025

Uh oh!

dotcarmen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linusgDec 19, 2024•
edited
Loading

RossComputerGuy commented Feb 8, 2025•
edited
Loading