|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Rust unikernels
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) > > 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. > 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. > [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! >> > 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? > > 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 > >> >> > >> > [1]: https://doc.rust-lang.org/nightly/book/advanced-linking.html#linux >> > [2]: https://gist.github.com/lnmx/e7a74bacafb7e38b8355 >> > [3]: http://roscidus.com/blog/blog/2014/07/28/my-first-unikernel/ >> > [4]: https://mirage.io/wiki/xen-events >> > [5]: http://zinc.rs >> > >> >> Geoffroy Couprie > > > -- > Len > -- Dr Thomas Leonard http://roscidus.com/blog/ GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |