Today's plan

• design issues
• monolithic kernels
• microkernels
• Mach 3.0
• exokernel
• virtual machines

Design Issues

• each operating system must define a set of interfaces:
  • to application programs: the operating system API
  • to device drivers: the driver API
  • to users: the user interface
• operating system APIs are usually a superset of some pre-existing, standard API, including Posix
• a good device driver API makes it easy to add new device drivers
• most operating systems have at least a minimal user interface, and must support, e.g. ttys (and serial ports), bitmapped devices, sound cards, etc.

Architecture: Design of the Implementation

• with a given set of APIs, there is still much flexibility in how to implement the system
• for example, Minix is structured as a microkernel with a file server, memory management server, and internet server
• for a different example, Linux has much internal structure, but is a single process, so all kernel global variables are available to all parts of the kernel
• some of the concerns include:
  • maintainability: is the design easy to modify and adapt?
  • performance: how long does it take to perform basic operations, e.g. a system call that doesn't do much?
  • security and correctness: do some architectures provide more security, or make it easier to avoid or find bugs, than others?
• maintainability include flexibility and generality: is it easy to make the OS do things it wasn't specifically designed to do?
• I'm not sure the security question has been answered

Monolithic Kernels

• most operating systems are built as monolithic kernels -- the entire OS is a single, perhaps multithreaded program (single process)
• monolithic kernels generally have fewer context switches than other architectures, and therefore tend to be faster
• monolithic kernels also have fewer boundaries than other architectures, which can help performance but hurt correctness and maintainability (changing one part can affect all the rest of the system)
• in favor of monolithic kernels is the argument that many microkernels are not really that small
• monolithic kernels are also arguably simpler, since they have fewer interfaces

Microkernels

• a microkernel OS is made up of several processes, each with a separate address space (though the kernel can of course look into all processes' memory)
• the microkernel itself is designed to be as simple and efficient as possible, usually doing not much more than message passing and perhaps memory management
• examples: Minix, Amoeba, Mach 3.0
• microkernels may sacrifice some performance for greater maintainability, perhaps better correctness
• but does anybody really care about OS performance? e.g. some very popular commercial OSs are alleged to have terrible performance
• a microkernel certainly makes the system easier to understand, since it enforces modularity: a microkernel system MUST be modular, a monolithic kernel may be modular

Mach 3.0

• microkernel system
• unlike minix, supported paging
• paging was done by a separate server (similar to the Minix MM)
• the "Unix server" supported the Unix system calls

Exokernel

• trying to make the microkernel as small as possible
• exokernel should:
  • provide security by doing minimal access control for devices, memory, etc
  • provide minimal scheduling of user-level processes
• most of the operating system, including most of the device drivers, should be in user space
• purely experimental system, but interesting ideas

Virtual Machines

• the API provided by the operating system should be identical to the API provided by the machine
• therefore, a single hardware machine (with enough memory or disk space) should be able to handle any number of "operating systems" running in its user space(s)
• for example, if a user program does a system call, this is a machine trap, which transfers control to the VM, which transfers control right back to the "operating system" corresponding to that user program
• same for page faults, hardware accesses by the "OS" (which are illegal, therefore transfer control to the VM, which can do the operation, and transfer control back)
• initially, IBM VM operating system (still available)
• for PCs, VMware or Plex86

Other Architectures

• multithreaded kernels may be monolithic or microkernel based, but in any case allow multiple threads to be active in a process at any given time
• multithreaded kernels must allow multiple kernel stacks (where does the hardware interrupt stack live?), and must provide synchronization for access to global variables
• multithreaded kernels must be very leery of deadlock or of any piece of code failing to release a lock
• embedded operating systems may not provide any security or memory management
• embedded operating systems may provide little more than a library to access devices, and perhaps support for handling interrupts
• in an embedded OS, only the functionality needed is linked in