Re: [MirageOS-devel] Rust unikernels

[Geoffroy Couprie <contact@xxxxxxxxxxxxxxxxxxx>]

On Thu, Jul 30, 2015 at 3:17 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> On 30 July 2015 at 13:57, Len Maxwell <len@xxxxxxxx> wrote:
>>
>>
>> On Thu, Jul 30, 2015 at 5:03 AM, Geoffroy Couprie
>> <contact@xxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi Len,
>>>
>>> On Wed, Jul 29, 2015 at 9:12 PM, Len Maxwell <len@xxxxxxxx> wrote:
>>> >
>>> > Hi Geoffroy and Thomas,
>>> >
>>> > On Tue, Jul 28, 2015 at 4:29 AM, Thomas Leonard <talex5@xxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> On 27 July 2015 at 15:54, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> >> > On 27 July 2015 at 09:36, Geoffroy Couprie
>>> >> > <contact@xxxxxxxxxxxxxxxxxxx>
>>> >> > wrote:
>>> >>
>>> >> [...]
>>> >>
>>> >> One other thing I should mention: Mini-OS runs in kernel mode and can
>>> >> be interrupted at any time. On x86, the interrupt handler uses the
>>> >> same stack as the rest of the code. Therefore, you must compile with
>>> >> the Rust equivalent of -mno-red-zone so Rust doesn't assume it can
>>> >> store things below the current stack pointer.
>>> >
>>> >
>>> > I'm just starting to learn Rust, but I managed to create a simple static
>>> > lib
>>> > and link it into a standalone Mini-OS build:
>>> >
>>> > * build Rust from git with static musl libc support [1]
>>>
>>> This is nice, I did not know about musl usage. This may be a bit big
>>> for a unikernel, though. Do we need a full POSIX interface, with
>>> threads and everything?
>>
>>
>> Hi,
>>
>> OK, now I see that targeting musl-static brings in too much
>> additional/unnecessary code; that was my misguided way of working around
>> linker errors between libhello and mini-os.  Your "mm" package imports the
>> "libc" crate; I suppose it adds the Rust stubs for libc functions, which are
>> then linked to the implementations in mini-os? (which, in turn, are not
>> needed for the trivial Rust code)

The libc crate has stubs for POSIX functions, but I import it because
it defines C types for FFI. Those stubs won't matter.

>>
>> It looks like mirage-platform/bindings [a] captures most of the interface
>> between Mirage/OCaml and Mini-OS.  It uses a few functions from time.h,
>> string.h, and various Xen-related APIs.  There's also main.c [b] which
>> overrides start_kernel to kick off the OCaml runtime.  Not sure if any
>> additional functions are needed by OCaml itself?
>
> Not much. We provide a few extra C functions here:
>
> https://github.com/mirage/mirage-platform/blob/master/xen-posix/src/mini_libc.c
>
> Mostly these are just stubs that abort or log if called, but make it
> easier to compile other things. For example, exit calls Mini-OS's
> do_exit; write calls console_print if the fd is 1 or 2; sysconf
> returns EINVAL for every input; etc.

This is what RustOS does. It implements libstd with stubs where it is needed.

>
>> Rust and OCaml also have a common dependency on libm.  For Mirage on Xen, it
>> is pulled in via mirage-platform/xen-posix.
>
> Yes. We're using openlibm, which is a standalone version of the BSD libm.
>
Maybe that one could be reused for Rust.

>> [a] https://github.com/mirage/mirage-platform/tree/master/bindings
>> [b] https://github.com/mirage/mirage-platform/blob/master/bindings/main.c
>>
>>>
>>> Thomas, what's mirage take on this?
>>>
>>> > * compile libhello.a from [2]
>>> Those should be the correct compilation flags
>>>
>>> > * declare the Rust function as an extern in mini-os/kernel.c, call it
>>> > from
>>> > start_kernel()
>>> > * add -L... -lhello to the Mini-OS linker flags
>>> > * make and run
>>> >
>>> > Geoffroy, how does this compare to your approach?
>>>
>>> See my code here: https://github.com/Geal/mini-os/compare/master...rust
>>>
>>> Basically, I'm trying to replace some parts of Mini-OS with Rust code,
>>> as Thomas suggested. That way, we keep an architecture and a
>>> bootloader that work well with Xen, and it can be tested right away
>>> with Mirage.
>>>
>>> >
>>> > To understand the interactions between Xen, Mini-OS, and MirageOS, I
>>> > found
>>> > [3] and [4] useful starting points.
>>> We will need a Rust implementation of clients for Xenbus and Xen
>>> events. Once code is running from start_kernel, the next step is
>>> interacting with Xen's devices.
>>
>>
>> I've started a learning exercise to see how much I can delete from Mini-OS
>> while still supporting Mirage.  Threading, POSIX emulation, HAVE_LIBC, and
>> all of the front/back devs can go (except console), and then I might
>> actually understand what's left.
>
> That's a good idea!

Yes, this is great!

>
>>> > The zinc.rs [5] project, a Rust RTOS for ARM, could provide some
>>> > inspiration
>>> > for modeling low-level operations in a type-safe way.
>>>
>>> Zinc looks great, and they do something that I was planning to:
>>> downloading the libcore part of Rust and linking to it directly. This
>>> is the easiest way to get Rust features as needed, without having too
>>> many dependencies. And once there's a libcore, making a libstd gets
>>> easier.
>>
>>
>> Not knowing much about libcore vs. libstd -- which parts of libstd are
>> important to the task of replacing C code in Mini-OS?

Not much. For the kernel part, we only need slicing, a bit of
formatting, and a way to interact with Xen's memory zones.

For the "user" code, some kind of libstd should be available, to
leverage the existing Rust libraries (almost everything uses libstd).

>>
>> Speaking of ARM, it would be interesting to see if the init_mm experiment
>> runs on a Cubie: https://mirage.io/blog/introducing-xen-minios-arm

I don't have a Cubie, but I could test on a Beaglebone Black.

Geoffroy Couprie

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel