1:N threading

[Terry Lambert]

Peter Wemm wrote:
> > 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.

I assume we are talking a process using per-process LDT's at the
time of the calls?

>From my reading of the i386_get_ldt()/i386_set_ldt() code, it looks
like an i386_get_ldt() with an argument list of more than the number
of per process LDT entries will return the current number of entries
instead of the requested number of entries.

This should be enough to get you the index of the "next" free entry,
since the returned values aren't a sparse matrix.


It also looks like i386_set_ldt() will reallocate the array larger,
if you pass down an entry whose index is larger than the largest
one, e.g.:

	if (!pldt || largest_ld >= pldt->ldt_len) {

I would recommend, though, that only the new entries be set; in
specific, the "start_sel" argument to i386_set_ldt() should be
for only the new descriptor being allocated.

So basically, you get with a huge number, it returns the actual
number, and you set the one after that to allocate a new one.

Anyway, maybe I'm not understanding why the discovery of a new
descriptor available for allocation is a problem here?

PS: I agree on the GDT, in principle, but in practice, is the
number-of-entries limit that comes with that acceptable?  That's
where the TSS limit of 65536 comes from, right?

-- Terry