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 ...

[Matthew Dillon]

: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).
:
:Joerg

    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
    TCB.

    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
    sane.

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>