Linked by Hadrien Grasland on Sun 20th Feb 2011 13:20 UTC
OSNews, Generic OSes Now that you have an idea of where your OS project is heading as a whole, it's time to go into specifics. The first component of your OS which you'll have to design, if you're building it from the ground up, is its kernel, so this article aims at being a quick guide to kernel design, describing the major areas which you'll have to think about and guiding you to places where you can find more information on the subject.
Thread beginning with comment 463811
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: VM Based Kernel
by alexisread on Thu 24th Feb 2011 11:01 UTC in reply to "VM Based Kernel"
Member since:

I don't think the type safe language would imply any overhead overhead over a correctly implemented unsafe-language version. All we require are safe language constructs which map efficiently over top of the underlying hardware like (memory mapped devices, port IO, DMA).

JNode and SqeakNOS are practical examples of VM based kernels - esp. check out Squeak and it's associated OS branch squeakNOS. It looks like development has stalled again, so it's missing COG integration (JIT compiler) and the latest I/O libraries, and the optimisation is pretty non-existant at this stage. It does run reasonably quickly however.

As per the argument put forward by the Phantom OS team, you should be able to (long term) optimise this sort of OS better than a monolithic kernel thanks to zero context switching.

"A VM running on top of bare hardware will be harder to write, and thus more buggy and exploitable, than a VM running in the user space of an operating system." This depends on how deeply integrated Java/Mono are with external dependencies (such as pthreads, or libc, or syscalls). Since I don't know the answer, I'll let the criticism stand. "Currently, the Java Virtual Machine is one of the biggest sources of vulnerabilities in existence on desktop PCs." Citation? Also, remember that, unlike a web browser sandbox, the kernel/VM isn't required to protect from maliciously altered kernel modules (untrusted code). It only needs to ensure that modules written in type safe code remain isolated. As long as the compiler only produces in-spec modules, then we can reasonably get away with a VM which produces undefined results for out-of-spec modules.

In addition, the VM would take away a whole class of bugs in user-level code eg. buffer overrun bugs in flash plugins. OS-wide I think you'd have a net gain and any VM bugs would show themselves quickly (and get fixed for an open source project anyway).

Features I thought about for my OS many years ago: It would be very nice to have support for clusters within the OS, such that you could take any running application and migrate it to another node while continuing to run. Similar to what VMware/KVM/Xen do, but would work with arbitrary applications. Every single kernel interface should have the ability to be virtualized such that all interfaces on PC-A could be transparently redirected/aliased on PC-B without explicit support for this within the drivers. PC-A: soundblaster, webcam PC-B: remote alias to peripheral devices from PC-A This would go hand in hand to make the application migration feature seamless. This also means that all local applications could bind to remote devices transparently without being explicitly written to do so. Other thoughts: I hope you're not planning on copying the *nix signal model, it's pretty bad for modern requirements. I also hope you opt for an asynchronous IO design within the kernel over a threaded IO design. This has been one of the weaknesses plaguing linux for years.

Checkout the Spoon image - it can do this and much more (versioning is handled well), major update due in March!

Reply Parent Score: 1