Linux has MILLIONS of lines of code. Please don't.
EFI is already bloated as it is.
Support efforts like coreboot instead. And FFS, firmware should not persist once the operating system boots. Persistent firmware is cancer.
Support efforts like coreboot instead. And FFS, firmware should not persist once the operating system boots. Persistent firmware is cancer.
Well, if you're going to run Linux anyway, running Linux as your firmware + bootloader doesn't increase your attack surface. And, it can be argued that e.g. the Linux networking stack is more battle tested than the UEFI one.
> Support efforts like coreboot instead.
Ron Minnich is the father of coreboot. If it were possible to run coreboot on modern Intel server platforms, I'm certain that's what he would propose. As a sibling commenter mentioned, he views NERF as a backup solution if using coreboot isn't possible.
> And FFS, firmware should not persist once the operating system boots. Persistent firmware is cancer.
In NERF, the Linux kernel burned on the flash rom kexec()'s the final distro kernel. IOW, it replaces itself by the new kernel, it doesn't linger around in the background.
I know some people like being retro with old ThinkPads but 12 year old servers are a bit much.
Also, Linux in firmware is either the final OS, or - more likely - a kexec step into the actual OS. In the latter case, there's no persistent firmware since the old Linux is gone.
Generally I agree with you, however there is one thing that cannot be done without a RAM-persisted firmware: any kind of power management. It's highly dependant on the specific chips (sometimes, chip revisions) on the motherboard, and while integrating even ultra low level stuff into the Linux kernel might help there, we see the consequences of doing so in the Android world: manufacturers do not have the time/money to get their code in a shape that's going to be accepted by the kernel community, so they fork it and the users are screwed.
It's not just a simple flag - it's basic stuff like for example which clock pin is mapped to which clock consumer(s), which GPIOs on which pins are mapped to stuff like LEDs, the power/reset switch, which hardware interrupt line is mapped to which GPIO... all stuff that's best kept inside the BIOS where the manufacturer can easily patch it if needed in contrast to the Linux kernel with its notorious difficulty to get stuff accepted into mainline, much less into a kernel that actually runs on users' computers - think LTS users, for example. I can take a 2010 kernel and it will likely run fine on a recent x86 machine, but if I needed to wait for motherboard support to ship in kernel, that would be not very cool.
Yes, something like FDT would be nice but even on the relatively small ARM space it has its fair share of issues - I don't even want to think about having FDT in mainstream x86.
Either do it in the OS, or do it in a separate CPU, such as a microcontroller.
The big difference is Go on one side, and a small selection of config files to support a small/growing collection of hardware on the other.
Is this guy looking to use the existing kernel code, as coreboot does? Or is he going to add to it, to make the One Kernel to Rule Them Allz? Because Im hearing the former, not the latter. I could be wrong.