Dinghy index concept papers




Mu Q&A
.

(This is not linked into the rest of the site at the moment, but seemed better
than adding to the wall of text in IRC.)


// Documentation

Interesting in creating a getting-started-with-mu document. I suppose it
should point people to a reading list, and provide clear build instructions.

Someone who wants to try mu for project euler would have a quick
zero-to-running turnaround.

If you are OK with this, I can start prototyping it on songseed.org (where I
have console access) with the expectation that would move the substance of it
to akkartik.name when (you have time to care about it) + (there is worthwhile
content to move).

I would also try to tidy up the discussion from this channel, and anything
else you point me to (e.g. hacker news thread) into something resembling a FAQ
page.

This is an offer of collab, and do voice any reservations you have.

Below, I will start to ask questions towards this.


// Operating system sketch/design proposal

::: Background

Consider these rival approaches to building a Mu OS,

    1. Use linux to get to Init. Then, load a Mu platform on top of the
    linux kernel.

    2. Build a kernel from scratch.

    3. Two-stage system, assuing n cores,
    
        Hypervisor. Physical system boots a minimal linux. Its focus is to act
        as a hypervisor.

        VMs. Virtual machines hosted by the Hypervisor,
        
            (a) We launch a Linux system in a virtual machine. This will be
            our Bridge Box. (described below in more detail)

            (b-n) We launch n-1 Mu kernels, with each tied to the remaining
            physical cores.

In this proposal, we will focus on the Hybrid model.


::: Hybrid OS model

Motive,

    Drivers are hard. It is a constant race. Option #3 gives us the benefit of
    the linux driver stack and network stack.

    The linux kernel is deeply complicated. Here, we get to create a clear
    partition between the linux kernel and our aspirations to have a whole
    machine that a mortal can fit in their head and reason about.

    Linux cannot do pure-async. Assuming we proceed with Mu coroutines, we now
    have a path towards creating a pure-async operating system to service Mu
    application.

Example layout on a six-core system:

  Virtual machine layer
  .
  . ------------    ---------- ---------- ---------- ---------- ---------- 
  . | Linux    |    | Mu     | | Mu     | | Mu     | | Mu     | | Mu     | 
  . | network  |    | kernel | | kernel | | kernel | | kernel | | kernel | 
  . | and hw   |    |        | |        | |        | |        | |        |
  . | Bridge   |    |        | |        | |        | |        | |        |
  . ------------    ---------- ---------- ---------- ---------- ---------- 


  Hypervisor layer
  .
  . ----------------------------------------------------------------------
  . | Linux Hypervisor Instance                                          |
  . ----------------------------------------------------------------------


  Physical layer
  .
  . ----------      ---------- ---------- ---------- ---------- ----------
  . | Core 0 |      | Core 1 | | Core 2 | | Core 3 | | Core 4 | | Core 5 |
  . ----------      ---------- ---------- ---------- ---------- ----------


::: Messaging-based IPC

Before we get into the details of IPC, we should first highlight that this
approach is unconventional,

    Contemporary operating think of the application layer and the OS layer
    separately. Hence, there is always glue between them. System call
    interfaces and shared object libraries.

    In this system, I am proposing that the Mu kernel be built at the same
    time as the application.

In this way, we will enumerate message types each time we compile. And the
"kernel" and "application" will get the benefit of them. In fact, the kernel
and the application are the same thing in this proposal. A single process,
pegged to a CPU, running in Ring 0.

Sets of Mu kernels need to be raised and lowered in concert. There will be
tooling on the Linux Hypervisor Instance to facilitate this.

With these arrangements in place, we can use strongly typed messages to
communicate between Mu instances. (I am unsure of the lower levels of how this
will work. This old article hints at some mechanisms,
https://www.drdobbs.com/sharing-memory-with-the-virtual-machine/184402033)


::: Bridge Box

The coming sections will talk about the Bridge Box.

The role of the bridge is to provide a static interface that Mu instances can
access in order to access hardware and network.


::: Bridged network

Here is a problem that we still have with the hybrid model: what to do about
a network stack? You /could/ build one in Mu. But it would be a lot of work.

Instead, in this proposal we leverage Linux for that. Our bridge instance acts
as a Go-between. Within the system, it speaks in terms of Mu messages. It uses
its network stack to talk outside the system.

Example of an outbound TCP client connection,

    Mu kernel messages to the Bridge

    Bridge uses its TCP stack to make connection to outside world.

    Bridge uses messages to communicate back to the Mu kernel.

Example of a TCP server hosted on a Mu kernel,

    Mu kernel messages the Bridge to indicate it is listening for traffic on
    a particular port.

    Bridge starts up its own TCP server.

    Bridge proxies information tothe Mu kernel, using messages.

    Later, the Mu kernel signals that it is closing its TCP connection. The
    bridge obliges, and sends a message back to indicate that it has.


::: Disk, GPU

You could talk to other hardware using roughly the same mechanism.

In this way, we leverage Linux driver support for native hardware where you
need it.


::: Memory management

To start with, the hypervisor makes a static allocation of RAM to each kernel
when it starts up.

If there was demand for more dynamism than that, we could evolve towards a
Single-System Image architecture. The messaging IPC I propose would be a
strong foundation for such an evolution.



// Mu language questions

(These are not feature-requests. Genuine questions about perspective.)

::: Exceptions and complications created by that

Do you have any thoughts about situations where a function can return an
error.

For example. In your sample functions, you return result/eax. Could there be a
second entry for error/ebx?

If this was introduced, it might require variable unpacking on the left of the
arrow. A similar concept in python,

    (a, b, c) = (1,2,3)

Change like this complicates the code. Complication is undesirable.

What are your thoughts?


::: Type inference

What are your thoughts about type inference?

I see you using 'var' in document ./apps/ex3.2.mu

If mu had type-inference, you could remove the need for types after variables
names. (But you may judge it desirable to have such things)


::: Compiler strategy

Do you have a particular strategy in mind for the mu complier? (e.g. hand
rolled recursive descent. I suspect you have found something even simpler,
because your notation can be parsed line-by-line.)


::: Named parameters

In the other direction, what are your thoughts about named parameters?

You could force or allow the user to always name the arguments they were
passing to a non-primitive function.

Rough example,

fn format_string
    addr:   int
    q:      int
    r:      uint
    s:      string*
-> result/eax: int {
    # ...
}

{
    len <- format_string(
        addr: eax
        q:    42
        r:    43
        s:    "some text")
}


::: Namespaces

Do you have opinions about the idea of adding namespaces to mu? (Your notes
about testing imply you have thought about it)


::: String handling

Handling strings is a challenge in multiple languages.

The way that C orders items onto the stack was decided by what was convenient
for printf.

Do you have thoughts about how to cover situations which, in C, would be
covered by varargs? Such as printf?