Skip to content

Instantly share code, notes, and snippets.

@saltyJeff
Last active November 29, 2021 22:51
Show Gist options
  • Select an option

  • Save saltyJeff/34803e266d2bb38bab86d8f38fac407d to your computer and use it in GitHub Desktop.

Select an option

Save saltyJeff/34803e266d2bb38bab86d8f38fac407d to your computer and use it in GitHub Desktop.
a hypothetical OS design

saltyJeff's Hypothetical OS Design

Background

An OS kernel can be thought of many interacting hardware abstractions, or drivers. For example, an OS kernel has a timestamp driver that abstracts away the process of reading from a hardware clock, and a filesystem driver that communicates with the timestamp driver to accurately timestamp file modification times.

In a monolithic operating system, drivers are statically linked, so all interactions are just method calls. In a microkernel however, driver interactions look like this:

TODO: copy a example

Problem

Users are forced to make security decisions at OS-adoption time. If I have 100 drivers that I trust

We want to create an OS with drivers that look like they're monolithic, but can run microkernel style.

This is similar to the rump kernel, but we want the OS itself to reflect this goal, instead of having many user-mode drivers with their own copy of a rump kernel.

Solution Requirements

  • unified interface: drivers should be able to be compiled once, and either linked directly into the kernel or run in userspace
    • stable interface: drivers should be able to be compiled once, and run on any version of the underlying kernel
  • support blobs: vendors write drivers, and they hate sharing code.
    • support risky blobs: vendors may write dangerous drivers, so the user should be able to select which drivers run in userspace

Proposed Solution

My proposed solution is based around the concept of API is the ABI is the API. For statically linked

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment