Interest in GSoC project: Add UEFI boot options

hanbings <[email protected]> Sat, 28 Feb 2026 15:41:06 +0800
Newsgroups	gmane.os.netbsd.devel.installation
Message-ID	<[email protected]>
------=_Part_2201265_1523380196.1772264466632
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,



I found this mailing list through the NetBSD GSoC "Add UEFI boot options" p=
roject page, and I'm interested in taking on this work.



A bit about me: I'm an undergraduate student. I host my projects and partic=
ipate in open-source communities on GitHub =E2=80=94 feel free to check out=
 my profile: https://github.com/hanbings=20

Before learning about "Add UEFI boot options," I participated in a project =
called "arceboot" through OSPP (Open Source Promotion Plan, a GSoC-like pro=
gram organized by the Chinese Academy of Sciences). The main goal was to bu=
ild 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 fl=
ow and its internal mechanisms. I've also been writing my own operating sys=
tem kernel with a custom EFI bootloader: https://github.com/hanbings/canicu=
la , which has given me hands-on experience with the full chain from firmwa=
re 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 i=
s 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 w=
ith default names. To make this work, we would need to expose a userland in=
terface and modify sysinst to use it. Linux achieves this by exposing files=
ystem nodes under /sys/firmware/efi/efivars. From my initial research, NetB=
SD might prefer exposing this under /dev/efivars, or possibly through somet=
hing like sysctl hw.efi.vars. I'd love to hear your thoughts on the preferr=
ed approach. In the meantime, I'll continue studying NetBSD's design philos=
ophy and digging into the sysinst source code.



Thanks,

hanbings
------=_Part_2201265_1523380196.1772264466632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>=
<meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h=
ead><body ><div style=3D"font-family: Verdana, Arial, Helvetica, sans-serif=
; font-size: 10pt;"><div>Hi everyone,<br></div><div><br></div><div>I found =
this mailing list through the NetBSD GSoC "Add UEFI boot options" project p=
age, and I'm interested in taking on this work.<br></div><div><br></div><di=
v>A bit about me: I'm an undergraduate student. I host my projects and part=
icipate in open-source communities on GitHub =E2=80=94 feel free to check o=
ut my profile: <a target=3D"_blank" href=3D"https://github.com/hanbings">ht=
tps://github.com/hanbings</a><br></div><div>Before 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 A=
cademy of Sciences). The main goal was to build a UEFI firmware from scratc=
h (filling the same role as UEFI OVMF). The repository is at: <a target=3D"=
_blank" href=3D"https://github.com/rustsbi/rustsbi">https://github.com/rust=
sbi/rustsbi</a>. Through that work, I gained a solid understanding of the U=
EFI Spec, as well as the UEFI boot flow and its internal mechanisms. I've a=
lso been writing my own operating system kernel with a custom EFI bootloade=
r: <a target=3D"_blank" href=3D"https://github.com/hanbings/canicula">https=
://github.com/hanbings/canicula</a>, which has given me hands-on experience=
 with the full chain from firmware to kernel.<br></div><div><br></div><div>=
Here is my understanding of the "Add UEFI boot options" project: the kernel=
 has access to SetVariable() for setting EFI variables, but since sysinst i=
s 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 w=
ith default names. To make this work, we would need to expose a userland in=
terface and modify sysinst to use it. Linux achieves this by exposing files=
ystem nodes under /sys/firmware/efi/efivars. From my initial research, NetB=
SD might prefer exposing this under /dev/efivars, or possibly through somet=
hing like sysctl hw.efi.vars. I'd love to hear your thoughts on the preferr=
ed approach. In the meantime, I'll continue studying NetBSD's design philos=
ophy and digging into the sysinst source code.<br></div><div><br></div><div=
>Thanks,<br></div><div>hanbings<br></div></div><br></body></html>
------=_Part_2201265_1523380196.1772264466632--