On 07/11/15 18:24, Gabriel Parmer wrote:
We are OS developers and have a system (composite.seas.gwu.edu) we've been working on for quite some time. We'd like to execute Rump Kernels (RK) in that system. The environment in which we want RKs to execute is user-level, and uses the system calls of our system to provide many of the services necessary within the rumpuser interface.
Sounds cool. Can you give a two sentence summary of composite?
Our initial plan was to simply implement a library that exports the rumpuser interface. However, as we went through the bmk rumprun unikernel, we found that we could simply reuse quite a bit of that code, while porting some key functionality (context switch, memory image allocation, interrupts, etc...). The fact that the rumprun environment was already somewhat general, supporting both bmk and Xen, also factored into our decision to add a new "architecture" to it, rather than use a clean-slate approach.
In the new terminology world order, bmk is the MI+MD "OS" which supports both hardware and Xen.
Anyway, let me just summarize (both above and what I didn't quote "below") so that you can check if I understood what you're saying.
You have ported bmk to "composite", rewriting various bits which were not suitable for your case. Now you want uses of __thread to suit your system better.
Hopefully this provides some context. However, if there is no pluggable library-supported TLS, then it seems like the resolution is to 1. support the use and modification of %gs, or 2. port each part of the system, and each application to use our own TLS facilities. Is this an accurate assessment?
If you can get the compiler/linked to generate __tls_get_addr() for TLS access, AFAIU you can just change bmk_platform_cpu_sched_settls() to do whatever corresponds to your __tls_get_addr()?
I'm still not 100% sure of what kind of change you propose to bmk. What's confusing me is that you've been porting and changing various bits, but now don't want to change various other bits.
