From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:00:42 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 1CA5416A4D1 for ; Mon, 7 Jun 2004 16:00:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E1943D41 for ; Mon, 7 Jun 2004 16:00:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i57G8DSD048841; Mon, 7 Jun 2004 10:08:13 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C49107.8010800@freebsd.org> Date: Mon, 07 Jun 2004 10:00:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <200406071011.01370.dfr@nlsystems.com> <40C48AB3.50705@freebsd.org> <1086623305.10911.30.camel@builder02.qubesoft.com> In-Reply-To: <1086623305.10911.30.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention 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: Mon, 07 Jun 2004 16:00:42 -0000 Doug Rabson wrote: > On Mon, 2004-06-07 at 16:33, Scott Long wrote: > >>Doug Rabson wrote: >> >>>On Sunday 06 June 2004 20:55, Daniel Eischen wrote: >>> >>> >>>>On Sun, 6 Jun 2004, Scott Long wrote: >>>> >>>> >>>>>All, >>>>> >>>>>We are about 4-6 weeks away from starting the 5.3 release cycle. >>>>>As it stands, KSE still only works reliably on i386. There are >>>>>reports of significant instability on amd64, and it doesn't work at >>>>>all on alpha and sparc64. I'm willing to drop the alpha >>>>>requirement and maybe even the sparc64 requirement, but there >>>>>absolutely will not be a 5.3 until amd64 is solid. Please contact >>>>>myself, Dan Eischen, and David Xu if you are interested in helping >>>>>out. >>>> >>>>amd64 looks to be a problem in readline which doesn't seem >>>>to redispatch signal handlers with SA_SIGINFO arguments. >>>> >>>>David also has patches for debugging support at: >>>> >>>> http://people.freebsd.org/~davidxu/kse/dbg/ >>>> >>>>Doug Rabson also has basic TLS support working in perforce. >>>>It'd be nice to get TLS and debugging in before 5.3-release. >>> >>> >>>I'll probably try to commit some kind of TLS support into current in the >>>next couple of weeks. Its likely to only support i386 and will be >>>stubbed out for other platforms. Right now, I'm just waiting for some >>>kind of feedback from an nvidia developer whos testing it. >> >>I'm happy to see that it's gotten this far along, but it needs to be >>available on all tier-1 platforms when it goes in. For the sake of >>argument, we'll call that amd64 and possibly sparc64. My understanding >>is that amd64 should be very similar to i386, yes? Please let me know >>what kind of help you need with getting this done. > > > Well I'm not so sure that it does need to be supported on all tier 1 > platforms. If a given tier 1 platform has a TLS-capable toolchain then > sure - its only about a hundred lines of code to add support once the > toolchain support is there. Currently our toolchain only supports TLS on > i386 and ia64. I think that a binutils upgrade might fix amd64 but the > rest need a new compiler. > > Right now, there is only one real application which absolutely needs TLS > and that is the NVidia OpenGL driver on i386. It looks like the DRM > people will start using TLS at some point but they aren't using it now. > If we reach 5.3 without any new toolchain support for TLS, I think we > should ship with TLS support on only i386 and ia64. It seems silly to > not support TLS on i386 (which people are begging for) because we can't > do it on sparc64 (which no-one needs). > > I agree completely. I forgot to stress in the previous mail that there is a strong push at the moment to get in gcc34 and binutils 2.15(?), which should make TLS infrastructure available to amd64 and sparc64. I don't think that sparc64 should be a hard requirement, but it should at least be looked at and documented so that someone else can come along and do the work. Scott