DragonFly kernel List (threaded) for 2005-05
Re: cvs commit: src/sys/i386/include tls.h src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc34/cc_prep/config/i386 dragonfly.h src/lib/csu/i386 crt1.c src/lib/libc/gen tls.c src/lib/libc/i386/sys cerror.S src/lib/libc/include libc_private.h ...
:That's an ABI nightmare. It means the userland can't *ever* change %gs
:to something other than a TCB in the DragonFly format. Yes, I can think of
:valid uses like wrappers around foreign code (e.g. flash plugin, win32 code).
First of all, it's a pipe dream to hope that one can simply run a
third party binary-only module in a native DragonFly environment
without an emulation wrapper around it. Secondly, I am not about to allow
third parties who don't provide source code to dictate what we can and
cannot do in our operating system.
For DragonFly-native code, %gs is only used a certainly way, period.
Otherwise how do you expect us to be able to support TLS ? TLS
address lookups absolutely require that we have full control over the
For kernel-use of the TCB, i.e. for a signal critical section... well,
the kernel doesn't actually have to look at %gs. It can simply look
at the address programmed via sys_set_tls_area(). No third party
code will ever make that system call. It's a DragonFly-specific call.
For that matter, if we really wanted to, we could have cerror call
sys_get_tls_area() to get the TCB pointer rather then assume that
%gs points to it. Personally, however, I believe that a clear
distinction must be made between 'native' and 'foreign' and that for
anything 'native' we should be able to assume that %gs is set to something
So what it comes down to is there is DragonFly native stuff, and
there is third party emulation stuff, and they have to be considered as
two separate entities.