From owner-freebsd-current@FreeBSD.ORG Tue Mar 23 18:44:34 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 A451C16A4D7 for ; Tue, 23 Mar 2004 18:44:34 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E1CA43D2D for ; Tue, 23 Mar 2004 18:44:34 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 54384 invoked by uid 1002); 24 Mar 2004 02:44:32 -0000 Received: from unknown (HELO ?10.4.1.17?) (64.58.1.252) by smtp.mho.net with SMTP; 24 Mar 2004 02:44:32 -0000 Date: Tue, 23 Mar 2004 19:49:00 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Daniel Eischen In-Reply-To: Message-ID: <20040323194312.Y55727@pooker.samsco.home> References: 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 02:44:34 -0000 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? > > > 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. Maybe this task list can be appended to Marcel's page and then linked somewhere prominently. If not then I'll create a new project page for it. Scott