From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 23:48:15 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 53C8416A4CE; Tue, 23 Mar 2004 23:48:15 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E42B43D58; Tue, 23 Mar 2004 23:48:13 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004032407481101600n9e4ve>; Wed, 24 Mar 2004 07:48:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA56639; Tue, 23 Mar 2004 23:50:55 -0800 (PST) Date: Tue, 23 Mar 2004 23:50:54 -0800 (PST) From: Julian Elischer To: Scott Long In-Reply-To: <20040324002624.T55727@pooker.samsco.home> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marcel Moolenaar 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 07:48:15 -0000 On Wed, 24 Mar 2004, Scott Long wrote: > On Wed, 24 Mar 2004, Daniel Eischen wrote: > > 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. > > Maybe something got misunderstood, then. My intention was to create > a list of tasks that need to be done in order to reach the final goal of > having TLS work. New binutils is one of those tasks. I also wanted to > stress that each task needs an owner, otherwise it won't get done. Don't > make me pull out MSProject and do this in a Ven diagram =-) > > > > > > > > > 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). > > > > This isn't terribly desirable since C_R is going to be the fallback thread > package for 5.x. Is there any way for C_R to detect when it's in a > position to blow up and/or give an intelligent message to the user? The linker could almost DEFINITLY do this # myprog ld.so: "You are tring to link libc_r to a program using TLS. Use libpthread" # > > > Scott >