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@...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