1:N threading

[Daniel Eischen]

On Fri, 4 Apr 2003, Julian Elischer wrote:
> On Fri, 4 Apr 2003, Peter Wemm wrote:
> 
> > Daniel Eischen wrote:
> > > On Thu, 3 Apr 2003, Peter Wemm wrote:
> > > 
> > > > Daniel Eischen wrote:
> > > > 
> > > > > The patches are available:
> > > > > 
> > > > >   http://people.freebsd.org/~deischen/libpthread.diffs
> > > > > 
> > > > > FYI, since this is a new mailing list, the above changes
> > > > > are meant to give libpthread M:N capability.
> > > > > 
> > > > > I don't need testers; I have enough bugs that I know about
> > > > > to fix.
> > > > 
> > > > +	__asm__("movl %%gs, %0" : "=r" (id));
> > > > +	id >>= 3;
> > > > +	if (id - NLDT < 0)
> > > > 
> > > > There is a problem here, NLDT is kernel private and changes depending on
> > > > things like whether SMP is enabled or what the maximum number of cpus
> > > > is.
> > > > 
> > > > You're trying to find if its a local or global selector, right?
> > > > What you really want is bit 2 which tells you which it is.
> > > > 
> > > > #define ISLDT(s)        ((s)&SEL_LDT)   /* is it local or global */
> > > > #define SEL_LDT 4               /* local descriptor table */
> > > 
> > > OK, but if NLDT is kernel private, how do can I know
> > > what LDTs I can use as local?
> > 
> > Whoops.  I misread NLDT as NGDT.
> > 
> > Gah.  We're doing some crufty stuff here.  For starters, we're running
> > userland on a LDT for %cs and %ds/es/ss/etc.  We really should be using a
> > GDT slot for those.  Most of the other stuff there is for the a.out
> > "lcall 7,0" instruction and for BSDI's version of the lcall stuff.
> > 
> > The i386_[gs]et_ldt() syscalls really should have a way of reporting what
> > is available for use.
> 
> What we SHOULD be doing is setting an LDT entry to point to the 
> mailbox (puts some constraints on the mailbox but..) of each upcall
> and setting %gs to teh appropriate entry before returning to userspace.

Well, we can do it just fine from userland and are doing it
right now.  The kernel doesn't really need to...  But, if
you want to do that, let's think about the interface and
see if it makes sense for all architectures.

If the kse_create() is going to do it, then we should probably
pass in the size of the entry, or perhaps put the size in the
kse mailbox with the mailbox address being the start address.
That way we can put the kse mailbox in the (at the top) userland
KSE structure and still be free to change the size.

-- 
Dan Eischen