Hello Alexander,
as a base I borrow some code from glibc, and remove related files (mostly _ucontext.h/ucontext.h) from genode
May I ask what is the reason for choosing and incorporating the glibc implementation rather than using/enabling the one in the FreeBSD libc?
- current implementation of context switch in FreeBSD done completely
in kernel via sys call. E.g. this is full code of getcontext function (stored in genode, not used):
[…]
- context family support do require complex and misleading structure,
e.g. take a look for setcontext code:
[…]
- ucontext.h and related is isolated in current libc and could be
easily replaced (because it used only in *context family of functions and signals which has only rudimentary support
- glibc implementation is straightforward and well supported,
relatively small and suitable for big set of platforms, without complex kernel/__libc_interposing analogous and could be borrowed (copied) with minimal efforts, I can confirm this.
- glibc implementation of these functions do contain potentially
useful security feature of shadow stack support (under SHSTK_ENABLED define - not enabled in my patch)
So, I consider option to use existing freeBSD version and replacement of code of functions to ones from glibc - and think that this make everything too complex, related infrastructure not clear and not easy to support. May be I am wrong.
for me simplest for implementation and, especially, for future support
- is chosen approach (with part of glibc port). It is simple and
straightforward, easy to extend to arm/etc.
Another option I consider is a usage of native context-switch functions for genode low level Os (OS - dependent). Anyway, it will significantly lower performance, and not portable option, so, I do not choose it.
Strictly speaking containg such a large patch makes the commit unsuitable for the Genode main repo as the burden of maintaing it falls on our shoulders at the end and the reason for including it in the first place is not immediately clear.
significant part of patch is a removal of old files like ucontext.h and plain addition of new files, take a look for statistics, no complex updates of files involved:
[…]
By the way, I can make patch smaller if you give me a direction how to remove some files during install or patch process without patch itself, may be via .mk file (e.g. libc-gen.mk)
Thanks for the thorough answer, which puts things into perspective. We briefly discussed the matter offline and somehow implementing the API with a mechanism that is already there (e.g. the setjmp/longjmp based task model that we use in various drivers and the libc) feels more natural. That being said, we do not know if there are any requirements in the *context API that would prevent us from going down that road.
Do you know of any, besides the potentially worse performance?
For better or worse, we still lack the resources (read man-power) as well as a deeper understanding for the issues at hand when it comes to the requirements of the golang-runtime (which somewhat is a consequence of the lack of resources) that such an undertaking arguably deserves.
I need *context() implementation, and it can’t be moved to world repository - its a part of libc.
Also to use functions I need C interface for allocate_seconday_stack() which should be somewhere inside (I choose libc dummies.cchttp://dummies.cc file) Question: may be better other place? e.g. inline C interface function as a part of e.g. thread.h? Any recommendations are welcome!
I understand your point, so, another question is: how I can continue if patch can’t be stored inside genode core? it can’t be significantly smaller (4 functions/files to be add at least)...
Everything else for golang support I will have in world, this is the only part of core (may be together with extended anonymous mmap support).
Judging by the freestanding nature of the '*context()' implementation should it not be possible to get away with putting it into world as well? For example as part of a supplementary static run-time library that shadows the libc by resolving everything locally, including the stack functions.
Regards Josef