mmap implementation for ANON mapping with desired address

[Alexander Tormasov]

So, far we have decided that some restructure needs to be done: we will move most of it to genode-world. Also, we will take a look at the context-related functions. Do you think porting

tor> ok. while question - how to call «configure» from it? the main reason why I make it inside «port/noux» - it allow to call configure from target.mk. I am against approach to extract list of files and compile them. This operation need to be done every new version of soft to be port release… IMHO this should be as seamless as possible, best of all involve original build environment.

 some existing libraries, like libpcl or boost.context will do the trick?

tor>
Sorry for not knowing - but seems that libpcl is a kind of image processing library using boost?

about boost.context. In general, I think that it will be good to have it ported.
but for particular go runtime I see here 2 problems

1. go runtime directly call getcontext/setcontext/makecontext (not call swap context, as I remember), so their semantic need to be emulated exactly. At least, related to «kernel» signals (get/setsigmask). And, important, need to create stacks for threads to be switched from dedicated area of Golang (not as it implemented in boost.context via standard heap)

2. boost do require C++ specific initialisation which also need to be called during construction before C main() which is called from golang runtime. It could have some limitations/tricks. E.g. too many unnecessary C++ internal functions/code will be linked to the executable, and/or tricky sequence. Typically such «rich» library hard to split and port partially, I doubt that boost porting is a separate complex task tightly bounded to the compiler version/llvm/etc.


> 
> @Jozef, should we create issues in the genode-world repo?
> 
I created one single issue about golang port - may be we need separate ones for components to be kept in main repo (outside of world)
may be it worth to move this discussion here?