Hello Josef,
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? So, you want to keep FreeBSD structure and related functions by replacement of the code inside old infrastructure to direct switch ones? See some doubts below (except some potential problems related to «native» FreeBSD infrastructure, as mentioned in previous letter). Note: Under "worse performance" I mean that current FreeBSD borrowed code assume context switch to kernel and back for every get/set context. In theory, we can call native context-switching functions from underlaying kernel (while it will be unique for every kernel, no common code). I don’t like this approach as non-portable. And I still have these questions to be answered to move further: 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><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. the problem that this family together with headers and ucontext structure is a part of general libc. how I can mask its usage, e.g. in configure scripts? I potentially need to install / modify part of files installed by libc, Eg signal.h from libc (include/libc/signal.h) do include #include <machine/ucontext.h> #include <sys/_ucontext.h> and it is not clear for me how to mask existing files if I have 3-d party application (not mine which can include own ucontext.h in repos/world ), e.g. in repos/ports? It I replace header search path - it will be complex mix of native FreeBSD-esh headers from Genode, own application code and my world replacement code for *context... Another problem that setcontex/getcontext should be called on the same nested level, you can’t put easily wrapper above them (stack should be restored correctly). Due to specific of Genode we have another potential problem - we can’t use standard malloc() for stack allocation because stack should be from specific memory area to allow context switch, so, external packages compatibility will be limited anyhow. By the way, what is a reason for this? it is relatively fast and easy to make a separation between «main» and «other» threads using, e.g. registry... And, last but not least - setcontex/getcontext should store and restore signal context (including signal handlers) which is not that clear for me in Genode. Currently is is limited, and where it should go later? how we can store/restore state of signals for current thread? So, returning back. I can try to put everything in *context with uniq name (replace original files and function names) into world repo, and force libgo to call these function. Anyway, any other software porting will require manual efforts mainly because of old/rest of headers from libc. And I still need to patch part of libc related to anonymous memory mapping. Updated implementation for libc 21.02: https://github.com/tor-m6/genode/commit/c64bfeeba6e8cca4376636bdd2e9e8bbf3aae1cc
_______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
