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] https://www.youtube.com/watch?v=F2Ls6xZdSrE [2] https://atmanos.org/talks/go-without-the-os-gophercon-2016 [3] https://atmanos.org/ [4] https://github.com/atmanos/atmanos
Hello Rolf,
* Rolf Sommerhalder <rolf.sommerhalder@...278...> [2017-05-25 19:59:34 +0200]:
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
On 31.05 14:33, Josef Söntgen wrote:
Hello Rolf,
- Rolf Sommerhalder <rolf.sommerhalder@...278...> [2017-05-25 19:59:34 +0200]:
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
-
Josef Söntgen -
Rolf Sommerhalder -
Taru Karttunen