It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.
Yeah but fact a part can crash without bringing rest down doesn't make it non-monolithic.
The fact that driver bug in theory could overwrite any other part of the kernel is what makes it monolithic.
Sure, I'm just saying that there is some nuance to "a driver crashing crashes the whole kernel".
Yes. But a Linux driver can crash the whole OS. In micro kernel land, most driver will not be able to do that.
As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".
You're almost there. Yes, there's a narrower definition. Yes, that means that crashes are outwith the kernel. But no that only means that the circle around what bit is named "the kernel" is smaller. Importantly, it does not mean that it is impossible to "crash the whole operating system".
Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the entire operating system relies upon, such as a central shared rendezvous server, or a server that handles "magic" values, or a central local security subsystem server, or a shared fundamental "personality subsystem" server, still crashes the entire operating system, no matter that the crash isn't in the part of the operating system that's labelled "the kernel".
I think now we need to define what's the "whole OS". From a user's perspective: the whole OS crashed (became unresponsive). But from a developer's perspective the OS worked, as it was still logging, responding to network, etc.
In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.