5 ms·
While I could go into a long story here about the relative merits of the two designs, suffice it to say that among the people who actually design operating
by ryao 2y ago
While I could go into a long story here about the relative merits of the
two designs, suffice it to say that among the people who actually design
operating systems, the debate is essentially over. Microkernels have won.
The developers of BSD UNIX, SunOS, and many others would disagree. Also, the then upcoming Windows NT was a hybrid kernel design. While it has an executive "micro-kernel", all of the traditional kernel stuff outside the "microkernel" runs in kernel mode too, so it is really a monolithic kernel with module loading.
While the original post was written well before NeXTSTEP, the Mach 3.0 kernel was converted into a monolithic kernel in NeXTSTEP, which later became MacOS. The reality is that Mach 3.0 was just still slow performance wise, much like how NT would have been had they had made it into an actual micro-kernel.
In the present day, the only place where microkernels are common are embedded applications, but embedded systems often don't even have operating systems and more traditional operating systems are present there too (e.g. NuttX).
- fmajid 2y agoNot just that but between 3.51 and 4.0 many NT drivers like graphics were moved to ring 0, trading performance for robustness.
- ryao 2y agoDo you mean robustness for performance?
- Numerlor 2y agoAre graphics just specially handled by the kernel with how recoverable they are from crashes?
- p_l 2y agoVista moved graphics mostly out of kernel even if part of GDI was still handled internally, but essentially the driver model changed heavily and enabled restartable drivers and by Windows 7 IIRC the new model was mandatory. In "classic" Windows and NT 4.0 - 5.2 GDI would draw directly into VRAM, possibly calling driver-specific acceleration routines. This is how infamous "ghosting" issues when parts of the system would hang happened. With new model in Vista and later, GDI was directed at separate surface that was later used as texture and composited on screen. Some fast paths were still available to bypass that mainly for full screen apps, and were improved over time.
- yndoendo 2y agoWindows standard file locking prevents a number of useful user experiences that file base OSes like Linux and BSD provide. Main they can update the files while open / in use. Windows needs to stop a service or restart one to apply updates in real-time. Ever watched the screen flash during updating on Windows? That is the graphic stack restarting. This is more present on slower dual and quad core CPU systems. Microsoft needed to do this to work around how they handle files. Windows even wired HID event processing in the OS to verify that the display manager is running. If the screen ever goes black during updates, just plug-in a keyboard and press a key to restart it. * There are ways to prevent a file lock when open a file in Windows but it not standard and rarely used by applications, even ones written by Microsoft.
- bmacho 2y ago> There are ways to prevent a file lock when open a file in Windows but it not standard and rarely used by applications, even ones written by Microsoft. mpv happily opens files while they are downloading, and they don't interfere each other. > Windows even wired HID event processing in the OS to verify that the display manager is running. If the screen ever goes black during updates, just plug-in a keyboard and press a key to restart it. Funny you mention this, I just have managed to set up my laptop to listen audiobooks. It was such a pain. I somehow disabled the windows lock screen, made a script that calls "nircmd monitor off" every 5 seconds. And with mpv I can listen audio in total dark, and change volume and seek position on the touchpad with gestures. It works, but it is probably cheaper to get an mp4 player with volume and jump back buttons
- throw16180339 2y agoIIRC, didn't they move drivers back to userspace in Windows Vista or Windows 7?
- stevemk14ebr 2y agoNo drivers are kernel modules
- wongarsu 2y agoI believe GP misspoke or misremembered and is referring to GDI, not drivers. GDI is the original Windows 2d graphics interface, widely used for drawing UI. For performance reasons it lived in the NT kernel, together with the Window manager (which also draws windows using GDI). Vista moved to a compositing window manager, I believe that was the point when GDI moved fully into userspace, drawing into the new per-window texture buffer instead of directly to the screen. And of course Windows 7 introduced Direct2d as the faster replacement, but you can still use GDI today.
- rzzzt 2y agoMaybe the reference is about the XDDM/XPDM vs. WDDM driver models, the latter has a kernel-mode and a user-mode portion: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-architecture https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
- throw16180339 2y agoYes, that's what I was thinking of.
- lproven 2y ago> For performance reasons it lived in the NT kernel, together with the Window manager (which also draws windows using GDI). Only from NT 4 onwards. NT 3.1, 3.5 and 3.51 ran GDI in user space. NT 4 moved it into the kernel. NT 5 (branded "Windows 2000") and NT 5.1 (branded "Windows XP") kept it there. It is interesting to consider is as moving back out again; it never was, in my understanding, and even today in "Windows Server Core" it still has the window system built in. But GDI was not so much moved back out of the kernel again as replaced in NT 6 ("Vista") with the new Aero Compositor.
- tonyedgecombe 2y agoYes, I remember blue screening a customers server just by opening a print queue.
- ww520 2y agoBack in the times when I read that statement, it had immediately lost credibility to me. The argument was basically an appeal-to-authority/argument from authority. It put Tanenbaum onto the "villain" side in my mind, someone who was willing to use his position of authority to win argument rather than merits. Subsequent strings of microkernel failures proved the point. The moment Microsoft moved the graphic subsystem from user mode into the kernel mode to mitigate performance problem was the death of microkernel in Windows NT.
- johnisgood 2y agoIf the GPU driver crashes, your kernel does not crash on Windows still, right? It continued working fine on Windows 7.
- ryao 2y agoIt depends on what part of the GPU driver crashes. The kernel mode part crashing caused countless BSODs on Vista. The switch to WDDM was painful for Windows. Things had improved by the time Windows 7 was made.
- pjmlp 2y agoMeanwhile they moved it back into userspace by Windows Vista, and nowadays many kernel subsystems run sandboxed by Hyper-V. One of the reasons for the Windows 11 hardware requirements, is that nowadays Windows always runs as a guest OS.
- betaby 2y ago> kernel subsystems run sandboxed by Hyper-V What subsystems? Is there a documentation outlining that. > nowadays Windows always runs as a guest OS What is hypervisor in that case?
- pjmlp 2y agoYes, https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de... https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows https://learn.microsoft.com/en-us/windows/security/hardware-... https://learn.microsoft.com/en-us/shows/ignite-2016/brk4010 https://learn.microsoft.com/en-us/shows/ignite-2016/brk4010 Naturally it is Hyper-V, given it is a type 1 hypervisor, and Microsoft owned.
- lizknope 2y ago> While the original post was written well before NeXTSTEP, the Mach 3.0 kernel was converted into a monolithic kernel in NeXTSTEP, which later became MacOS. The original Tanenbaum post is dated Jan 29, 1992. NeXTSTEP 0.8 was released in Oct 1988. https://en.wikipedia.org/wiki/NeXTSTEP#Release_history https://en.wikipedia.org/wiki/NeXTSTEP#Release_history 3.0 was not the conversion into a monolithic kernel. That was the version when it was finally a microkernel. Until that point the BSD Unix part ran in kernel space. https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/Mach_(kernel) NeXTSTEP was based on this pre-Mach 3.0 architecture so it would have never met Tanenbaum's definition of a true microkernel. > Mach received a major boost in visibility when the Open Software Foundation (OSF) announced they would be hosting future versions of OSF/1 on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the NeXTSTEP system and a number of commercial multiprocessor vendors. OSF/1 was used by DEC and they rebranded it Digital Unix and then Tru64 Unix. After NeXT was acquired by Apple they updated a lot of the OS. https://en.wikipedia.org/wiki/XNU#Mach https://en.wikipedia.org/wiki/XNU#Mach > The basis of the XNU kernel is a heavily modified (hybrid) Open Software Foundation Mach kernel (OSFMK) 7.3.[3] OSFMK 7.3 is a microkernel[6] that includes applicable code from the University of Utah Mach 4 kernel and from the many Mach 3.0 variants forked from the original Carnegie Mellon University Mach 3.0 microkernel. > The BSD code present in XNU has been most recently synchronised with that from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project as of 2009 Back in the late 2000's Apple hired some FreeBSD people to work on OS X. Before Apple bought NeXT they were working with OSF on MkLinux which ported Linux to run on top of the Mach 3.0 microkernel. https://en.wikipedia.org/wiki/MkLinux https://en.wikipedia.org/wiki/MkLinux > MkLinux is the first official attempt by Apple to support a free and open-source software project.[2] The work done with the Mach 3.0 kernel in MkLinux is said to have been extremely helpful in the initial porting of NeXTSTEP to the Macintosh hardware platform, which would later become macOS. > OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org http://www.mklinux.org). Later, this and code from OSF’s commercial development efforts were incorporated into Darwin’s kernel. Throughout this evolutionary process, the Mach APIs used in OS X diverged in many ways from the original CMU Mach 3 APIs. You may find older versions of the Mach source code interesting, both to satisfy historical curiosity and to avoid remaking mistakes made in earlier implementations. So modern OS X is a mix of various code from multiple versions of Mach and BSD running as a hybrid kernel because as you said Mach 3.0 in true microkernel mode is slow.
- pjmlp 2y agoAll Intel CPUs have a Minix 3.0 powering their management engine. Modern Windows 11 is even more hybrid than Windows NT planned to be, with many key subsystems running on their own sandbox managed by Hyper-V.
- ryao 2y agoThe management engine is an embedded processor.