Information on implementing L4

[Paul Boddie]

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 
of them.

> 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:

https://en.wikipedia.org/wiki/JX_(operating_system)

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:

https://en.wikipedia.org/wiki/Nemesis_(operating_system)

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 
systems:

https://en.wikipedia.org/wiki/Multi-Environment_Real-Time

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:

pkg/l4re-core/l4sys/include/ARCH-mips/L4API-l4f/ipc.h

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.

Paul