@jens Theres obviously a need to communicate between userspace and the kernel somehow, but now imagine the network subsystem doing the exact same thing when working with the memory management or filesystem subsystems
Maybe the problem isn't microkernels, but the in-built assumptions kernel devs make about what kind of environment their code is running in.
There's no question microkernels will always take longer to satisfy a service request than a monolithic kernel; so, instead of building APIs that are composed of lots and lots of tiny functions, you create requests that are basically aggregate common functionality.
Prior art: X11 works this way (where xlib queues "lots of little functions" into work units that are big enough that a network request's overhead is well amortized), 9P works this way (where Plan 9 queues seek and read/write interfaces into a single 9P transaction to minimize overhead), the L4 programming interface frequently works this way (where just about every message exchange is always a send-then-receive or receive-then-send, and is one reason why it outperforms Mach), etc.
And, speaking of 9P, although Plan 9 is not technically a microkernel, it is not exactly a monolithic kernel either. It's somewhere in between these two extremes, and any typical Plan 9 environment will make extensive use of microkernel-like functionality, since the vast majority of its system services are actually provided through user-space daemons and applications. ACME, the GUI itself, Plumber, etc. are all user-space, not kernel.
A lot of R&D has gone into making microkernel environments responsive. If they can make hard real-time devices using them, frequently in medical devices that keep people alive, I feel the issue of latency when invoking other system services is a problem which is now tolerable, if not solved.
And though I'm actually doing only userspace things for a bunch of reasons, a kind of planet scale 9P-ish thing is sort of a goal.
My focus is currently on network and security topics. @alcinnz is, in a roundabout way, closer to the file-like protocol. It'll have to be a combination of both to become useful.
TL;DR, a better file-like API would probably make a lot of application code simpler and safer.
A private instance for the Finkhäuser family.