Information on implementing L4
paul at boddie.org.uk
Fri Sep 14 15:47:47 CEST 2018
On Friday 14. September 2018 05.58.09 Andrew Warkentin wrote:
> Yes, I guess that would work, but you still have the problem of a
> rather complex language runtime being part of the TCB, which you don't
> get with an OS based on safer native code.
I am very fond of dynamic languages which usually their own runtimes, but I
would also be somewhat wary of deploying some of these runtimes in any kind of
privileged role. (I don't know if that is what is being suggested, not having
digested every word of this discussion - sorry!)
As I recall, there are just-in-time compilers being used in the Linux kernel,
maybe in the network firewall/rules functionality, and it is possible that
this has already caused security problems. Of course, there are so many
sources of such problems that it might be mean-spirited to single out just one
> Developers probably aren't going to port to (or completely rewrite for
> in the case of non-.NET languages) some obscure alternative OS.
I see that nobody (prominently) mentioned JX whose documentation was quite
approachable, I thought:
But one of the lessons from the phenomenon of Java is that people don't like
to be told to rewrite all their stuff in a particular language, and although
you can try and make the runtime language-neutral, some languages end up being
more equal than others.
> They'll just say "oh, it runs Linux applications, so our Linux port is
> good enough", and users will probably pass it over because there will
> be few native applications, and Linux applications will be
> second-class citizens (unless you actually manage to integrate Linux
> applications and allow them to take advantage of your OS's advanced
> features, but that sounds like it might be tricky in a non-Unix-like
> language-based OS).
It is interesting to consider Nemesis, which evolved into Xen, in this regard:
One of the goals was to support POSIX applications, and it was apparently a
usable system in its day, maybe still is.
> An advanced Unix-like OS would have a much easier time integrating
> Linux applications (even in its native environment, UX/RT will
> implement Linux-specific APIs where it makes sense to do so, and its
> Linux binary compatibility layer will be more or less transparent,
> allowing Linux programs to integrate reasonably well with the rest of
> the OS and take advantage of many of its advanced features).
It is also interesting to see the UX/RT label given the heritage of Unix
In the L4 microkernel-related materials I have seen, nobody seems to mention
this work or even the foundational influences on it. Indeed, one set of slides
calls the Mach microkernel "The mother of all microkernels", later to discuss
IBM Workplace OS and to note that "OS personalities did not work". Presumably
such remarks are made in that specific context given that DMERT apparently
supported multiple personalities (Unix-RTR and RSX-11).
> However, if you're writing your OS for some reason other than
> practical real-world usage, then I guess compatibility doesn't matter
> as much.
Who is to say that an incompatible system does not have "practical real-world
usage", though? I agree that compatibility would be helpful, and there are
plenty of systems that exist only through the perseverence of their creators,
only to fade away at some point, partly due to a lack of interest and
difficulties integrating mainstream software.
Personally, I am also interested in what it would take to develop a vaguely
standard multiserver system, albeit leveraging L4 technologies. A while back,
people tried to get the Hurd working on L4 (Pistachio, I think), and I think
there is potential to get something like that going on Fiasco.OC, particularly
since the lack of capability support was supposedly the reason why the Hurd-L4
work was abandoned.
On that note, since documentation was discussed at the start of this thread, I
should note that for Fiasco.OC, things like the register usage employed in IPC
appears different from certain specifications. So, for example, the L4 X.2
(revision 6) and V2/MIPS specifications differ from what Fiasco.OC uses,
defined here in the sources:
Obviously, I'm only focusing on MIPS for various reasons. Maybe there is
similar documentation describing these interfaces and a particular
specification that Fiasco.OC implements, but I didn't find it.
More information about the l4-hackers