WoofƆs

WoofƆs intends to be my playground for personal long-term project of writing a micro-kernel operating system. It will be targeted at a beagleboard.

It is a micro-kernel architecture which copies some ideas from Minix3 and AmigaOS.

This is just a brain-dump of the ideas so far.

High level plans

• Very small microkernel which performs context switching, implements a small number of IPC primitives and interrupt management.
• Kernel will not be interruptible, unless it turns out it needs to be. To that aim all function will have upper-bound processing worst-case; or get moved out of the kernel.
• Memory server is separate high-priority process that executes in system space and manages both MMU tables and dynamic in-kernel objects.

Microkernel

• Very small API, very small implementation.
• Minimal IPC - non-copying message passing and signals. Perhaps mailboxes. Perhaps event buses.
• Redirect interrupts through use of IPC mechanisms.
• Context switching. Support for threads within processes.
• Might support process-level pre-emption for signal reception.
• Hoping to avoid need for re-entrancy.
• Privileged access to certain functions for system servers.

Memory Server

• Privileged process.
• Executes in system memory space.
• Manages process page tables.
• ?Manages kernel memory for dynamic objects?
• Communicates using base kernel IPC mechanisms.

Process Server

• Image/ELF loader
• Prepares ready-made page tables and process headers for memory server/kernel
• Manages process lifecycle.
• Has privileged access to memory server and kernel.
• ?Perhaps proxies user-process memory management to check capabilities? e.g. mapping i/o region.

Device Drivers

• Ordinary user processes
• Standard 'i/o requests' - messages with common format. open, read, write, etc.
• Memory mapped I/O? Or kernel controlled port access?
• IO requests are just messages.
• Allows secure direct-access to requesting "process's memory".
• Possibly allow multiple operations per request.
• Do they go through filesystem namespace?
• Then need to implement VFS interface too ...
• API is similar mind you.
• Could perhaps be an additional 'interface' at code level.
• Also require additional namespace redirection.

Filesystems

Way way off ... Haven't thought about this before, so these ideas aren't very refined.

• Ordinary user processes.
• Standard 'dos requests' - messages with common format.
• VFS? Well `VFS' is really in the common message format, no need for central bottleneck.
• Mapping filesystems to filesystem process/ports?
• Namespace management?
• Translators?
• Device drivers?
• Mount points/table.
• Buffer cache and interaction with paging?

Paging server

Haven't thought about this before, so these ideas aren't very refined. I don't see this as being a priority for a very long time, if ever.

• Long way off - not much use without block devices.
• Not sure it's really needed these days or especially on future hardware.
• Probably need to run as privileged server (or maybe not - use memory server for that).
• Does it need access to physical ram addresses?
• How to redirect page i/o to device driver
• Pre-allocated messages not going to work.
• Copying out of the question.
• Perhaps special i/o requests for physical memory instead - move problem to device driver.
• Wonder who directs it what to do? Memory server and perhaps process server.

IPC

Ideally just have one IPC mechanism used everywhere, but each has trade-offs.

Messages

The primary IPC mechanism will be message passing via message ports.

• Implemented using protected memory.
• Uses dedicated system-global address space simplifies code.
• Non-copying.
• Non-blocking.
• Minimum message size one page (4K)
• Uses signals for notification and sleeping.
• Messages, ports pre-allocated before use - minimal checks then required in kernel.
• Kernel only passes messages, it never creates them!
• Additionally it only remaps the message memory - process-level code manages queues. Even fewer checks required in kernel space.
• Kernel never needs to access process memory itself.
• Could be used for interrupts, but only in a pull/poll mode.
• Ports per-process or per-thread?
• ?Should message be separate from standard message header?
• Requires more information to be retained in kernel and passed to receiver (message, length, replyport).
• Allows page-aligned buffers, particularly nice for i/o.
• But this might not be any use - IO requests need additional header info anyway, could just use 2 pages to do the same thing.

Signals

• Interrupt-like set-once and notify mechanism.
• Can be slept on - with multiple sources.
• ?Could also allow process to be interrupted?
• Probably mechanism used to redirect interrupts to device drivers - if they don't need to count specific interrupts.
• Kernel able to create signals.
• Signals per-thread or per-process?

Mailboxes

• For passing very small amounts of data into fixed-length queues.
• May be more efficient than message passing and more flexible than signals.
• May not be worth it if the difference isn't significant.
• Alternative possibility for interrupt redirection - support multiple interrupts before processing.
• Kernel able to create mailbox entries.

Event bus

Probably just user-level system process. Can just use message ports and messages. Push or pull model possible. Should be re-usable for both system and user events of all types. e.g. 'mouse moved' to 'process died' to 'sd card removed', etc.

Also some overlap with interrupt mechanisms, but probably do that separately for efficiency.

Heterogeneous Processing

Way way off. I wont be at all surprised if I never get anywhere near this idea ...

But basically run a similar microkernel on the DSP processor, and somehow implement interchangeable message passing across both processors. Ideally through exactly the same API. If the microkernel remains small this could help here.

The DSP could then become a first-class peer to the main processor and both send and receive messages to/from the ARM cpu and not require some sort of proxy server for implementing i/o for example.

e.g. the DSP could open the 'audio.device' directly since for the most part it just amounts to passing messages around. Or files, or anything else.