Linux: microkernels are crap, it's clearly impossible to do anything useful with message passing.

Also Linux: if you want to do anything with network device configurations, here's the AF_NETLINK socket type and a bunch of messages you can pass to/from the kernel to get everything done.

I know there's nuance that I'm ignoring here, but it amuses me.

@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

@espen @jens I can, and I have used systems that worked exactly in that mode before (e.g., QNX), and the systems were very responsive. This, on 386 and 486-class hardware.

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.

@vertigo @espen I had that opinion for a while, but frankly never had that much experience with these systems, other than as an end user.

@jens @espen Contrary to what my post might suggest, I'm not actually a microkernel apologist. My preferred architecture is exactly what Plan 9 uses; a hybrid design where you can get the best of both worlds, leaving it up to a system integrator to decide what resides in the kernel and what doesn't. Putting something in the kernel should be a performance optimization, not a hard requirement for basic operation.

Linux modules are a great compromise here, but I think their potential was never truly realized. I agree with Rob Pike that the basic philosophy behind Unix I/O primitives are under-utilized. Yeah, we now have /proc and /sys, but ... that's it?

I think it's obscene that Linux has over a thousand system calls when I've used, maybe, a total of 40 system calls in all my code since 1995, when I switched to using Linux as my desktop for the first time.

Old man shouting at clouds again, I suppose.


@vertigo @jens @espen take the unikernel pill: everything should be in the kernel

@lunch @jens @espen +1 if the hypervisor offered the right services. I grew up on AmigaOS; if I can use contemporary terminology, arguably the first open-ended uni-microkernel environment. 😏 There are still some things about it that I miss dearly.

Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal support us on patreon or liberapay!