Thank you Dave for this video. I use it in my class at CTU (Colorado Technical University). My class studies computer architecture and one of the subjects is operating systems. You provide a good starting point where we discuss the benefits and problems found with MicroKernels.
Okay, can we get serious now? I mean, I keep hearing that the difference between a monolithic kernel OS and a microkernel OS is all about how much of an OS runs in "kernel mode" versus how much runs in "user mode", and that the benefits of one type over the other therefore depends on this difference. But this comparison plainly ignores the fact that there does *NOT* need to be just two processor privilege modes that a CPU can run in, as well as the fact that there does *NOT* need to be a context switch in order to change processor privilege and gain addition memory protection (with the right hardware). So ISTM that what we're talking about here is what's the least crappy way to do things when you've ruled out the "better" way to provide memory protection which is to use rings and domains with gates. The original CPU hardware for Multics had just two processor modes, but it is my understanding that even way back when, this was used to emulate (albeit slowly) more processor privilege modes to support the notion of "rings" and "domains" until the CPU hardware was revised to actually support more processor privilege modes for real. I'm not a Multician, but it's my understanding that there were gates that allowed the processor privilege to change (at least in the later hardware) at least in some cases without a context switch (i.e. an interrupt). Likewise, the 80386 and its ilk (until the x86-64 architecture hit the fan) had more than two processor privilege modes (up to four [4]) whose use seemed to be ignored because it might make OS designers actually consider using segmentation on top of paging. The 80386 and it's ilk also supported gates to change processor privilege mode without a context switch although you had to accept and use segmentation, which again various OS designers seemed to be hell bent on avoiding. Then there's the Unisys M-Series architecture as exemplified by the the 2200/900 and 2200/500 which likewise had more than two processor privilege modes (up to four [4]) until the Company stopped making CPU hardware and instead turned to emulation resulting in going back to just two. Even so, there's still a ring/domain mechanism built into the M-Series segment descriptors and segment registers (called "banks" in Unisys-speak) with eight (8) ring layers (and thousands of domains within a ring) even today. And you can very much go between pieces of code that are different privilege levels in different banks by means of goto and call gates *WITHOUT* a context switch by way of an interrupt in order to pass a "message" (AKA "packet" in Unisys-speak) except for possibly getting into processor privilege 0 which is pretty much the domain of interrupt handlers. And with all due respect to Professor Tanenbaum, the last time I looked at Minix-3, it too looked (to me) like it was doing the same sort of protection mode (ring) emulation thing that was done on Multics by using bit maps to determine who can be the recipient of a message. So it seems to me that all of this talk about the advantages of monolithic kernels versus microkernels all boils down to how much "pain" an OS designer/user is willing to accept *WHEN THEY DO NOT WANT TO TAKE ADVANTAGE OF USING MULTIPLE PROCESSOR PRIVILEGE LEVELS AND THE GATE MECHANISMS THAT GO WITH THEM* which is directly related to the fact that the majority of people apparently don't want to think about using segmentation which seems to a large reason behind having multiple processor privilege levels in the first place. But rings and domains don't require segmentation as is evidenced by the Dirty Genitals (AKA Data General AKA DG) Eagle's incorporation of ring level into the processor's addresses. This suggests to me that the "real" reason behind the argument over monolithic kernel OS versus microkernel OS must some how be related to the old "ring" and "domain" protection scheme having some sort of deficiency that causes everyone to look everywhere except for the obvious and lower overhead (albeit a very CISC-like) method. So can someone explain the me what this deficiency is and how the current fixation on monolithic kernel versus microkernel OS corrects for it? Thanks in advance.
@@DavidEvans Yes, we've been hearing that for ages. But, to be fair, while Minix is the de-facto academic example of a microkernel, QNX is a microkernel and has been successful (albeit, sure, in its niche) for several decades now. So claiming that microkernels are just nowhere yet is a false claim. Comparing Linux and QNX would be more interesting, and more fair. I'm curious to see what's been done in that regard, and what your opinion is regarding QNX. (Leaving aside license considerations.)
@@joseoncrack Yes, QNX is a good example (and has an interesting academic history). I talk about L4 at the end of this clip, which is an even more widely distributed microkernel OS thank QNX, although QNX may be more interesting in other ways.
@14:48 worth mentioning that Avie Tevanian went on to NeXT where he built the Mach based NeXTSTEP and then later Apple, which of course, built macOS based on NeXTSTEP. Both of those OSes are hybrid, correct?
Yes, "hybrid" is usually a murky term, but I think it applies pretty clearly here, where NextSTEP was using the Mach microkernel as a component, but inside a BSD kernel.
I was enamored with Tannenbaum's thesis until I saw this wonderful clip! I was wondering, if it was that easy, why did Linux work and Minx didn't, who likes to increase the lines of code in their project by millions and cause more bugs on the kernel when they can not do that! Thank you david!
I read an article that the trends of memory is more flat than cpu when it comes to speed, etc and that a micro kernel vs monolithic kernels are only 10% in different, which was explained here (disk seek) but, what about memory efficiency, if memory speed and size is more flat compared to cpu
I am not sure if L4 is still used today. Tbh I did not know there are multiple OS used in the same smartphone. I thought Android and the underlying kernel takes care of all that, including the radio chip that takes care of the communications. Can you kindly clarify if this is still the case?
Yea chips have its own firmwares usually. Like baseband has its own or secure chips such as SEP on iPhones run a whole different OS(speaking of that SEPOS run embedded). They can communicate but still separated
Hello ! I want to ask you something, I wrote a riscv32im emulator, and it has 512mb of rom and 512mb of ram, and I have written test programs and the cpu works perfect, but I want to write a microkernel, and the truth is that how the theory of kernel but not the practice, I do not speak of only a multitasking as free rtos, I want that cpu to load independent programs in the ram and execute them, something very simple for me to understand, I have currently managed to load a program in the ram and positioned the counter program to the address where the application is and executes it, but by positioning the counter in another location that application takes full control of the entire cpu, thank you very much!
In order to support operating systems, the processor needs to be able to do a context switch, which is described in the RISC-V Privileged set, which adds support for machine mode, Supervisor mode, and User mode, a machine timer register, and another instruction called a trap. When you call a trap in User mode, it jumps to a trap handler which is pointed to in a certain region of memory, and then elevates it to Supervisor mode so the supervisor code can handle the trap. Then, if you want to jump out of a user program and into another, you can set up the machine timer, which will regularly call a trap at certain intervals. You can program this trap to decide which program to jump into next, switch to user mode, and jump into it. There's a lot of other bookkeeping to be done like saving the state of the program, but that's the gist of it
I am in the storage business and wonder, the actual block size in a monolithic operating system like linux is limited to 4096 bytes, which hinders filesystem to actually use larger blocks so in order to deal with larger io it, it has to put the file io into a queue on the kernel (called elevator), and try to figure out which part is sequentials, try to mapping these together into larger io pass this to the device layer and complete the io task on a monolithic operating system, I would assume that those io can be larger, and should improve the performance, right? second question I know that there could also be differences comparing true timesharing multitasking operating systems with preemptive multitasking system, right?
Not necessarily. The 4096 byte limit is imposed by the memory management unit. The processor can only specify memory in these 4KiB chunks when talking to the MMU, thus IO is divided in this size. Many newer amd64 CPUs support huge pages, which can either be 2Mib or 1GiB in size, however, for compatibility reasons, these are normally not used. These need to be compiled into the kernel and enabled at boottime for support.
@@Tony_Goat thanks Tony that is what I meant if a larger file i/o enters the kernel space, it is cut into 4kb chunks, sent to the i/o driver glued together into larger size and if one is lucky, it is same or bigger size some system has smaller io size after cut-paste/gluing... and this process is waste of system resources
@@repostorthe problem with larger io pages is that all memory allocations on the system are in terms of pages. The larger the pages the less granular your memory allocations are.
@@emdadgar_officialrust will be a big deal in OS/systems programming. Microsoft already use it in their kernel and Apple already use it in their GPU driver. Rust could eliminate the majority of vulnerabilities in systems programming. I hope you stuck with it and didn’t listen to C programmers who think they know absolutely everything.
Stackoverflow: ”Do not confuse the term modular kernel to be anything but monolithic. Some monolithic kernels can be compiled to be modular (e.g Linux), what matters is that the module is inserted to and runs from the same space that handles core functionality (kernel space).” Althought it's hybrid most of it can be considered monolithic. In terms that core part is monolithic.
What a nice professor, my professors just read from slides and it has no benefit. Thanks for the video
shall i go in school to be abale build OS ?
i'm from Iran .....
Thank you Dave for this video. I use it in my class at CTU (Colorado Technical University). My class studies computer architecture and one of the subjects is operating systems. You provide a good starting point where we discuss the benefits and problems found with MicroKernels.
Such an informative lecture wished i had professor like you in my college
The GNU system was meant to have a microkernel long before Linux got started.
This is a very informative discussion about microkernels. Great job prof.
Okay, can we get serious now?
I mean, I keep hearing that the difference between a monolithic kernel OS and a microkernel OS is all about how much of an OS runs in "kernel mode" versus how much runs in "user mode", and that the benefits of one type over the other therefore depends on this difference.
But this comparison plainly ignores the fact that there does *NOT* need to be just two processor privilege modes that a CPU can run in, as well as the fact that there does *NOT* need to be a context switch in order to change processor privilege and gain addition memory protection (with the right hardware).
So ISTM that what we're talking about here is what's the least crappy way to do things when you've ruled out the "better" way to provide memory protection which is to use rings and domains with gates.
The original CPU hardware for Multics had just two processor modes, but it is my understanding that even way back when, this was used to emulate (albeit slowly) more processor privilege modes to support the notion of "rings" and "domains" until the CPU hardware was revised to actually support more processor privilege modes for real.
I'm not a Multician, but it's my understanding that there were gates that allowed the processor privilege to change (at least in the later hardware) at least in some cases without a context switch (i.e. an interrupt).
Likewise, the 80386 and its ilk (until the x86-64 architecture hit the fan) had more than two processor privilege modes (up to four [4]) whose use seemed to be ignored because it might make OS designers actually consider using segmentation on top of paging.
The 80386 and it's ilk also supported gates to change processor privilege mode without a context switch although you had to accept and use segmentation, which again various OS designers seemed to be hell bent on avoiding.
Then there's the Unisys M-Series architecture as exemplified by the the 2200/900 and 2200/500 which likewise had more than two processor privilege modes (up to four [4]) until the Company stopped making CPU hardware and instead turned to emulation resulting in going back to just two.
Even so, there's still a ring/domain mechanism built into the M-Series segment descriptors and segment registers (called "banks" in Unisys-speak) with eight (8) ring layers (and thousands of domains within a ring) even today.
And you can very much go between pieces of code that are different privilege levels in different banks by means of goto and call gates *WITHOUT* a context switch by way of an interrupt in order to pass a "message" (AKA "packet" in Unisys-speak) except for possibly getting into processor privilege 0 which is pretty much the domain of interrupt handlers.
And with all due respect to Professor Tanenbaum, the last time I looked at Minix-3, it too looked (to me) like it was doing the same sort of protection mode (ring) emulation thing that was done on Multics by using bit maps to determine who can be the recipient of a message.
So it seems to me that all of this talk about the advantages of monolithic kernels versus microkernels all boils down to how much "pain" an OS designer/user is willing to accept *WHEN THEY DO NOT WANT TO TAKE ADVANTAGE OF USING MULTIPLE PROCESSOR PRIVILEGE LEVELS AND THE GATE MECHANISMS THAT GO WITH THEM* which is directly related to the fact that the majority of people apparently don't want to think about using segmentation which seems to a large reason behind having multiple processor privilege levels in the first place.
But rings and domains don't require segmentation as is evidenced by the Dirty Genitals (AKA Data General AKA DG) Eagle's incorporation of ring level into the processor's addresses.
This suggests to me that the "real" reason behind the argument over monolithic kernel OS versus microkernel OS must some how be related to the old "ring" and "domain" protection scheme having some sort of deficiency that causes everyone to look everywhere except for the obvious and lower overhead (albeit a very CISC-like) method.
So can someone explain the me what this deficiency is and how the current fixation on monolithic kernel versus microkernel OS corrects for it?
Thanks in advance.
Micro kernel and RISC micro processors are the future and the simplicity is the winner.
Yes, they have been the future since the 1980s - but maybe we are getting close now...
wow, people are alive with sense, I am totally with you on this point.
VLIW for the winner
@@DavidEvans Yes, we've been hearing that for ages. But, to be fair, while Minix is the de-facto academic example of a microkernel, QNX is a microkernel and has been successful (albeit, sure, in its niche) for several decades now. So claiming that microkernels are just nowhere yet is a false claim. Comparing Linux and QNX would be more interesting, and more fair. I'm curious to see what's been done in that regard, and what your opinion is regarding QNX. (Leaving aside license considerations.)
@@joseoncrack Yes, QNX is a good example (and has an interesting academic history). I talk about L4 at the end of this clip, which is an even more widely distributed microkernel OS thank QNX, although QNX may be more interesting in other ways.
I always thought Dave Cluter had based the NT Kernel architecture on VAX/VMS. This history of the Mach Kernel is new to me.
@14:48 worth mentioning that Avie Tevanian went on to NeXT where he built the Mach based NeXTSTEP and then later Apple, which of course, built macOS based on NeXTSTEP.
Both of those OSes are hybrid, correct?
Yes, "hybrid" is usually a murky term, but I think it applies pretty clearly here, where NextSTEP was using the Mach microkernel as a component, but inside a BSD kernel.
This is a really nice explanation for a beginner
I was enamored with Tannenbaum's thesis until I saw this wonderful clip!
I was wondering, if it was that easy, why did Linux work and Minx didn't, who likes to increase the lines of code in their project by millions and cause more bugs on the kernel when they can not do that!
Thank you david!
I read an article that the trends of memory is more flat than cpu when it comes to speed, etc
and that a micro kernel vs monolithic kernels are only 10% in different, which was explained here (disk seek)
but, what about memory efficiency, if memory speed and size is more flat compared to cpu
Great videos! Are the complete lectures available anywhere?
Thanks, Jose! The full class is available here: www.rust-class.org/, with direct links to all the videos at: rust-class.org/pages/classes.html
I am not sure if L4 is still used today. Tbh I did not know there are multiple OS used in the same smartphone. I thought Android and the underlying kernel takes care of all that, including the radio chip that takes care of the communications. Can you kindly clarify if this is still the case?
Yea chips have its own firmwares usually. Like baseband has its own or secure chips such as SEP on iPhones run a whole different OS(speaking of that SEPOS run embedded). They can communicate but still separated
Hello ! I want to ask you something, I wrote a riscv32im emulator, and it has 512mb of rom and 512mb of ram, and I have written test programs and the cpu works perfect, but I want to write a microkernel, and the truth is that how the theory of kernel but not the practice, I do not speak of only a multitasking as free rtos, I want that cpu to load independent programs in the ram and execute them, something very simple for me to understand, I have currently managed to load a program in the ram and positioned the counter program to the address where the application is and executes it, but by positioning the counter in another location that application takes full control of the entire cpu, thank you very much!
In order to support operating systems, the processor needs to be able to do a context switch, which is described in the RISC-V Privileged set, which adds support for machine mode, Supervisor mode, and User mode, a machine timer register, and another instruction called a trap.
When you call a trap in User mode, it jumps to a trap handler which is pointed to in a certain region of memory, and then elevates it to Supervisor mode so the supervisor code can handle the trap.
Then, if you want to jump out of a user program and into another, you can set up the machine timer, which will regularly call a trap at certain intervals. You can program this trap to decide which program to jump into next, switch to user mode, and jump into it.
There's a lot of other bookkeeping to be done like saving the state of the program, but that's the gist of it
I am in the storage business
and wonder, the actual block size in a monolithic operating system like linux is limited to 4096 bytes, which hinders filesystem to actually use larger blocks
so in order to deal with larger io it, it has to put the file io into a queue on the kernel (called elevator), and try to figure out which part is sequentials, try to mapping these together into larger io
pass this to the device layer
and complete the io task
on a monolithic operating system, I would assume that those io can be larger, and should improve the performance, right?
second question
I know that there could also be differences comparing true timesharing multitasking operating systems with preemptive multitasking system, right?
Not necessarily. The 4096 byte limit is imposed by the memory management unit. The processor can only specify memory in these 4KiB chunks when talking to the MMU, thus IO is divided in this size.
Many newer amd64 CPUs support huge pages, which can either be 2Mib or 1GiB in size, however, for compatibility reasons, these are normally not used. These need to be compiled into the kernel and enabled at boottime for support.
@@Tony_Goat thanks Tony
that is what I meant
if a larger file i/o enters the kernel space, it is cut into 4kb chunks, sent to the i/o driver glued together into larger size
and if one is lucky, it is same or bigger size
some system has smaller io size after cut-paste/gluing...
and this process is waste of system resources
@@repostorthe problem with larger io pages is that all memory allocations on the system are in terms of pages. The larger the pages the less granular your memory allocations are.
Really good video Dave. Thanks for sharing this.
i have no access to a rich resource of OS area ... i learning rust . i wish i could be a OS developer .
Learn c and some assembly languages bro
@@Bruh-hd4rj C is massive exprianced area for OS ,, but why not rust ? we see efort in it like redoxOS ?
@@emdadgar_officialrust will be a big deal in OS/systems programming. Microsoft already use it in their kernel and Apple already use it in their GPU driver. Rust could eliminate the majority of vulnerabilities in systems programming. I hope you stuck with it and didn’t listen to C programmers who think they know absolutely everything.
Linux isn't monolithic because supports modules, is a weird thing in between, a hybrid.
Stackoverflow:
”Do not confuse the term modular kernel to be anything but monolithic. Some monolithic kernels can be compiled to be modular (e.g Linux), what matters is that the module is inserted to and runs from the same space that handles core functionality (kernel space).”
Althought it's hybrid most of it can be considered monolithic. In terms that core part is monolithic.
14:51 - is that Scotty from Star Trek?
Damn... If not he's a dead ringer!
great explanation
awesome video. thanks
Unikernels!!! Exokernels!!
I Didn't understand
Where's the full unedited videos?
Sorry, I'm not able to share the unedited videos. You can find all the videos and other course materials here: rust-class.org/pages/classes.html