Golang on Genode: a follow-up

[Josef Söntgen]

Hello Wenbo,

TL;DR nothing has changed in regards to Go on Genode AFAIK but as a
      first step it might be worthwhile to check how well gccgo in
      our toolchain works if at all.

* Wenbo Xu <wenboxu.cn at ...2...> [2017-03-03 16:16:41 +0100]:
> I’m also trying to implement something on Genode. I noticed there is
> already a discussion about this issue one year ago:
> https://sourceforge.net/p/genode/mailman/message/34975818/
> <https://sourceforge.net/p/genode/mailman/message/34975818/>
> 
> Since it is already a long time, I’m wondering if there is any latest
> news about that. To be more specific:

Since those questions are somewhat general but the last one I will
also answer them this way as well.

> 1. What is the amount of effort, to port existing program or library
>    to Genode, or implement something new in Genode?

That depends on the requirements/dependencies of the to be ported
software and therefore a general statement is difficult. POSIX programs
that mostly depend on the libc and have none or minimal dependencies to
kernel specific features, e.g. epoll(2) or kqueue(2), are fairly easy to
port. The same goes for libraries that are used in this context.
However, if the library is going to be used in a Genode Component that
provides a service to other components and still depends on the libc it
is a bit more laborious (calling into the libc within such a component
needs to be explicit). On the other hand, the effort of writing a new
Genode component from scratch depends on the functionality this
component requires. Writing a driver for a simple device might be easier
than porting one but writing a component that makes some network
protocol accessible that, for obvious reasons, needs code that handles
the protocol involves implementing such functionality from scratch or
you end up porting a existing library.

In case of porting Go based software I would imagine that it is pretty
straightforward and you do not have to alter the code at all because
most of the platform specifics are handled at Go's runtime and standard
library. And it is the same for new programs. That being said, last time
I looked into the runtime is some years ago; things might have changed.

> 2. Is there any reason, that I should not use Genode? (Re-asked).

Again, that really depends on your requirements or your use case in
general. It would be nice if you could ask this question in more
concrete way.

> 3. Is there any guidelines, principles, rule of thumbs, good and bad
>    experiences to use Go on Genode?

Well, none of us (core) developers actually took a shot at making Go
available on Genode so far. I know of some community efforts to make
it available (those, that were already discussed on this mailing list)
but I do not know how far those efforts have progressed by now. There
is, however, the GCC Go frontend enabled in our toolchain. Then again
none of us has used it so far and I do not know how useable it actually
is (seeing that it implements Go version 1.2 I am not sure how benefical
it is nowadays). So, for this matter, from a practical point of view
I would say you cannot use Go on Genode currently which renders this
question somewhat unanswerable.

Since by now most parts of the runtime seem to be written in Go instead
of C, we probably would need a newer version of gccgo to bootstrap the
actual Go compiler and runtime anyway. We are going to update our
toolchain soon and will, if it is feasible, probably keep the Go
frontend enabled. That might be a better starting point to get a
“proper”, more update to date Go version enabled on Genode besides
evaluting if the potential stopping blocks, e.g. TLS, still stand.
Again, if someone from the community (it is also featured on our
challenges [1] page) wants to tackle it, we are happy to lend a helping
hand.


Regards
Josef

[1] http://genode.org/about/challenges

-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/