Porting GO to Genode

General
1

I’d like to run Syncthing on my Sculpt natively to use it as a NAS.
The Syncthing is ans awesome file sharing solution, but unfortunately it written in GO :pensive_face:

So in order to port it to Genode I have to port GO first.
And this is what I’m playing around currently.

I plan t use this topic to report my progress and to leave some useful notes and hints.

I use Claude to learn, investigate and try things, so some vibe coding is used.
Will see were this journey will lead me. :rocket:

1 Like
2

First findings to note so far:

  1. Apparently there’s outdated and stale gccgo, that is stayed behind the official GO specification some years ago and is currently in a maintenance mode. I don’t see a feasibility to update it and reimplement all the new features to just trying to keep up with the GO development. Not an option :cross_mark:
  2. Another option is to extend GO to the genode platform leveraging it’s POSIX layer. I don’t see a value to implement and support hacks and workarounds to make it fully POSIX (unix=true) compatible. Too much efforts for something that is not natural in Genode :cross_mark:
  3. And finally an option is to extend GO to the genode platform utilizing Genode API directly + reusing some POSIX (unix=true) implementaions. This is the most promising and least effort way so far :check_box_with_check:

So I’m currently trying to implement the option 3 :+1:

1 Like
3

I managed to build some minimal executable and run it in goa testbead with many issue so far, currently trying to resolve them.

One of the issue was connected with the necessity of RM session for GO.
And apparently the Goa testbed is not configured to provide RM sessions out of the box.

So in order to make it work I did this runtime patching:

  1. Start the goa_testbed Preset
  2. On default FS in /depot/jschlatov/pkg/goa_testbed/2026-04-16/runtime add + rm node as a child of + requires node
  3. In /model/deploy add + rm | + parent node as a child of + connect node under + child goa_testbed node.
  4. Restart goa_testbed component

Now all your test runs will be able to obtain RM sessions.

1 Like
4

Apparently there’s a mismatch in maximum threads count.
Go allows to have 10000 threads, while Genode is capped in 250 per component.

This is not an issue for the most common case of FS operations, since Genode VFS is asynchronous there’s no need to park a thread for an otherwise synchronous file operation.

But this puts a limitation on CGO usage, meaning apps requiring C would not build. And the ones that have CGO as optional might run a bit slower and heavier in some cases without it.

Implementing CGO support would require a POSIX libc implemented, that I’m trying to avoid for now (too much efforts to implement it and to make it fully compatible with Genode)

Other possible thread-heavy use cases are either irrelevant for Genode or very rare to happen.

So I’m proceeding with CGO_ENABLED=0 for now leaving CGO_ENABLED=1 challenge for future…

5

That’s an exciting project. I’d be very interested in using a few Go-based applications on Genode as well.

I’m not familiar with Go at all and thus am curious to learn more about it. The cgo part raised my interest in particular. If I understand it correctly, Go is independent from a C runtime but requires it to link against C-libraries. Have you had a look at existing Go projects and their dependence on 3rd-party C-libraries (and therefore their dependence on cgo)? If it turns out that most interesting Go projects require cgo anyway, it might be easier and more maintainable to directly use Genode’s libc and improving its POSIX compliance where needed.

6

I’m not an expert in GO either, but what I learned while researching this topic on a high level is:

  • GO compiles into a native platform statically linked binary using the supported platform implementations. E.g. libc for POSIX, something custom for plan9, Windows (and I’m trying to add Genode now)
  • Most of the GO projects stay “pure GO” and use only GO libraries dependencies.
  • CGO is optional for use when someone wants to squeeze out max performance by directly calling libc (or other c libs) functions. So portable development way is to use CGO when it’s available and fallback to pure GO when it’s not.
  • Though some projects are built without fallbacks and require CGO.
  • Gemini estimates that 87% of all projects written in pure GO, 8.1% with light CGO usage for some isolated tasks, and 3.2% with heavy CGO usage (massive, infrastructure-level software or heavy database/graphics wrappers)

In particular Syncthing is able to compile and run without CGO, and this is my first goal with GO port at the moment :slight_smile:

1 Like