From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 21:29:40 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 6947F37B401 for ; Fri, 4 Apr 2003 21:29:40 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE5543F85 for ; Fri, 4 Apr 2003 21:29:39 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h355TYBg026107; Sat, 5 Apr 2003 00:29:34 -0500 (EST) Received: from localhost (eischen@localhost)h355TXdU026104; Sat, 5 Apr 2003 00:29:33 -0500 (EST) Date: Sat, 5 Apr 2003 00:29:33 -0500 (EST) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Sat, 05 Apr 2003 05:29:40 -0000 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