That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can. The executable file format redbean uses is a DOS Master Boot Record with a partition table, so it's technically a valid disk image you can `dd` too. If you're willing to trade away Windows support, then it can be an EFI image. The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack. Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs.
Recently, I took this approach to get proper ACPI S01x sleep on my Lenovo X1 Fold (a wonderful device BTW, once you take the time to work around Intel drivers bugs)
A battery discharge rate of 0.5%/h in sleep is just great... but I think I can do better: I'm now trying for 0.25%/h.
Imagine if you could immediately resume your foldable oled tablet, and it'd have only lost like 6% of the battery. With a 20% hibernate trigger, it would remain immediately available for over 3 days straight!
> That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can.
I love the spirit :)
> The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack.
Why? Is it for performance reasons or security reasons? (or both)
> Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs.
I'd suggest you "think different", and use instead something like ppp to create a TCP/IP stack over a serial link.
Modern btuart implementations already routinely achieve >1Mbps on commercial devices. The GSI as seen on the Intel Serial IO devices support bitrates over 20Mbps.
This could buy you time until you find a better solution, if it's ever needed (which I doubt as back of the envelope estimations make me believe you'll hit other limitations before)
It's less about perf/security and more to do with simply needing the time to wrap my head around how to do it. Entering ring0 is a whole different world. My productivity depends on a responsive TDD workflow and it's hard to test kernel code. I currently do it using an emulator I wrote called Blinkenlights, because the existing ones (Bochs and QEMU) couldn't be integrated into my Makefile / Emacs build system. So I not only need to build the kernel but I need to emulate the CPU features the kernel needs too.
> It'll be nice to know that any normal PC program we write will "just work" on Raspberry Pi and Apple ARM. All we have to do embed an ARM build of the emulator above within our x86 executables, and have them morph and re-exec appropriately, similar to how Cosmopolitan is already doing doing with qemu-x86_64, except that this wouldn't need to be installed beforehand. The tradeoff is that, if we do this, binaries will only be 10x smaller than Go's Hello World, instead of 100x smaller. The other tradeoff is the GCC Runtime Exception forbids code morphing, but I already took care of that for you, by rewriting the GNU runtimes.
> Probably related to #399. The recommended approach would be to use a full emulator like Bochs. It's not something we use at the moment so we can't provide support on this. Although we do intend to have APE support ARM at some point in the future.
