Re: Information on implementing L4

Also, perhaps I should look into seL4; although I'm not sure I can leverage
it.  Long-term, I want to get .NET Core running on something akin to L4
implementing Minix (reliability features) and Linux (userland ABI), with a
capability-based security model.  That's years out, and short-term I'm
probably just using Alpine Linux as a base for things like electronic
voting machines (everybody is doing elections integrity wrong; I started
with an integrity model and built around that).

On Thu, Sep 13, 2018 at 10:27 PM John <[email protected]> wrote:

> 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 <[email protected]>
> 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 <[email protected]> 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
>> [email protected]
>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>>
>>
>>

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers