Golang on Genode

[Petar Stupar]

Hi everyone,

I'd like to be able to write servers and clients for Genode in Golang. I
believe this is currently possible only through gccgo (as I see go is
supported by Genode tool-chain) but I'd like to be able to use the native
compiler and all of its standard library.

I don't think this would be a hard task albeit a bit more involved.
First I'd need to port and build an older Golang tool-chain (version 1.3 or
1.4, not sure which of the two is the latest possible) and then bootstrap a
newer one. Does this sound about right?

What my questions/concerns are:

1. Has there been any previous work done on this or in this direction?
2. Is there any reason why Golang wouldn't be a good choice as a language
on top of Genode? Although this seems to me as a very intuitive combination
perhaps there are concept/security issues I might have overlooked.
3. Is there any work work being done or work that has been planned already
to be done on Genode which could influence the Golang port and it's
standard library? I've gone through the Road Map and several things popped
out to me which might have some influence like cross-kernel binary
compatibility and work to be done on networking stack.
4. Would adding Golang programs into the mix be an issue for the build
system? The Genode build system is such a powerful feature and I'd like to
think it will be easy and quite natural to integrate it with Golang's build
system too, but maybe I'm wrong.

I'd be very grateful if I could hear your thoughts and pick your brains
before I start. Any suggestions and comments are very welcome.


Regards,
Peter

[Emery Hemingway]

Post by Petar Stupar
2. Is there any reason why Golang wouldn't be a good choice as a language
on top of Genode? Although this seems to me as a very intuitive combination
perhaps there are concept/security issues I might have overlooked.

As someone who has written a fair amount of Go and is familiar with
some of the Genode interfaces I would say that it could be a quite alot
of work to bring enough of the Go standard library into working order.
I think it would require generating C bindings to Genode and then Go
bindings those (keep in mind Go doesn't have macros). For things like
files and network you could use the libc, but then there would be an
abstraction layer on both the Genode side and the Go sides of libc.

That said I would be happy if Go worked, but to me it would be too much
effort to port enough of the standard library to make Genode a viable
platform for a lot of existing Go programs. I came to Go from Plan 9
and think it would hard to leverage the flexibilty of Genode with a
language so strongly influenced by unix.


Good luck,
Emery

[Norman Feske]

Hello,

Post by Emery Hemingway
That said I would be happy if Go worked, but to me it would be too
much effort to port enough of the standard library to make Genode a
viable platform for a lot of existing Go programs. I came to Go
from Plan 9 and think it would hard to leverage the flexibilty of
Genode with a language so strongly influenced by unix.

whereas I don't know whether or not Go would be good language to write
Genode components in, I think that the ability to run Go programs
directly on Genode would be very interesting. For example, the custom
applications by Inversepath (e.g., for file encryption) for the USB
Armory are written in Go. Right now, we need to run them on top of
Linux on the USB Armory. With Genode supporting Go directly, we could
eventually move those applications to the Genode world.

On a technical level, I have a question though: As far as I know, the
Go tool chain produces statically-linked binaries. Is this mandatory
or is it possible to produce position-independent code (to be loaded
by a dynamic linker) as well? I ask because I'm planning to move
Genode's kernel-specific code into the dynamic linker and keep the
actual applications and libraries kernel-agnostic. If Go executables
must always be statically linked, this concept wouldn't work for such
programs, which would be unfortunate.

Cheers
Norman

- --
Dr.-Ing. Norman Feske
Genode Labs

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

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

[Petar Stupar]

Hello again,

Norman thank you for this insight.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,

Post by Emery Hemingway
That said I would be happy if Go worked, but to me it would be too
much effort to port enough of the standard library to make Genode a
viable platform for a lot of existing Go programs. I came to Go
from Plan 9 and think it would hard to leverage the flexibilty of
Genode with a language so strongly influenced by unix.

whereas I don't know whether or not Go would be good language to write
Genode components in, I think that the ability to run Go programs
directly on Genode would be very interesting. For example, the custom
applications by Inversepath (e.g., for file encryption) for the USB
Armory are written in Go. Right now, we need to run them on top of
Linux on the USB Armory. With Genode supporting Go directly, we could
eventually move those applications to the Genode world.
On a technical level, I have a question though: As far as I know, the
Go tool chain produces statically-linked binaries. Is this mandatory
or is it possible to produce position-independent code (to be loaded
by a dynamic linker) as well? I ask because I'm planning to move
Genode's kernel-specific code into the dynamic linker and keep the
actual applications and libraries kernel-agnostic. If Go executables
must always be statically linked, this concept wouldn't work for such
programs, which would be unfortunate.

This is exactly why I needed to ask.
It is possible since 1.5 version via "-buildmode=c-shared" flag. It can
even export packages as static libraries as well as shared objects that can
be linked into C programs.
Gccgo on the other hand has had a limited corresponding option.

Unfortunately I'd need to build 1.4 version first so that it could
cross-compile later versions (1.6 is current). Since 1.5 version of Golang
most of C code has been replaced by go code.

I'll see if I can make a couple of tests during the weekend and will get
back to y'all.

Cheers
Norman
- --
Dr.-Ing. Norman Feske
Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlb8wlwACgkQQwppp8aV4siiTwCfQf1ZG5biK/k+/N9j3dhPRxen
vwUAnjqhg+oc3qUlbpV1DHaQ1oPYrsHj
=rXt8
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

Regards,
P.

[Petar Stupar]

Hi everyone,

Emery thank you for your input.

Post by Petar Stupar

Post by Petar Stupar
2. Is there any reason why Golang wouldn't be a good choice as a language
on top of Genode? Although this seems to me as a very intuitive

combination

Post by Petar Stupar
perhaps there are concept/security issues I might have overlooked.

As someone who has written a fair amount of Go and is familiar with
some of the Genode interfaces I would say that it could be a quite alot
of work to bring enough of the Go standard library into working order.
I think it would require generating C bindings to Genode and then Go
bindings those (keep in mind Go doesn't have macros). For things like
files and network you could use the libc, but then there would be an
abstraction layer on both the Genode side and the Go sides of libc.

I was thinking about this. I'm not sure if this double abstraction would
make programs significantly more slower. I guess I'd have to make a couple
of test to see if this would pay off.

Post by Petar Stupar
That said I would be happy if Go worked, but to me it would be too much
effort to port enough of the standard library to make Genode a viable
platform for a lot of existing Go programs. I came to Go from Plan 9
and think it would hard to leverage the flexibilty of Genode with a
language so strongly influenced by unix.
Good luck,
Emery
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Emery]

Even if compiling legacy Go programs is difficult, having
the Go standard library for native applications would be
nice, especially the TLS stack and cryptographic stuff.

I seem to remember that the problem with the Go runtime
had to do with platform threads and Go routines.

Emery

[Taru Karttunen]

Post by Petar Stupar
I'd like to be able to write servers and clients for Genode in Golang. I
believe this is currently possible only through gccgo (as I see go is
supported by Genode tool-chain) but I'd like to be able to use the native
compiler and all of its standard library.

Hi,

The hardest part for porting the go tool chain is that it really wants
fast access to thread local storage. In addition Go has M:N threading
(go-routines) and moves the go-routines with their stacks from one
physical thread to others quite commonly.

Providing fast thread local storage on x86 with moving stacks can be
quite complex on Genode with various kernels.

- Taru Karttunen


------------------------------------------------------------------------------