Hi everyone,
I found this mailing list through the NetBSD GSoC "Add UEFI boot options" project page, and I'm interested in taking on this work.
A bit about me: I'm an undergraduate student. I host my projects and participate in open-source communities on GitHub — feel free to check out my profile:
https://github.com/hanbingsBefore learning about "Add UEFI boot options," I participated in a project called "arceboot" through OSPP (Open Source Promotion Plan, a GSoC-like program organized by the Chinese Academy of Sciences). The main goal was to build a UEFI firmware from scratch (filling the same role as UEFI OVMF). The repository is at:
https://github.com/rustsbi/rustsbi. Through that work, I gained a solid understanding of the UEFI Spec, as well as the UEFI boot flow and its internal mechanisms. I've also been writing my own operating system kernel with a custom EFI bootloader:
https://github.com/hanbings/canicula, which has given me hands-on experience with the full chain from firmware to kernel.
Here is my understanding of the "Add UEFI boot options" project: the kernel has access to SetVariable() for setting EFI variables, but since sysinst is a userland tool, it cannot call this function directly. As a result, the UEFI firmware can only rely on scanning for EFI binaries at default paths with default names. To make this work, we would need to expose a userland interface and modify sysinst to use it. Linux achieves this by exposing filesystem nodes under /sys/firmware/efi/efivars. From my initial research, NetBSD might prefer exposing this under /dev/efivars, or possibly through something like sysctl hw.efi.vars. I'd love to hear your thoughts on the preferred approach. In the meantime, I'll continue studying NetBSD's design philosophy and digging into the sysinst source code.
Thanks,
hanbings