From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 22:49:30 2004 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 8483616A4CE; Tue, 23 Mar 2004 22:49:30 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 405A843D39; Tue, 23 Mar 2004 22:49:30 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2O6nPtf005668; Wed, 24 Mar 2004 01:49:25 -0500 (EST) Date: Wed, 24 Mar 2004 01:49:25 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <20040323194312.Y55727@pooker.samsco.home> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marcel Moolenaar cc: Julian Elischer cc: FreeBSD current users Subject: Re: SF Bay area hackfest X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2004 06:49:30 -0000 On Tue, 23 Mar 2004, Scott Long wrote: > On Tue, 23 Mar 2004, Daniel Eischen wrote: > > > > For the KSE bits, we've already said a few times that we're > > ready to go but are waiting for a toolchain upgrade that > > supports TLS. > > > > > going to enforce. I don't want 5.3 to go out with hap-hazard and/or > > > unfinished TLS support. SO let me start the list, and I'll let you and > > > others add to it. If we can't get through this step, then there is > > > absolutely no way that we can expect to get this done for 5.3. And for > > > the record, I would really, really like to see this done for 5.3. > > > > I don't quite understand why you need commitments for a toolchain > > upgrade. From what I understand, TLS support can't happen without > > it, and by deferring the toolchain update you prevent it from > > getting done. But I'll play along regardless... > > Operating without a plan or commitments leads us back to 2002 with KSE. > If TLS needs a new binutils, then we need to figure out who is going to > provide that. If no one is going to provide it, then the rest is futile, > no? Right, but the prerequisite for TLS is a new toolchain, not the other way around; you don't need TLS support in non-toolchain components to update the toolchain. Once the toolchain supports TLS, support for it can be added at any time, regardless of whether or not it is before or after 5.3. And yes, we (thread-guys) would like to support it for 5.3 and have said so for quite some time. We've already rearranged our per-{thread,KSE} storage to allow for it. > > > Task Owner > > > > > > Import new GCC Alexander Kavaev > > > Import new binutils ??? > > > Modify loader (image activator?) > > > to understand TLS ??? > > > Modify KSE to understand TLS ??? > > > > Yes, I'm sure I and/or David can support this. > > > > > Modify THR to understand TLS ??? > > > Modify C_R to understand TLS ??? > > > > Death to C_R, death to C_R, ... > > > > What happens when the compiler, toolchain, etc, etc, are all updated to > make TLS work, but the user libmaps C_R in? Does stuff blow up? I'm ok > with C_R not explicitely supporting it so long as it doesn't create new > failure cases. I guess stuff blows up, probably very similar to what already happens when someone tries to use nvidia drivers/openGL with libpthread or libthr. But as far as I know, nothing we have is currently built to use it (it probably can't be because our released toolchain first needs to support it). -- Dan Eischen