[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reviewing Hurd-on-L4 (and considering its future?)

From: Paul Boddie
Subject: Reviewing Hurd-on-L4 (and considering its future?)
Date: Wed, 23 May 2018 17:21:32 +0200
User-agent: KMail/1.13.7 (Linux/3.2.0-6-486; KDE/4.8.4; i686; ; )


The day before yesterday, I found myself editing the L4 page on the Debian 


It occurred to me that in the context of the Hurd, very few updates about L4 
implementations have been propagated via various channels for probably a 
decade or more. This meant that the above page was outdated as well as 
inaccurate or incorrect on some matters (and it wasn't exactly a long page, 

Reviewing the archives for the l4-hurd list, I see that very little discussion 
has taken place since 2010 or so, where Viengoos was once again mentioned. And 
the background to all this is, of course, provided on the Hurd site:


What I would like to know is whether more modern L4 implementations might be 
reasonable candidates for attempting this kind of work again. It seems to me 
that L4 implementations of the early 2000s were considered inappropriate or 
insufficient for the design of "Hurd-NG", leading to things like Viengoos.

But then again, L4 implementations have since been widely deployed, albeit 
perhaps in very specific roles. Meanwhile, environments like L4Re and Genode 
must surely go some of the way towards providing the basis of something like 
the Hurd.

The hurd-l4 work that was previously released got as far as running the banner 
program, apparently, but surely things like L4Re and Genode go quite a bit 
further than that. Obviously, they are merely the foundations of any potential 
Hurd-like system, but it would not be unfair to claim that anyone wanting to 
implement such a system would start off with a lot more code already written 
than was the case fifteen or so years ago.

So, has anyone seriously considered a fresh approach to this endeavour using 
more recent L4 implementations and environments? I largely ask because I have 
been developing programs to run on certain niche hardware devices using L4Re 
and the Fiasco.OC microkernel, and although some aspects of this are 
frustrating, it is surprising how much supporting code there is already. I can 
envisage building components on top that support a more general computing 

Does anyone have any constructive perspectives on this?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]