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.
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' :)
Nice Bert, yeah the times are changing, amazing how much processing power you could squeak out of that ancient hardware. I remember seeing PDP-11's used for a lot of different tasks, we used them as Peripheral Processor Units (PPUs) off the CDC 6400 machine as well as a few PDP-8's for the less intensive I/O channels.
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.
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 RUclipsrs like Brodie/Luke or Podcasts like Linux Action News or Unplugged?
HI Markus, thank you for the kind comments. I have several videos on the future of linux where I talk about some of the areas I see that really need improvement. RedoxOS is another interesting OS, and I have a video talking about Fuchsia and will be updating it as things progress with it. Am I affiliated with other Linux RUclipsrs, not at the moment, I started the channel a few years ago as a way to give something back to the community. Might consider something like that down the road though.
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).
Macrokernals became popular because of speed. OS/2 was a really good microkernal and it's a shame that IBM ditched it. It's not a microkernel OS but Qubes is a good one to look at in the sense of compartmentalising processes in virtual machines. It's useable but still not streamlined as much as it should be.
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.
Cool, thanks for the video. Very interesting information about kernels. I will be waiting for the next episode.
P.S. Nice new glasses ;)
Thanks Antoh snf yeah i needed new glasses :). Thanks
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.
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' :)
Nice Bert, yeah the times are changing, amazing how much processing power you could squeak out of that ancient hardware. I remember seeing PDP-11's used for a lot of different tasks, we used them as Peripheral Processor Units (PPUs) off the CDC 6400 machine as well as a few PDP-8's for the less intensive I/O channels.
Man! This channel is pure GOLD.
@@can.slaughter Thank you Lucas
Nice, nice, and nice for sure, very good go back in time :) Well done DJ!
Thank you sir!
Welcome Felix :)
A Great explanation Indeed. Thank You.
Dezmond, thank you glad you enjoyed it.
Love your video of micro kernel, can't wait for the next one on nano and pico, thanks
Thanks for watching!
I guess we're still waiting.
Thank you for your sharing, DJ. Happy to learn a new thing today!
My pleasure, Derek!
Always fascinating to delve into the history of some of these technologies.
Great vid, keep up the good work!
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.
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 RUclipsrs like Brodie/Luke or Podcasts like Linux Action News or Unplugged?
HI Markus, thank you for the kind comments. I have several videos on the future of linux where I talk about some of the areas I see that really need improvement. RedoxOS is another interesting OS, and I have a video talking about Fuchsia and will be updating it as things progress with it. Am I affiliated with other Linux RUclipsrs, not at the moment, I started the channel a few years ago as a way to give something back to the community. Might consider something like that down the road though.
Thanks DJ. Please review Redox!
Where's the rest of the series?
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).
Macrokernals became popular because of speed. OS/2 was a really good microkernal and it's a shame that IBM ditched it.
It's not a microkernel OS but Qubes is a good one to look at in the sense of compartmentalising processes in virtual machines. It's useable but still not streamlined as much as it should be.
Minix not mentioned?
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.
Thanks Lucas for the thoughtful comment, I love Rust as a language and am glad some of the linux distros are beginning to adopt it for their addons.
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.