Sunday, October 09, 2005

Pedal to the Metal

Andrew Ducker made some interesting comments about my last entry, where I suggested that new silicon technologies would significantly change the role of the operating system. One thing I failed to mention was that I was positing some future version of the .Net CLR that would focus purely on computation, and on network connectivity. This would significantly simplify the task of writing a "raw metal" CLR. Yes, Microsoft would have the problem of maintaining two different CLRs - a server/middleware version and a client version - however, the architecture that Microsoft is driving towards through the various Windows Foundations wouldn't preclude such a move. In fact it would make it easier - leaving Microsoft with a componentised CLR that could be tailored for specific tasks. After all, not everything needs a UI, and the .Net CLR is part of a mature application server platform. A componentised CLR would also allow Microsoft to synchronise releases of the Compact Framework with the full .Net system. The Windows hypervisor would be able to manage multiple "raw" CLRs effectively, allowing system managers to get much more bang for the buck without the OS overhead. And perhaps then Microsoft backends could take advantage of intriguing new technologies like Azul Systems network attached processing.

1 Comments:

Anonymous Anonymous said...

None of this is particularly new -- IBM developed the virtual-machine OS in the early 1960's. UCSD Pascal was running a complete environment built on a portable byte-code interpreter back in the 1970's. And eCOS and TinyC provide the functions of an OS as a subroutine library running on bare metal. Squeak is a more recent example, and Sun is talking about running Java on bare metal as well. There are good reasons why these ideas never really took off.

Whether it runs on top of a virtual machine or a real one, or is just a collection of low-level subroutines called from libc, an OS provides a standardized interface to a richer virtual environment full of services like virtual memory management, networking, and file systems. On the other side (the side facing the bare metal), the OS presents a standardized interface to device drivers. Linux, eCOS, and the BSD's have proven again and again that an OS kernel and a complete set of drivers can be ported to any sufficiently-capable architecture using little more than a C compiler. They have also presented convincing evidence that a monolithic kernel running on bare metal is more efficient than a pile of tasks running on top of a hypervisor or microkernel.

10/09/2005 05:24:00 pm  

Post a Comment

<< Home