From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 16:18:13 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E6E237B401; Fri, 1 Aug 2003 16:18:13 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1608443FAF; Fri, 1 Aug 2003 16:18:12 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h71NIBnj001420; Fri, 1 Aug 2003 19:18:11 -0400 (EDT) Date: Fri, 1 Aug 2003 19:18:11 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030801230157.GA6323@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: current@freebsd.org Subject: Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 23:18:13 -0000 On Fri, 1 Aug 2003, Marcel Moolenaar wrote: > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: > > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs > > > LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. > > > I didn't check other ABIs, but setting to a fixed location of LDT in userland > > > is also a bad idea, I think it will conflict with thread library soon, > > > it is better to use dynamic allocating facility newly added in i386_set_ldt. > > > > Perhaps we need to rethink the interface and disallow > > specification of any ldt; only allow dynamic. We would > > need a different method of setting an array of them, though. > > Why not allow setting a specific entry when it's currently unused > and not reserved by us? > We can simply fail if the process is trying to set a LDT entry that's > currently being used or is reserved by us. The only case that causes > problems is when an existing LDT entry is overwritten by another > consumer. That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). I can see the need to keep the old behavoir for compatibility's sake. -- Dan Eischen