mmap implementation for ANON mapping with desired address
josef.soentgen at genode-labs.com
Thu Dec 3 16:51:01 CET 2020
as predicted I am back with some questions.
First, thanks for your efforts of bringing Golang to Genode. I took a
look at the commits on your topic branch and your README was very
helpful in getting started; especially the current limitations section
reflects questions I am going to ask. Please bear with me if some
questions sound obvious but I lack the understanding of the inner
workings of Golang's run-time and I did not follow all your previous
E-Mails on the ML.
So, I checked out your 20.11 branch and tried to follow your instructions.
Unfortunately, I could not compile libgo out-of-the-box because libtool
was complaining about “unrecognized options” and I stopped at this point.
This brings me to my first question
* Is there a technical reason for executing the auto-tools build system
rather than porting the libraries, i.e., create the .mk files for
Genode's build system?
The instructions in the README lack the motivation behind that decision.
* Is it strictly necessary to solely produce static libraries or could
we get away with a dynamic shared-object, libgo.lib.so, that incorporates
everything and the target application is linked against or is it possible
to have multiple shared-objects. After all, there is already a libffi port
- ffi - that is built as .lib.so.
While stepping through the libgo commit I noticed the patches:
* You choose to add a new run-time target, “inno”, that is based on NetBSD
rather than using the existing FreeBSD target. For all intents and
purposes, Genode appears to be FreeBSD for ported software due to using
its libc¹. Is there a reason why that is not possible for Golang's
IIRC, on some platforms, e.g. Solaris(?), the normal Golang run-time
solely uses the libc to interface with the OS instead of wrapping
system-calls directly. Is it the same with gccgo's run-time?
With regard to the first questions, if we remove auto-tools from the
equation we could shadow specific run-time parts where the upstream
implementation does not work on Genode.
¹) Granted, our libc port is not feature-complete and might lack
expected functionality, e.g. kqueue/sysctl or as you already
noticed mmap handling, but we could take this as an opportunity
to extended our libc port.
* I noticed that you use internal headers for implementing the stack
handling. Is in this context the available Genode::Thread API not enough?
My somewhat naive point of view would be to use our POSIX layer wherever
possible and only diverge where necessary - that only boils down to
go-routine and stack handling or does it not?
Finally, the most important question:
* From what I can tell the port itself still somewhat feels like a
proof-of-concept that as you mentioned in the README is the side
result of a research project. It would require further clean-up
before we could add it to Genode.
(This includes the current short-comings like missing context
support for go-routines, reliance on -fno-omit-framepointer,
etc. The support code that is currently part of the component
should be moved to a central location like you already suggested.)
Would you be willing to do that clean-up work or is it from your
point of view enough to just keep the port as an example in case
somebody else wants to do that? Your reaction so far, creating
the github issue, suggest that you do have some motivation.
I ask because in the past we got a welcome one-time contribution
for Rust support on Genode. However, since we do not use Rust, we
merely dragged it along and eventually removed it². As support for
Golang has no immediate priority for us, we hesitate to spend our
limited time on this at the moment.
That being said, I wrote our CI-tools web front end in Golang and
running it on Genode certainly would be nice and could be a reason
to nonetheless set some time aside to get that up and running :-).
Judging by the reaction on your issue, we could very well make a
community effort out of supporting Golang.
²) To not make the same mistake I imagine adding support to our
tooling for creating Golang based components is necessary.
Maybe it is worthwhile to extend 'goa'[sic] in that regard so
that a Golang-developer can use 'go' to initially develop his or
her application and later one use 'goa' to create a binary for
Genode, while 'goa' does the heavy-lifting behind the scenes.
I think you briefly touched the “go build → Makefile” topic in
one of your mails. After all, rather than writing specific
Genode components in Golang I guess people want to deploy their
existing applications first and would be fine with interacting
with Genode via the POSIX/VFS layer.
http://www.genode-labs.com/ · http://genode.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the users