Golang on Genode: a follow-up

[Rolf Sommerhalder]

Hello,

At GopherCon 2016 [1, 2], Bernerd Schaefer presented AtmanOS [3, 4]
which cross-compiles Go programs so that they interface/run directly
on Xen hypervisor, e.g. as hypervisor-aware Unikernels, without
requiring a Guest OS on virtualised environments.

According to Bernerd, AtmanOS provides a microkernel, an
implementation of Go's runtime, and standard library, all implemented
natively in Go (3000 lines) with a little bit of Assembly (150 lines).
From AtmanOS' repo, I noticed that they have recently updated it's
bootstrap code to the latest version of Go 1.8.1, so the project is
still active.

After following the threads about Golang on Genode and reviewing
AtmanOS, I suspect that AtmanOS could facilitate bringing Go to
Genode, for example by making AtmanOS target Virtualbox in addition to
Xen (maybe not so elegant), or by adapting/replacing AtmanOS'
microkernel with Genode, and porting the Go runtime, standard library
and system packages that AtmanOS wrote in Go for Xen or its own
microkernel, respectively (maybe preferable over Virtualbox).

Am I reading too much into it? Would it be worth diving deeper into
AtmanOS' sources? Any thoughts, comments?

Thanks,
Rolf

[1]

[2] https://atmanos.org/talks/go-without-the-os-gophercon-2016
[3] https://atmanos.org/
[4] https://github.com/atmanos/atmanos

[Josef Söntgen]

Hello Rolf,

Post by Rolf Sommerhalder
After following the threads about Golang on Genode and reviewing
AtmanOS, I suspect that AtmanOS could facilitate bringing Go to
Genode, for example by making AtmanOS target Virtualbox in addition to
Xen (maybe not so elegant), or by adapting/replacing AtmanOS'
microkernel with Genode, and porting the Go runtime, standard library
and system packages that AtmanOS wrote in Go for Xen or its own
microkernel, respectively (maybe preferable over Virtualbox).
Am I reading too much into it? Would it be worth diving deeper into
AtmanOS' sources? Any thoughts, comments?

It definitely looks interesting wrt to investigating how much
infrastructure the current Go runtime needs or rather on what
functionality from the underlying system it depends. So diving
into the source code would be worthwhile indeed. It still stands
to reason how to properly wrap the Genode's C++ API, though.

Regards,
Josef

[Taru Karttunen]

Post by Josef Söntgen
Hello Rolf,

Post by Rolf Sommerhalder
After following the threads about Golang on Genode and reviewing
AtmanOS, I suspect that AtmanOS could facilitate bringing Go to
Genode, for example by making AtmanOS target Virtualbox in addition to
Xen (maybe not so elegant), or by adapting/replacing AtmanOS'
microkernel with Genode, and porting the Go runtime, standard library
and system packages that AtmanOS wrote in Go for Xen or its own
microkernel, respectively (maybe preferable over Virtualbox).
Am I reading too much into it? Would it be worth diving deeper into
AtmanOS' sources? Any thoughts, comments?

It definitely looks interesting wrt to investigating how much
infrastructure the current Go runtime needs or rather on what
functionality from the underlying system it depends. So diving
into the source code would be worthwhile indeed. It still stands
to reason how to properly wrap the Genode's C++ API, though.

Typically C++ APIs are wrapped in Go with a thin wrapper of C++
extern "C" functions that also translate such exceptions into
errors. SWIG can do this in theory for Go, but in practice
doing it by hand or quick scripting tends to be easier unless
deep class hierarchies are involved. The wrapper functions
are then called from Go with cgo.

They tend to look like:

extern "C" myerror_t libfoo_baz(baz* ptr, int arg, foo* ret) {
try {
*ret = ptr->bazbaz(arg);
return noerror;
} catch(...) {
return errorcode;
}
}

If lots of templates are involved then things become somewhat harder.

- Taru Karttunen