OSDev.org

MessiahAndrw wrote:When I started this thread, I wasn't thinking about porting a browser environment (including HTML and WebGL) into your kernel. Instead, I was thinking about the possibility of using WebAssembly as your OS's bytecode format for distributing applications in.

At the very least, this would require implementing a WebAssembly VM/interpreter into your kernel, so you can run WebAssembly on bare metal.

A WebAssembly module is associated with a table of symbols it imports (your system calls) and exports (e.g. 'main', but you could have other entry points such as handlers). I'm fascinated with the idea of implementing the same set of the system calls in both a bare metal kernel, and inside of a web page. Then the same program, distributed in WebAssembly bytecode could run on both your kernel and in a browser, as long as they shared the same ABI.

I misunderstood. I had the idea of adapting the OS to run web app APIs natively (although not entirely in the kernel, not in browser either when run locally, and with additional extensions where necessary.) Your vision is to adapt the browser APIs by bridging with javascript code that emulates your OS execution environment.

MessiahAndrw wrote:I mentioned Canvases, not because I'd want to reimplement the Canvas spec in my bare metal kernel, but because web modern browsers provide a bitmaprenderer Canvas context, so you could display the pixels your low-level graphics API is pumping out. (The syscalls for a higher level graphics API could take advantage of hardware acceleration in the browser such as WebGL.)

This could work for some applications, although I don't think that a multimedia player with built-in codecs could be run this way. For this to happen, the browser must have really slick JIT that converts canvas buffer accesses into raw memory transfers to get reasonable performance. Not to mention the lack of YCbCr (to my knowledge.) On other hand, a player that relies on system codecs could run using html5 video.

MessiahAndrw wrote:I mentioned Web Workers, not because I'd want to reimplement Web Workers in my bare metal kernel, but because Web Workers would provide a way to implement multi-threading and process isolation inside the browser.

Do they offer means of communication and synchronization comparable to kernel threading?

MessiahAndrw wrote:You could implement your filesystem IO syscalls around IndexedDB inside of a browser.

You could use that, or WebDav, or cloud storage (although I think they are object based, not block based), but there will be limitations. For example, an image viewer will need to open image files. Would those come from the web?

MessiahAndrw wrote:Web Audio gives you an audio buffer you can write into.

Same as with the Canvas APIs, but with less performance impact. I can see how this could work for things like games, or uncompressed audio editors.

MessiahAndrw wrote:The dream for me is to be in a state where I have an app store, and I can share you a link to a program I wrote in C++, you can click "Run", and the program near-immediately runs inside of the browser, and the binary is identical to what you could download and run off a disk on my bare metal kernel.

This is not a bad marketing move, but it will emphasize the application, not the OS. To turn this into advantage, you will have to show superior application quality and availability compared to other OSes, or you would have demonstrated that the browser can run an application that the user already has on their desktop. On the other hand, I think that just making the relevant C and JS libraries might turn into a meaningful product in itself (OS aside), because software companies sometimes try to provide a taster of their application on their web page by rather primitive means. This will make their online demos realistic. You might then offer cloud storage integration and this will turn your infrastructure into a portability solution for applications that run standalone natively and as a web service. I know this is not what you have in mind, but just saying - there might be demand there.

Solar wrote:But aren't the services provided (and required of) a bare-metal OS and a webbrowser so distinct as to render the intersecting set non-existent?

I admit I don't know much about WebAssembly, or web programming in general.

But let's take the I/O as an example. I can't imagine a webbrowser allowing a WebAssembly free access to the file system. So you'd have to "mock up" the filesystem as your bare-metal OS sees and handles it inside the webbrowser. I have a hard time seeing the usefulness of e.g. a database application running inside a browser on top of a filesystem mock-up running on e.g. a database backend running on the filesystem the webbrowser is running on... you see what I mean? On the other hand, many of the things necessary on the OS level -- filesystem defrag, concurrency, multi-user handling etc. -- just don't apply to what is happening in the browser.

Its funny, I was originally going to agree with you - but then I looked up WASI and this insanity: Browsix. WASI looks like it kind of sort of partly covers syscalls and a libc implementation. But you're still right in that none of the OS services would be available. You could have your own WASI backend that mocks some of that (fake vfs etc), but from what I can tell its still up to the browser's choice on what backend to use (ie it'd use its own?).

The only way to have an identical binary in WASM that I can see is basically a Smalltalk/Lisp-esque image - ie the program *is* or is packaged *with* the OS. Or your OS's API has a layer that checks what WASM environment its running in and falls back to an alt path that emulates the same environment for browsers. Essentially shipping twice the libraries to maintain the identical binary goal.

Yes, if you wanted to launch the program by itself, it would need to be packaged with the OS.

I find it interesting that both platform-independent kernel code (e.g. a windowing system) and your userland code can be written in C++, compiled to separate WebAssembly modules, with their own isolated interfaces (e.g. you could run the main kernel module in the browser's UI thread, and userland modules in workers.)

Of course, you'd compile the kernel to machine code for your bare metal OS (and it'd need to include a WebAssembly interpreter.)

Hi,

@MessiahAndrw: using WASM as a distribution format for platform independent code makes a lot more sense than writing the entire OS in WebAssembly and running it inside a browser. It's not just perfectly viable, but it's much more sane than using python bytecode or java bytecode for example. (That's because python bytecode is not standardized, and java is way too tied to the language, you can't write a C++ compiler that outputs java bytecode without serious compromises. WASM on the other hand is a simple stackmachine and totally language agnostic.)

Just for the records, WASM has a very decent library import feature set, where the library can be written in any language, therefore it is easy to provide an "OS" layer for WASM bytecode. The aforementioned WASI intend to be something like that, but unfortunately it's not complete, it lacks many POSIX functions. Therefore if you want to distribute your applications in WASM, they must be dynamically linked with a run-time library for your OS (implemented as a native code in your kernel as part of the WASM VM).

WASM does not depend on browsers, that's a common misconception. It is true that most WASM VMs are implemented in browsers as of now, but that's just a circumstance to help spreading WASM. According to the spec, you don't need JavaScript either, you can use your OS' libraries to provide the same features (although you'll have to implement canvas natively on bare metal, there's no other way.) Note that JavaScript is only needed if a) you run WASM in a browser, b) you embed it into a HTML page, c) your WASM code is linked with functions that are implemented in JavaScript in the browser's WASM VM. It is pretty easy to avoid a) and b), and you could provide your own library for c).

Take a look at these examples:
- https://github.com/kanaka/wac a very minimal WASM MVP interpreter in C (with interactive prompt and WASI support too)
- https://github.com/WAVM/WAVM another browserless implementation, this one is a JIT compiler written in C++ (uses LLVM IR)

Both could be ported into a bare-metal kernel to provide WASM bytecode user space applications. But you have to implement your own WASM run-time library that the WASM bytecode can import, because there's no browser.

Cheers,
bzt

Plan 9 is very flexible in how the parts can be split; local vs. remote is not hard-coded. The default is to have only the files remote, but any other resource may also be remote. Only CPU & RAM are kept together.

Regarding the practicalities of Plan 9's implementation of this, the guy who particularly told me the latency situation is getting better lives and works between 730 and 870 km from his VPS, routinely connecting with Plan 9's version of remote desktop. Working with him, 9front's kernel dev removed compression of images sent to the remote desktop, finding it quite fast enough without compression. *shrug*

If and when high latency is a problem in Plan 9, it's possible to work around it, but the workaround isn't automatic. Only one program implements it. There have been several proposals for "streaming 9p" to correct this situation, but none appear to have been developed.

Even the network stack may be remote to any given program; a trivial tunnel. It results in tcp/tcp, which I've heard is a bad idea, but with a little work it's possible to bring back Plan 9's simpler alternative to tcp, il.