Microkernel Architecture 

In the second part of the seventies I designed a special purpose micro-kernel for 16 bits mini computers, comparable to the PDP11. We used the system from 1976 to 1990 in Air Traffic Control Systems and Sea Port Ship Tracking Systems. After 1990 the 16-bits minis were extinct. The requirements allowed a simplified design, since everything needed to be memory resident, no time to load programs or pages from disk. The ATC controller has no patience and the aircraft tracks keep coming hundreds per 5 or 10 seconds. The "job control" was run off line and the resulting system was one big boot-image. All program and OS code was read only and would restart from memory automatically after any crash. All data was initialized dynamically! The system was designed according to the leveling ideas of Dijkstra and information hiding principles of Parnas, the levels were: - Assembler and completely closed for interrupts and using physical memory, max size of a routine say 100 instructions 0. Memory management to load the correct page table. 1. Preemptive task scheduler with queue task for CPU, start highest priority task and save task status. 2a. Process synchronization by semaphores, if needed the master P-operation was send to slave processor on a 16-bit HW interface. 2b. Primitive IO, starting the IO operation and interrupt handling. 2c. Primitive date/time and timer handling. - High Level Language RTL/2 (C like), open for interrupts and running in its own address space. 3a. Message queuing with send message; locate message (instead of receive to avoid a move) and free message buffer all based on level 2a. 3b. Device handling and error handling based on level 2b and 2a. If needed disk-partition shadowing from master to slave. 3c. Date/time and timer handling to RTL/2 3d. Semaphores to RTL/2 4. Network queue selection for messages to other processors using level 3a. A Process was identified by CPU# and process# like 3,45. The default for the own CPU was 0 and 255 was broadcast. Master/slave setups used 3 CPU#, 2 for the physical CPU and 1 for the current master of the pair. - Operating system processes were all based on level 4 messaging and running in their own address space for: 5a. One or more network processes for HDLC/SDLC 5b. File manager 5c. Hardware error logging 5d. Program error logging 5e. Loading remote computers over the HDLC/SDLC network 5f. Logical name translation from e.g "multi-radar-tracking" to 5,110 or better 056E :) 5g. Operator communication. 5h. Time event management based on level 3c, managing "wake-up" and "time-out" messages. All major application processes received messages in a queue with 4 priority levels and did send the result to another queue somewhere in the network. The queue priorities were high prio; human inputs; streams and low prio. IO was done by small and simple IO processes. The nice thing was that with the strongly message based system, we could debug the computer on the radar heads with the debug function of the operator communication in the center, correct the source, rerun the compiler, linker and the off line job-control and reload the new boot image over the network. In principle we could record the output of any application process and replay it later. We had operational requirements to log all aircraft tracks and all operator inputs. In this environment it was not very difficult to implement. I think we did write the operational log to magnetic tape using a HDD partition of the 80 MB HDD as cache. The Times They Are A Changin' :)

Wikipedia says "The AmigaOS Exec kernel was an early example." I didn't think I'd seen it say it was the first. Also, MorphOS uses an L4 like microkernel, which makes me think of AmigaOS more of an exokernel.

Cool, thanks for the video. Very interesting information about kernels. I will be waiting for the next episode. P.S. Nice new glasses ;)

Nice, nice, and nice for sure, very good go back in time :) Well done DJ!

Thank you sir!

A Great explanation Indeed. Thank You.

Always fascinating to delve into the history of some of these technologies.

Thank you for your sharing, DJ. Happy to learn a new thing today!

Great vid, keep up the good work!

Love your video of micro kernel, can't wait for the next one on nano and pico, thanks

I am writing a tiny kernel for a few microcontrollers, like cortex-m and the tiny RISC-V mcu. I think I will go exokernel with an init process in user space that I will use as a shell to start other programs.

Many thanks! Very instructive. The arguments for a smaller kernel are compelling, but I guess (for me at least) one advantage of the monolithic Linux kernel is that I can run Fedora with the latest kernel more or less flawlessly from the regular ISO on a 10 year old mobile workstation. Which probably puts me in the small group that causes the bloat.

Thanks DJ. Please review Redox!

And answered my question on DKMS I had from last video (loadable kernel modules). Could you please go in depth to the Linux kernel. It's 30 years old so where are it's major areas of concern/problems? Is there a chance it gets replaced by a better kernel? what about RedoxOS? Or Fuchsia? It would be also a good follow up to the Fuchsia video! Awesome videos and in depth knowledge I really love this channel. I feel so glad I discovered this channel! Are you in any way connected to other RU-vidrs like Brodie/Luke or Podcasts like Linux Action News or Unplugged?

Where's the rest of the series?

Minix not mentioned?

This is the only sane OS design possible, in my opinion. Somehow, we ended up here, and I feel that as a consequence of that, many applications end up having to replicate the right design at the higher layers (see, for example, containers, docker, kubernetes).

Hi /g/

I think in the near future we are going to see less virtualization and runtime checking, and more static analysis tools like Rust's borrow checker. As well as more use of shared memory. Virtualization in particular needs to go away. I can't believe how Google with its billions of dollars isn't able to compile this website to run natively on every OS and architecture that's ever existed. We are starting to get rid of JavaScript but people are compiling to WebAssembly instead. Some day they will realize it is better to just compile down to machine code.

QNX was opened by QSSL back when they were going to be the core of the next amiga os, which never happened of course, but then blackberry closed the source again. I wish I'd kept the source, I don't know what happened to it.

You can't write a portable microkernel with multics multilayers, because not every CPU has multiple system levels like Intel does, most have two: user and kernel.

It's Brinch, not Binch.