linux

At least for certain types of OSes, it should be relatively easy to get most of Linux's hardware support by porting LKL (https://github.com/lkl/linux) and adding appropriate hooks to access hardware. Of course, your custom kernel will still have to have some of its own code to support core platform/chipset devices, but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers). Also, it probably wouldn't work so well for typical monolithic kernels, but it should work decently on something that has user-mode driver support.

Rather than the "easy" way of porting an x86 emulator to WASM, I've been trying to natively port the Linux kernel to WASM. UML[0] and LKL[1] prove that running the kernel in a process is viable. μClinux efforts like NOMMU and binfmt_flat prove that you don't need memory-management nor ELF to run the kernel. Both my own independent experiments and WALI[2] have shown it's possible to port the Linux syscall interface and userland ecosystem to WASM. I'm confident it's doable, but there are a number of other challenges to solve along the way (like dynamic linking, the Harvard architecture, etc). Currently I'm blocked on the fact that while the kernel supports running non-ELF binaries, it really wants to be an ELF itself. [0]: https://en.wikipedia.org/wiki/User-mode_Linux [1]: https://github.com/lkl/linux [2]: https://arxiv.org/abs/2312.03858

Okay, so of interest but maybe not applicable to my usecase. Thanks:) Yeah, it remains to be seen how complex the actual format/code is. Would need to balance the difficulty of recreating it (which I assume to be quite high) against difficulty of extracting kernel code... although https://github.com/lkl/linux exists so for all I know maybe it's easy¯\_(ツ)_/¯ And yes, if I needed to actually write a "tar2ext4" tool today - like, start working in the morning and have it done by EOD - I would absolutely use... actually probably a loopback device rather than a true ramdisk, but yeah. But that requires root access and fiddling with loopback config, which seems excessive for what is, ultimately, just another archive format (from a certain point of view). And honestly some of it is just that it sounds fun to get my hands dirty with filesystem co

the most crazy LD_PRELOAD was using 4.X kernel on a centos6 machine with LKL https://github.com/lkl/linux There are tons of extremely OpenVZ hostings on the interweb but with an ancient 2.6 kernel like centos5. With LKL you can enjoy the benefits of modern kernel with minimal performance penalty. Submitted an issue here: https://github.com/gaul/awesome-ld-preload/issues/1

How does this differ from LKL (the Linux kernel library : https://github.com/lkl/linux )?

Linux kernel as a Library (LKL)[0] uses nommu mode. I think mostly just because it was easier to get working fast than trying to emulate an MMU. They've attempted to upstream a patch to XFS to work in nommu mode[1], but met some resistance from some XFS developers. [0]: https://github.com/lkl/linux [1]: https://lkml.org/lkml/2015/11/17/862