Joys of Porting a Kernel to WebAssembly
medium.com
medium.com
Phew. I was worried it might take him a decade or two. Here I am 3.5 decades in, and I'm still an imperfect programmer. Clearly, I just suck.
More seriously ... can someone explain the point of this? Why would you want to implement "a kernel" in WebAssembly? The browser (JS) environment already more or less defines a virtual machine already ... why would you overlay that abstraction with yet another semantically very similar abstraction? If you want to play with "kernel" concepts, why would you do this inside a browser rather than on an actual machine (or even a host-supported VM) ?
According to RMS, a hacker is "someone who enjoys playful cleverness, especially in programming but other media are also possible."
This seems to me a perfect example of the Hacker ethos. There isn't a real point (that I see) except to have some fun. For the record, I have daydreamed of porting a kernel to WebAssembly, however, I have not (yet) "perfected my skills as a programmer".
I don't think there needs to be a "point" to all programming projects for everybody.
What I really meant was: what can you learn by doing this? If the goals are as they are stated in the doc, what's the motivation for trying in a browser context? TFA doesn't say "I was just feeling playful", it lays out some goals and some rationale for them. I just don't understand why, given those goals, you would try to do this in a browswer. Screwing around with kernels is fun, because of all the stuff that can happen (and that you can learn). I'm having a hard time seeing how this would be the case here. I'm probably just blind.
The author's bio says "Writes kernels for fun", so that may be the primary motivation.
> The browser (JS) environment already more or less defines a virtual machine already ... why would you overlay that abstraction with yet another semantically very similar abstraction?
I had assumed that a possible motivation may have been to use WebAssembly in a non-browser hosted environment but that doesn't seem to be a specific motivation in this situation--but it could be in another situation.
> If you want to play with "kernel" concepts, why would you do this inside a browser rather than on an actual machine (or even a host-supported VM)?
I think the key motivation in this situation is explained in this quote from the "VI. The need for code compatibility between freestanding and hosted environments" section:
> As such we can make up for the shortcoming of the freestanding environment by making the code as much platform-independent as possible. This allows for a rigorous stress-testing and debugging of shared code via standardised, powerful and robust tools in the hosted environment, and safe deployment of this verified code on freestanding platforms.
So, in brief, this seems partially motivated by the fact that portability of code improves its debug-ability due to the ability to run it in an easily instrumented environment in addition to the original standalone environment.
And partially motivated by portability being a function of both runtime environment and compilation toolchain--the latter which seems to have been a factor here with lack of custom section support in the object format.
Thus, rather than being a desire to "play with 'kernel' concepts" in a browser, this seems motivated by improving portability of existing code written to play with kernel concepts in a more standalone environment.
The next logical step would be whether the kernel itself can be written in web assembly.
Because webassembly has all the problems (very old) physical hardware has. No multithreading, but a kernel can cheat that out (by rewriting user space programs or interpreting them). Cooperative multithreading is a central component of virtually every webassembly program (ie. we're at win3.1 level). There's uses for drivers, dynamic libraries, permissions, ... all of these concepts have uses it seems to me very similar to what you need on real hardware.