On 06/11/15 19:35, Robert Gifford wrote:
Good Afternoon,
We are in the process of porting RK to a new host platform and have run
into a few problems with thread local storage and segmentation in
general.We do not want to use segmentation in our system and have thus far
been reimplementing anything in RK that access the gs register.
Our modifications thus far have included removing thread local storage
within
libbmk_core/sched.c and librumprun_base/_lwp.c
Our most recent issues have been due to errno access within src-netbsd.
Those files belong to the Rumprun unikernel, not rump kernels.
Before we move forward, we were curious to know if there were build options
to disable segmentation in RK? As of now, we can still continue to move
forward if this is not a possible, however it is always nice to save a bit
of time.
Let's clarify a few things, mainly the difference between rump kernels
and the Rumprun unikernel.
Rump kernels are intended as a framework. That intent means that if
someone has problems in adapting rump kernels to their needs, we'll try
to make it simpler for them.
The Rumprun unikernel is not intended as a framework, except in the
sense of one for running applications -- posix or raw syscalls -- on top
of it. Rumprun is intended to support applications which use __thread,
so it must be supported, no way around that.
It sounds to me like you're porting Rumprun, not rump kernels.
(besides, I don't think rump kernels are "ported" so much as "used" --
if you have to port rump kernels, it means that they failed as a framework)
Rump kernels do not use thread local storage unless you ask them to
(CURLWP=__thread). Technically, a rump kernel should never use
__thread, but using TLS for curlwp gives a very measurable performance
boost, so I bent the rules there with an option.
Rumprun does not explicitly use %gs, though it does use __thread. The
compiler generates the accesses to %gs (on x86, at any rate). If you
want __thread to do something else, you also have the option of patching
the compiler. It's not very convenient, I'll grant you that, but not
wanting to use the mainstream practise never is.
You're of course welcome to further expand your motivations and
intentions, and maybe then we can work something out.
