1. It can still trash various board level devices 2. Uh, what? How do you reset the firmware? (Answer: You reboot the PC) 3. This defeats the entire reason of writing firmware vars which is reconfiguring it and/or preserving data across boots
Exactly. Doing it as bytecode is the right way - it inherently invites the OS kernel to control access as it sees fit without a costly emulation/virtualization layer that incentivizes omitting it.
-
-
you could always put QEMU into kernel the best part is when you'll use this on ARM64 with an UEFI firmware that includes QEMU for talking to AMD64 option ROMs
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
You may be the first person I've encountered to describe ACPI byte code as 'how it should be'
-
Well no code at all would be preferable (documented mmio interfaces represented in device tree) but if you're going to have code, bytecode is the way to go.
-
Yeah, I was gonna say, isn’t it better to just have all hardware of a certain class work the same way?
-
Yes. USB device classes with standard protocols, no drivers at all, is how ALL hardware should work.
-
yessss, please lock the bad decisions of some shitty committee EVEN FURTHER into the stack
End of conversation
New conversation -
-
-
*bursts through the wall* Did someone say WebAssembly at ring 0? OH YEAH!
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.