DragonFly BSD
DragonFly kernel List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 12 May 2005 18:58:37 +0200
Mail-followup-to: DragonflyBSD Kernel <kernel@crater.dragonflybsd.org>

On Thu, May 12, 2005 at 09:04:05AM -0700, Matthew Dillon wrote:
> :Well, the same block used by the syscall layer could be used here too.
> :It has to be thread-local [thread-index is not an option, there can be
> :an arbitrary high number of threads]. TCB is not good, the kernel sohuld
> :not depend on %gs mappings of userland programs.
>      I don't see why not.  It makes a lot of sense to integrate the TCB
>      requirement into the kernel.  The format is already under our
>      strict control.  The kernel itself would not require the TCB, but
>      the RTLD already does (to support __thead declarations), and the
>      syscall layer certainly could too.  The kernel could easily set up a
>      minimal TCB/%gs automatically on program start if that were deemed 
>      necessary.

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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]