Singularity RDK

In the past 20 to 30 years nothing dramatic has changed to the base fundamentals of how an operating system works. Linux, Mac-OS, and Windows have all relied on what is called a monolithic kernel. Simply put these means you take all of your hardware and their drivers and stuff them in the same run space on your computer. If one driver goes nuts or a piece of hardware overheats… that all she wrote and the computer will crash. This has been seen as a “Blue Screen of Death” in the Microsoft world and as a “Kernel Panic” in Linux.

There is a different paradigm that has been tried before. It is called a Microkernel. The idea behind a microkernel is each driver and system service (such as the networking protocol stack) has its own run space. With the current thoughts of using unsafe and unmanaged code (assembly, C and C++) each of these parts needs to run in its own protected memory. This protected memory is a implementation in hardware that pretty much acts like a mother trying to prevent a child from getting to the cookie jar right before dinner. If you make a request to someone else’s memory space the hardware throws and exception and the kernel lets you know (smacks your hand). If you really need to access something in someone else space you have to ask the kernel to copy (marshal) the data for you. This comes with several downsides. The kernel needs to copy the memory from one memory space to another. It also needs to perform some magic in the hardware called context switching. Overall both of these actions are rather expensive.

What Microsoft Research has done with Singularity it to create a fully safe and managed operating system. They have provided a software protection that allows all application to safely run in the same address space. And using managed code had provided garbage collection and memory page management all in the same space as the user applications. This mandated by the fact that you cannot run unsafe, un-typed code outside of the kernel, simply put your program can only talk to other programs if it shares a channel (communication contact or interface) with another application. These channels build a standard form of communication that can be statically checked and verified at compile time and at runtime. They also provide a queuing process to allow for safe and clean recovery if a peer application fails. Keep in mind that system drivers are given this same level of protection. So if your video card or CPU overheats. The system would have the ability for pause everything and wait for the temperature to come back in range instead of causing a system panic that leads to a reboot, blue screen, or just locking up.

I am very impressed by this project and I can’t wait to see the outcomes. As a developer and engineer myself I cannot wait to see some of the principals learned by singularity show up in my person desktop.

-Matt