Change already defined enums

Hello all,

after getting my bootloader compiling and fixing the damn integer overflow, I got everything relatively far. Now there is another error, but that error is also in the example I translated to ZIG.
The error I am talking about is std.os.uefi.Status.NotFound. It occurs to me when I try to allocate memory to a physical address. This error is not fixed in https://github.com/ajxs/uefi-elf-bootloader, and as I learn by examples (and the github repo was the simplest), I can’t solve this problem.
However, I explored some projects on https://wiki.osdev.org/Projects because there must be something that’s working and found https://github.com/brutal-org/brutal. In this repo, a working bootloader is included, so I looked into the source and found an interesting memory type in sources/loader/memory.c:14, which turned out to be 0x80000ff0 according to sources/libs/hw/efi/srvs/bs.h:44.
Now my question: How can I change the ZIG enum std.os.uefi.tables.MemoryType to support a memory type like “UserKernelMemory” without editing its source (lib/zig/std/os/uefi/tables/boot_services.zig:205)? Using @enumFromInt does not work, according to the language reference.

Looking forwards,
Samuel Fiedler

1 Like

It isn’t possible to change the defined values of an enum without modifying the source code. However, in this case, MemoryType is a non-exhaustive enum, identified by the trailing _ member. What this means is that the enum may have any value of the corresponding tag type (in this case, u32), not just the values defined in the enum fields.

So, while you can’t add additional fields to the enum, it is completely legal to do const UserKernelMemory: std.os.uefi.tables.MemoryType = @enumFromInt(0x80000ff0); because MemoryType is non-exhaustive.

5 Likes