From owner-freebsd-arch@freebsd.org Wed Nov 11 18:46:21 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DF70A2C656; Wed, 11 Nov 2015 18:46:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1518B1EA4; Wed, 11 Nov 2015 18:46:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 567A4B9A8; Wed, 11 Nov 2015 13:46:19 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Cc: "Brian McGovern (bmcgover)" , Jordan Hubbard , Warner Losh , Anna Wilcox , "sparc64@freebsd.org" , Sean Bruno , Marius Strobl Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Date: Wed, 11 Nov 2015 10:32:08 -0800 Message-ID: <4004425.K7Etsx0SLe@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <563A5893.1030607@freebsd.org> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 11 Nov 2015 13:46:19 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 18:46:21 -0000 On Wednesday, November 11, 2015 04:07:35 PM Brian McGovern wrote: > I have to step in on Jordan's side on this one. As a recently-former lab admin (June), we were - and I assume continue to - chucking Sun Sparc hardware as fast as we can EOL the products which run on the platform, and to the best of my knowledge, we haven't bought new gear since Oracle bought Sun. I think I still have an SB150 sitting in a closet collecting dust for the emergency case which is predestined to emergency at some point, but we're not even considering giving the boxes another life as second tier hardware - the x86/64 space offers far superior metrics in terms of price/performance/support/replacement parts. > > This, of course, means that our customers will be eventually follow suit as they do their next round of upgrades. While this means there will be a ton of Sparc64 hardware around at low prices, I have no doubt it'll be a niche community, like BETAMAX, Laserdisc, and HD-DVD before... > > If there is someone who loves this platform enough to keep it going single-handedly, or nearly so, that's one thing. If the discussion is to divert project resources to keep it alive just because its one more platform, I have a laundry list of things that I suspect will have a bigger impact on the broader x86 (and even ARM) community; then again, I expect just about everyone has such a list. This last question is an important one I think. What is the actual cost to the project to let sparc64 remain Tier-2? That means we aren't committed to building packages, so that mostly lets Sean off the hook. The biggest hang up I can see is the question of toolchain. On the question of toolchain I think GCC 4.2 continues to become incredibly less useful. If we could have an 11 without GCC 4.2 that would be ideal. However, clang is only production-viable on x86 right now. Even lldb doesn't work on i386 and only works on amd64. If your argument for tossing sparc64 is GCC 4.2 then if you are logically consistent you have to toss a whole lot of other stuff as well. (Even clang on amd64 is still using binutils ld) Realistically I think FreeBSD needs to support two sets of toolchains: clang and modern (GPLv3) GCC/binutils. I think it is a laudable goal to have the option of a GPL-free base system, but I think we should also make it an option to use a modern GCC toolchain. For platforms that depend on GCC 4.2 I think we should be moving them to using newer GCC in some fashion. That is relevant for several architectures that we definitely want to keep going forward, not just sparc64, and it's a problem we need to solve regardless. Once that is addressed it is not clear to me what drain on project resources sparc64 is. -- John Baldwin