4 ms·
You sound very knowledgable about UEFI - it is intimidating since the spec is so big. It also...concerns me that so much code is running prior to my own, even i
by javajosh 5y ago
You sound very knowledgable about UEFI - it is intimidating since the spec is so big. It also...concerns me that so much code is running prior to my own, even if it is for a good purpose. I get it that CPU mode selection and boot device intitialization isn't something most programmers want to deal with, but doesn't putting it in UEFI firmware put it out of reach of most programmers? Should we not aim to put as little as possible into firmware?
- a-priori 5y agoFirst off I don't recommend implementing the specification from scratch. It is big, and there are implementations already in various languages: for C you can use GNU-UEFI, for example, Rust has uefi-rs, and Zig has support in its standard library. These take care of the fiddly details of interacting with the UEFI firmware's services. There's tutorial type articles for these around: for C there's https://wiki.osdev.org/UEFI_App_Bare_Bones https://wiki.osdev.org/UEFI_App_Bare_Bones, for Rust there's this template https://github.com/rust-osdev/uefi-rs/tree/main/template https://github.com/rust-osdev/uefi-rs/tree/main/template and the crate's documentation. I don't think the role of firmware requires it to be minimal. It's to provide a consistent boot environment on different hardware, and to provide useful services to the program. Even BIOS-based machines have significant amounts of code that run before they jump to the boot sector, so while UEFI is definitely more sophisticated I don't really see this as a drawback to it.
- glouwbug 5y agoIf you're worried about pre-OS code you will not believe what is running when your OS is running