You can always use DDEKit with linux drivers on an L4 kernel; probably not without possible bugs, but if you're doing something like that you would probably have time to check for bugs yourself.
Those l4 kernels are pretty impressive. These are what we need for IoT, along with rewritten userspace in "safe language" (for some value of safe). The BIG job will be rewriting drivers (at least certain drivers for devices like network adaptors (including Bluetooth)) so as to make the system as reliable as possible.
The Genode framework is almost perfect for this sort of project but its security isn't there yet.
plus, the OP referred to HURD as a general proof of failure for microkernels in general - but if anything, HURD only proved that stallman and his minions arent able to successfully develop a microkernel based OS and make it mainstream (with the model they're still adhering to, being tied to early 90's microkernel technology because of them not knowing any better)
but other microkernels have built upon the mistakes and inefficiencies of legacy Mach, distanced themselves a lot from it and strived quite a bit, although in specific niches (rt critical systems typically run on microkernels rather than linux) wouldn exactly call it a failure though..
maybe, if you just look at the kernel alone and equate beauty with minimalism.. from an engineering perspective things get quite less rosy when you consider that code that would otherwise belong to the kernel ("drivers", resource arbitration facilities and so on (*)) is still there, together with more (kernel - and user -) non trivial code needed to support the former in running in its own process, be restartable etcA proper micro-kernel is a thing of beauty from an architecture perspective -
so the overall view on the OS core (what needs to be present at very least to allow a process to run- which now includes much more than just the kernel) may even be less clean than before
(*) resource (cpu cycles, memory, files or storage devices, io ports) sharing and arbitration need to be done anyway - but centralising "drivers" and the rest of it in the kernel allows to implement it in an efficient way that also allows the kernel to be sufficient (load the kernel and you're ready to run non core processes - not so with microkernels)
that's why it's put it beneath the kernel to userpace barrier in a pragmatic, rather than elegant, design ..
otoh, it's to be noted that microkernels existed that achieved better performance than certain monolithic ones.. fanboyisms apart, it's all a matter of algorithms really, and how much processing a system call takes compared to the overhead of the client server round trip overhadbut keeping that purity of architecture means you can't make the compromises and shortcuts that are needed to achieve adequate performance.
consider that during time, microkernels have tacked and sometimes very cleverly solved the ipc overhead problem - something linux has yet to discover as a problem, much less solve (KDBUS still does copy across address spaces and marshaling/demarshaling whereas other systems directly share argument stacks)
and otoh, dont assume that just because linux isnt, no other monolithic/hybrid kernel is or can be internally compartmentalized with well defined api's...Monoliths have their own problems, of course, but by not enforcing strict interfaces between modules, they can avoid an awful lot of overhead...
Last edited by silix; 07-30-2014 at 10:42 AM.