In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust.
We could afford that before, it's just that Linus didn't see the value and put his foot down. Which is definitely a choice.
They aren't general purpose, but I presume microkernel "services" would also not be general purpose?
they are seldom implemented correctly on firmware/mainboard level.
On the other hand, datacenters have become so large that a 1% performance improvement can amount to millions of dollars in hardware and energy savings, so the extra cost of a microkernel might not be very welcome outside consumer devices.
Microkernels have won, even if monolitich kernel advocates haven't yet got the message.
Not to forget all the hardware based security bypasses that let any random application read and even modify any memory location it wants to.
The basic problem is that the kernel boundary is a trust boundary. You assume that anything in the kernel is legit and won't try to attack you, which simplifies things a lot. In the microkernel world the original idea was that all the servers would be just ordinary programs you could swap in and out at will. But then the threat model becomes muddied and unclear. Is it OK to run a server that's untrusted? If so, to what extent?
The Hurd seems under-designed as a consequence. To make that vision work you'd need to be willing to depart from UNIX way more, which really means being a research OS.
No, of course, it doesn't automatically do so. But it makes it a whole hell of a lot easier to write a reliable service, if you don't have to deal with all the crap that a monolithic kernel does.
I think you'd find Plan 9 interesting. It deals with many of the issues you're talking about in a rather head on way. In fact, it takes things even further than Hurd might, and allows processes to migrate to different processors, which may be contained on completely different machines.
2. Modern day hardware is mostly just ringbuffers mapped to memory. There's a real convergence of hardware interfaces, virtio, and io_uring into all being this very similar looking thing. With IOMMUs, moving drivers to userspace is pretty attractive. There's not much of a difference between a cloud VM getting access to a VFIO device from the hypervisor and a userspace device driver getting access to hardware from the microkernel. And there's a lot of money in making cloud VM networking & storage faster.
Check out Antti Kantee's The Design and Implementation of the Anykernel and Rump Kernels if you want details on the architecture.
> You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.
Just because the driver creator is a different human/org to the Kernel maintainers, doesn't mean their code needs to be separate if it makes more practical sense to bundle it all together.
Also the "proof of work" of being allowed to add your driver is probably that you are designing and producing actual hardware, so it is hard to troll.
I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-kernel-cost.html I expect that most of the current Linux kernel code is also for handling hardware (that is, drivers + the code to handle various architectures).