Clone this wiki locally
I've been thinking about the design of an OS for a while now, I've kind of known what I wanted to achieve, but not exactly sure how to go about it. I've already decided TAMP is to be a microkernel rather than a monolith.
TAMP should only provide the necessary abstractions to implement an OS, it will implement the following:
The spaces provide a container for a running application, i.e. it is a container for thread's, code, BSS, data sections from a application binary, stacks, heap, capabilities, etc.
A thread is an executable unit, a space can have many threads executing at any one time. Each thread has it's own stack.
A key (or capability) addresses an object within the OS, e.g. on creating a thread, the OS returns a key to this thread to the running application. and this will determine what an application can do with the thread.
Pages are the unit of memory within an OS. We need to be able to map and unmap them from process to process.
We need to be able to synchronise threads with other threads, possibly in an external space, so that they can access the same memory pages at the same time without interfering with one another.
OS Personality libraries
A user-space library (or OS personality) can sit on top of TAMP and implement the higher-level abstraction it needs. e.g. a Process will encompass a container, x threads, stack, data, code and BSS segments, y keys, etc.
Like L4, Amoeba and other similar microkernels, a number of user-space servers will need to be implemented to create a usable OS.
An external memory server needs to provide a number of services, it needs to be able to map pages into a space when it's running code asks for them. If the kernel needs more pages, it must be able to map them back into the kernel (unlike L4's design which cannot give back pages to the kernel).
A scheduler can implement any number of algorithms, but it's purpose is to see what applications are running and to switch the currently running application with another.
One process may be running (this is not the scheduler!), so how can the scheduler be switched to run to switch from the running process to another (again, not the scheduler)? The kernel must intervene somehow?
TAMP should be usable in a number of different forms, i.e. from a flash based MCU board, like the STM32F4DISCOVERY or PIC32 boards to a full workstation configuration working from disk.
Obviously, in an embedded environment, TAMP may only have the kernel, memory and scheduler servers, a number of drivers and a few applications running.
- There may be no need for ethernet access, but may need CAN instead.
- A simple UI may be needed for output to an LCD.
On a workstation, there may be many different applications running any one time as well as the basics mentioned above, a full UI, disks, swap space, USB drivers, ethernet with full TCP/IP stack, keyboard, tablet, mouse inputs, etc.
A workstation setup is more complex, but TAMP should be capable.