From owner-freebsd-sparc64@freebsd.org Sun Nov 8 16:02:18 2015 Return-Path: Delivered-To: freebsd-sparc64@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 0DC24A29E94 for ; Sun, 8 Nov 2015 16:02:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E5659152A for ; Sun, 8 Nov 2015 16:02:17 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: by mailman.ysv.freebsd.org (Postfix) id E48B4A29E92; Sun, 8 Nov 2015 16:02:17 +0000 (UTC) Delivered-To: sparc64@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 E3EF8A29E91; Sun, 8 Nov 2015 16:02:17 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 75A681527; Sun, 8 Nov 2015 16:02:16 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id tA8G2EwZ049793 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Nov 2015 17:02:14 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tA8G2EtP049792; Sun, 8 Nov 2015 17:02:14 +0100 (CET) (envelope-from marius) Date: Sun, 8 Nov 2015 17:02:14 +0100 From: Marius Strobl To: Poul-Henning Kamp Cc: Warner Losh , sbruno@freebsd.org, freebsd-arch , sparc64@freebsd.org Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151108160214.GA31931@alchemy.franken.de> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <93593.1446679609@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93593.1446679609@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sun, 08 Nov 2015 17:02:14 +0100 (CET) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 16:02:18 -0000 On Wed, Nov 04, 2015 at 11:26:49PM +0000, Poul-Henning Kamp wrote: > -------- > In message <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com>, Warner Losh write > s: > > >I concur. I think sparc64 has had a nice run, but it's time to > >recognize that the run is nearing its end. > > The main reason we wantd to have sparc64 in the fold was that it > was the opposite sex than i386, and thus helped find endianess bugs. > > The secondary reason was that it was 64 bit vs. i386's 32 bit. > Maybe that was the original motivation. However, in my perception, the main benefit of sparc64 for the entire tree over the last couple of years was to be a real magnet for alignment bugs in MI code, mainly network related things (with powerpc/powerpc64 being second place in that regard). It did that job so well that I repeatedly wondered myself: Who on earth actually is using arm and mips? I mean, sure, Juniper has its own IP stack but f. e. at the time alignment bugs in netgraph(4) got reported on sparc64, I really would have expected at least some people to use a MIPS-based router board for running a PPPoE session in order to terminate their DSL lines. That's even true as of today; f. e., there are still alignment bugs left to be fixed in dummynet(4) (which apparently has been written without platforms with strict alignment requirements in mind and, thus, is somewhat a PITA to properly fix). These bugs get reported for sparc64 from time to time but I've never seen a single one in the context of arm, mips or powerpc/powerpc64). Marius