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? > > 1. 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):
> […] > 2. context family support do require complex and misleading structure, > e.g. take a look for setcontext code: > […] > 3. 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 > > 4. 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. > > 5. 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.cc<http://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 -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/
signature.asc
Description: PGP signature
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
