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
