Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Nov 2000 16:00:11 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        arch@FreeBSD.org, Arun Sharma <arun@sharmas.dhs.org>
Subject:   Re: Thread-specific data and KSEs
Message-ID:  <Pine.SUN.3.91.1001122154225.18052A-100000@pcnet1.pcnet.com>
In-Reply-To: <XFMail.001122123415.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Nov 2000, John Baldwin wrote:
> On 22-Nov-00 Daniel Eischen wrote:
> > On Mon, 20 Nov 2000, Arun Sharma wrote:
> >> Linux threads implementation uses %gs to store a pointer to
> >> the thread structure. A segment register can only be loaded
> >> with a selector that points to a valid entry in a LDT or a GDT
> >> on x86.
> > 
> > Hmm, OK.  So if I initially load the LDT with entries (they
> > don't have to point to anything unless I want to really
> > use gs to point to something), then I can use gs.
> 
> Entries in the LDT have to point to something, that's all they can do.  You
> could in theory make them all be zero length or some such, but you might need
> more thread-local storage than a single 16-bit integer that would require 4k of
> backing store to avoid causing seg faults.  If each KSE has its own LDT, on the
> other hand, then you can use a fixed entry in the LDT to point to the
> thread-local data (so that %gs doesn't have to change) much like we do for
> per-CPU data with %fs in the kernel.  You can then use stuff similar to
> machine/globals.h to access each variable in the threaddata struct.

I only really need KSE specific data, since each KSE _always_ knows
what thread it's running.  When a KSE wants to run another thread, it
just changes the thread ID/pointer in the KSE specific data.  So CURTHREAD
(or _thread_run for those of us that have fiddled with libc_r) would
just be CURKSE()->ksd_curthread.

If I use the value of %gs (probably %gs>>3 - 17) as an index into
a global table of pointers to per-KSE structures, then I need not
worry about what is in the LDT, as long as it is valid.  I wrote
a simple test program to load the remaining LDTs with the same
values as the LUDATA_SEL LDT, and this seemed to work nicely.

I'll definitely check out your suggestion of using different entries
in the LDT for each KSE.  Initially, it might make it easier to use
%gs as a simple index, so it is easier to validate the entry when
debugging the implementation.

Thanks,

-- 
Dan Eischen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1001122154225.18052A-100000>