Information on implementing L4

[John]

Thanks!  That's a lot clearer than the rambling muck I'd read before.  This
is all highly-technical stuff and it does require some understanding of
computers and operating systems; but it's so far on the fringe that many
authors fail to consider an audience that doesn't already know what they're
talking about, as if everyone is a kernel programmer who has simply never
stepped back to get the big picture.

Wow, this document is really clear.  It also makes it clear that L4 is
still evolving, which suddenly makes things make a lot of sense.

On Thu, Sep 13, 2018 at 9:48 PM Gernot Heiser <gernot at cse.unsw.edu.au>
wrote:

> Hi John,
>
> In terms of what makes L4, the most comprehensive recent document is this:
> https://ts.data61.csiro.au/publications/nictaabstracts/Heiser_Elphinstone_16.abstract.pml
>
> Gernot
>
> On 14 Sep 2018, at 10:55, John <john.r.moser at gmail.com> wrote:
>
> Hi all.
>
> I've been looking at Google and Wikipedia for information about L4, and
> it's fairly thin.  I've come up with that L4 has read and write registers
> and performs IPC by fixed-length registers, with all actions synchronous (I
> guess that means you send a message and block until the target thread reads
> the message).
>
> Is there a more concrete document anywhere about implementing an L4
> microkernel and what makes it L4?
>
> I'm surveying the field at the moment and looking at all the advances made
> in computer software—security, managed language runtimes, hypervisors,
> real-time OS—and trying to project the possibilities for a next-generation
> operating system.  There's enough divergence that a rewrite from scratch
> might make sense; and besides, I've drawn up a method for getting a
> self-hosting CLR running with only anonymous memory allocation and VFS file
> page mapping, along with a method of getting the CLR to self-host and
> getting it up and running before an actual OS kernel.
>
> In other words:  it's readily-achievable to write a CLR in C#, get it
> running on itself before the kernel comes up, then load a kernel, VMM, VFS,
> ABI, scheduler, and so forth—all written in C#, compiled to CIL, and
> totally independent of the hardware architecture underneath—and then throw
> away the loader and bring up init.  The kernel would need to use an
> abstract factory model to do common tasks which require hardware-specific
> code, and the CLR would need to load an assembly with a concrete factory
> for the particular hardware and a few built-in native assembly calls; but
> it's doable.
>
> This is all theoretical at the moment, and I want to explore the
> particular edges a little to see what I find out.
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20180913/395aadf7/attachment.htm>