mmap implementation for ANON mapping with desired address

[Josef Söntgen]

Hello Alexander,

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.

and furthermore

* 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
  run-time?

  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.


Regards Josef

-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20201203/05ab9b2f/attachment.sig>