From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 14:26:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EDD937B404 for ; Fri, 4 Apr 2003 14:26:10 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A51D843FD7 for ; Fri, 4 Apr 2003 14:26:09 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0021.cvx22-bradley.dialup.earthlink.net ([209.179.198.21] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 191ZdL-0002En-00; Fri, 04 Apr 2003 14:26:03 -0800 Message-ID: <3E8E062F.2F69D32F@mindspring.com> Date: Fri, 04 Apr 2003 14:24:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030404200310.A374E2A8A9@canning.wemm.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fd97d2bdb6444bb00dc43e078f02f1c9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 22:26:10 -0000 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