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
On Tue, Mar 29, 2016 at 08:45:39PM +0000, Petar Stupar wrote:
- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
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
Hi everyone,
Emery thank you for your input.
On Wed, Mar 30, 2016 at 12:28 AM Emery Hemingway <emery@...261...> wrote:
On Tue, Mar 29, 2016 at 08:45:39PM +0000, Petar Stupar wrote:
- 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.
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.
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 genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello again,
Norman thank you for this insight.
On Thu, Mar 31, 2016 at 8:46 AM Norman Feske <norman.feske@...1...> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
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 genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Regards, P.
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
On 29.03 20:45, Petar Stupar wrote:
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
-
Emery -
Emery Hemingway -
Norman Feske -
Petar Stupar -
Taru Karttunen