What did I learn? What are the main takeaways?

The concept of border crossing pops up over and over again. This is a new term I never heard of prior to this class.  The term is almost synonymous to a context switch but it is subtly different in the sense that a context switch (switch from one process to another or one thread to another) can occur without a border crossing, without changing the underlying hardware address space.

SPIN attempts to enforce protection at the compiler level, by using a restrictive language called Modula-3. Unlike the C language, where you can cast a pointer to whatever data structure you like, Modula-3 enforces type safety, only allowing the developer to cast a pointer to specific types of data structures that they had already specified earlier in the code.

SPIN offers extensibility by allowing different types of OS services to co-exist with one another.

But what are the trade offs with SPIN, when compared with Microkernel and Exokernel?

It appears that SPIN would be more performant than Microkernel due to no border crossings while maintaining flexibilty (multiple types of OS services that cater to application processes) and security (via logical protection domains) with Modula-3, allowing code OS services library code to co-locate with kernel code.

Introduction

Summary

SPIN and Exokernel take two different paths to achieving extensibility. These designs overcome the issue of Microkernel, which compromises in performance due to border crossings, and monolithic, which does not lend itself to extensibility

What we are shooting for in OS Structure

Summary

We want flexibility similar to a microkernel based approach but also want protection and performance of monolithic. We want the best of both worlds: performance protection flexibility

Approaches to Extensibility

Damn, this is a super long video (8 minutes, compared to the other one to two minute videos prior)

Capability based

Hydra OS (1981)

Summary

Hydra did not fully achieve its goal of extensibility

Micro Kernel Based

Summary

Performance took a back seat, since the focus was on extensibility and portability. Bad press for micro kernel based due to the twin goals.

SPIN approach to extensibility

Summary

By co locating the kernel and extension in the same hardware space, the extensions are cheap as procedure call. Doing this by depending on a strongly typed language to provide safety

Logical Protection Domains

Summary

Using a programing language called Modula3, which doesn’t appear to be popular in practice, we can enforce protection at the logical level. This programming language, unlike C, restricts casting pointers to random data structures, only allowing the cast to a particular data type.

Spin mechanisms for protection domains

Summary

The secret sauce of protection and performance are the mechanisms of creating (i.e. expose entry points), resolving (i.e. leverage other entry points), and combining of logical protection domains

Customized OS with Spin

Summary

There can be multiple file systems (written in Modula3), each file system catering to their callers, and each file system using the same underlying hardware address space. And they can share modules with one another, like the networking entry point.

Example Extensions

Summary

Example of Unix Servers implementing their OS on SPIN as well as a video server / display client building on top of spin

Quiz: Border Crossings

Summary

Microkernel and SPIN offer performance since they limit the border crossings. In SPIN, Logical domains do not require border crossings

SPIN Mechanisms for Events

Summary

To handle events (like packet arrival) we can have a 1:1 mapping, 1:N mapping or N:1 mapping. For 1:1, an example would be an ICMP packet arriving and the 1 ICMP handler running. In a 1:N mapping, the IP packet arrived event runs and signals three other event handlers like ICMP, UDP, or TCP. Then finally, there is a N:1, and an example of this is an Ethernet and ATM packet event arrives but both funnel into the IP handler

Default Core Services in SPIN

Summary

SPIN offers core services like memory management, CPU scheduling etc. And SPIN will provide a header file that OS programmers need to implement. Remember: these implementations talk to each other through well defined interfaces, offering protection, but are also performant cause there are no border crossings)

Default Core Services in SPIN (Continued)

Summary

Provides primitives, the interface function definition. The semantics are up to the extension itself. SPIN makes sure extensions get time on scheduler