From owner-freebsd-arch@freebsd.org Sun Nov 8 15:55:12 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 7FBEBA29C4A; Sun, 8 Nov 2015 15:55:12 +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 0D8BA10AB; Sun, 8 Nov 2015 15:55:11 +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 tA8Ft1mu049757 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Nov 2015 16:55:02 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tA8Ft1wx049756; Sun, 8 Nov 2015 16:55:01 +0100 (CET) (envelope-from marius) Date: Sun, 8 Nov 2015 16:55:01 +0100 From: Marius Strobl To: Warner Losh Cc: 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: <20151108155501.GA1901@alchemy.franken.de> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> 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 16:55:02 +0100 (CET) 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: Sun, 08 Nov 2015 15:55:12 -0000 On Wed, Nov 04, 2015 at 04:19:38PM -0700, Warner Losh wrote: > > > On Nov 4, 2015, at 12:12 PM, Sean Bruno wrote: > > > > So here's the thing, Sparc64 is *just* barely alive in FreeBSD. > > Has anybody actually booted it off a newish tree? Yes, just works fine there as of r290419. root@v215:~ # uname -a FreeBSD v215.zeist.de 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290419: Thu Nov 5 23:01:37 CET 2015 marius@v215.zeist.de:/tmp/obj/usr/src/sys/GENERIC sparc64 > > There is exactly 1 Sparc64 machine as a ref box being hosted at Yahoo > > for the project. No new hardware is on the horizon. Over time, linimon@ and me independently tried to get more sparc64 machines there but failed. As far as I was involved the goal was to get hardware being offered for donation in the US there but it turned out that's it's just impossible to coordinate that from over here. However, I've been told that the primary reason for getting rid of the collocation at Yahoo is to improve the situation with on-site maintenance. So getting sparc64 hosts set up it the project cluster may actually be feasible now. I probably should check with glen@. Anyway, how many arm, mips, powerpc and powerpc64 reference machines are there in the project cluster and available for general use by developers? If there were, what would you do with them? According to my experience, the very few !x86 machines that actually are in there aren't really useful without root access. > > None of the newer > > Sparc64 processors have been tested to work on FreeBSD and nobody is > > clamoring to get them working. Unlike x86, sun4u and sun4v CPUs are only designed to be backwards compatible as far as the userland is concerned, host-PCI{,e}-bridges aren't compatible etc. So the kernel side always needs work and it simply isn't a matter of "testing" newer CPUs and models to work. Thus, the hardware is needed for developing support, see also below. I'm not sure at which point I'd speak of people "clamoring" for support of some hardware; f. e. there also isn't a request for the graphics of Haswell and later Intel CPUs to be supported on the mailing lists every other day but you'll certainly agree that many are waiting for it. Now there likely are fewer people looking forward for later sun4u and sun4v processors getting supported but there definitely are people asking for it, just have a look at the lists. > > We're moving into a post-gcc base system now, and sparc64 is the obvious > > "odd arch" here. There's activity to get MIPS moved to clang and active > > work to get powerpc moved fully to clang. Leaving Sparc64 in base, > > requires someone to either make clang DTRT or keep gcc 4.2.1-ish alive. I don't see why sparc64 would be "the obvious odd arch" in that regard. The real problem is switching an architecture for which clang might have gotten en par with GCC after clang was changed to require C++11 for bootstrap. Given that clang was only the default on arm and x86 at that point in time, we are now stuck without an in-tree upgrade path on all other architectures. Granted, that might be lesser a problem on mips as these machines typically don't have enough CPU and RAM that self-hosting would be interesting in the first place. That still puts sparc64 into the same boat as powerpc and powerpc64, though. > There was some work to get clang to do the right thing for sparc64. Last > I heard, the tree compiles with it. It didn?t boot, but at the time gcc-compiled > kernels didn?t boot either. I?m not sure how this status has moved through time. > It would be best to ask Marius Strobl, since he?s the only one committing > to sparc64 sub-tree lately non-global-sweep cleanups. Err, I'm sorry to say but pretty much all of these statements are wrong or at least don't reflect reality properly. As for clang, initial support for 64-bit SPARC v9 and FreeBSD/sparc64 was added in the late 3.5.x times (I don't remember the exact version offhand). Yes, it does compile FreeBSD userland but the majority of binaries do not work or put differently: For some strange reason a clang compiled sort(1) doesn't crash _and_ apparently does the right thing but I wasn't able to find any other program that worked correctly when compiled with clang. By installing clang-compiled system libraries one even totally hoses ones system, i. e. then also sort(1) instantly crashes. With clang 3.6.0 that got even worse; the front-end was changed to select soft-float by default but the back-end didn't have support for choosing between hard- and soft-float for 64-bit SPARC v9 so every compiler invocation just bailed out. As a side note: I couldn't spot any code that would suggest that hard-float support is implemented, which should be the actual default, though. I fixed that (the soft- float defaulting that is, not implementing hard-float support) and some other astonishing bugs (or rather: hacked some things into shape), which got some more things working and IIRC even a clang- compiled kernel got considerably further. However, I didn't get anywhere near the bottom of bugs and missing features. Generally, clang on sparc64 gives more of an impression that it never has faced a compiler test-suite. I haven't given clang 3.7.0 a try thus far but the release notes and source changes don't suggest much has improved in that regard since then. Also, for me a toolchain is just what the name implies: A tool. If it isn't sufficiently close to 100 % working I just use another one. Regarding GCC-compiled kernles not working on sparc64 at that point I'm not aware of such a problem in that time frame or generally of a sparc64-specific breakage in the last couple of years (there was one in userland a couple of months ago, though). I mean, sure, the kernel build gets broken regularly as people don't even compile-test their changes and sometimes that also results in run-time problems but that certainly isn't what you are referring to. However, I can't think of a sparc64 kernel breakage that got beyond that or even was sparc64-specific. What you _might_ be thinking of in that regard is the following: When 64-bit SPARC v9 and FreeBSD/sparc64 support initially were added, clang couldn't cope with code in the sparc64 pcpu.h. There was a patch by jmg@ floating around which changed pcpu.h so that clang could compile a kernel. However, that patch conceptually is wrong and results in a non-working kernel even with GCC. Meanwhile, clang has been taught to grok at least the code in pcpu.h (but not generally to deal with the pattern in question), so at least that situation has improved and said patch is obsolete. As for getting forward, the FreeBSD Software License Policy (https://www.freebsd.org/internal/software-license.html) specifically allows for existing GPLv2 licensed software in the FreeBSD source tree to be updated to GPLv3 licensed one. The initial, longer draft of this policy posted by brooks@ to developers@ even explicitly mentioned key technologies such as toolchains of other licenses being allowed when no mature BSD-licensed alternative exists. So I propose just that: Let's upgrade binutils and GCC in base to recent versions. Seriously. That way we 1) don't need to get external toolchain support into shape, 2) don't need to solve the chicken-and-egg problem of getting a toolchain onto a machine installed from a distribution built with an external toolchain and 3) once clang becomes mature on additional architectures, we have an upgrade path. Don't get me wrong, I'm only proposing that for !arm and !x86. As a side note: A while back I talked to grehan@ and marcel@ regarding the immaturities of clang and - as expected -, a GPL'ed toolchain just is no problem for either NetApp or Juniper as the binaries they ship don't include the toolchain itself. With the possible exception of the current incarnation of SCO which apparently sells a FreeBSD-based OS likely having a system compiler, for the same reason I can't think of why a GPLv3 licensed toolchain would matter for any of the commercial downstream consumers of FreeBSD. Thus, I really can't understand all that aggression regarding making FreeBSD 11 clang-only. > Here?s a breakdown of commits in different parts of sys. The ?Marius? column > is for commits Marius has made in sparc64 only. The rest are the different > architectures we currently support. I wrote this with mail.app, so formatting > may be dicy. > > Year Marius sparc64 mips arm powerpc i386 amd64 x86 arm64 > 2015 5 32 164 445 144 168 247 109 168 > 2014 0 39 117 672 98 125 296 108 - > 2013 14 65 235 455 217 142 235 67 - > 2012 24 55 272 343 152 188 221 76 - > 2011 78 131 205 105 172 189 182 56 - > 2010 75 127 501 103 211 274 268 75 - > 2009 58 95 269 193 137 293 258 - - > 2008 65 109 65 167 161 304 222 - - > > sparc64 rate of change has fallen way off since 2011, both in terms of the > number of commits, as well as the share of commits relative to other > platforms. While I know that not all commits are treated equally, and that > different commit styles in different parts of the tree may skew things, Not only because of that incomplete last sentence it remains unclear what you exactly would like to express with that numbers. There are quite a few reasons why they look the way they do, though. First off, FreeBSD/sparc64 is rock-solid, comparable to x86 in that regard, so it just doesn't need constant changing. Moreover, for a fair comparison you'd generally need to filter f. e. board and peripheral support from sys/arm and sys/mips as sys/sparc64 doesn't have something like the former and drivers for MACs, USB controllers etc. and even the uart(4) bus front-ends live in sys/dev for sparc64. Similarly, you'd need to exclude bhyve- and XEN-related commits from sys/{amd64,i386,x86}. As a side note: Sure, sparc64 isn't exactly en par with x86 when it comes to feature parity. However, IMO overall sparc64 competes rather well with arm and mips in that regard or actually is somewhat better. For example, neither arm nor mips have been converted to NEW_PCIB nor do they provide GET_STACK_USAGE while sparc64 has both. However, one reason certainly also is that some time ago I've decided that I had spent enough money on hardware for working on FreeBSD that I'd otherwise would not have bought (which mainly was sparc64 gear but certainly not limited to that) and rely on donations instead. That didn't turn out to work too well, though. A general problem in that regard are shipping costs and taxes when stuff is located outside the Schengen Area. Also, I've f. e. applied for the M5000 and T2000 machines that where up for donation last August in order to complete/ add support for newer CPUs (support for SPARC64-VI/VII and peripherals in models based on them is mostly there but disabled as I couldn't test it). Unfortunately, I haven't heard anything back regarding these machines. However, that also means: Whoever got that equipment could justify even better use than me, although I could point to the code I had written for that gear. > > I have asked around for help getting the Sparc64 qemu-bsd-user binary > > working so I could at a minimum build packages, and I have gotten no > > feedback from folks. So the only option here is to resurrect sparc64 > > machines somewhere and start up builds on real hardware. It would be more tempting to look at that if the 64-bit SPARC v9 support of QEMU generally would be up to speed but it isn't for years. QEMU seemed to have made some progress in that regard in current versions but it still just isn't there, yet; see the recent attempts on freebsd-sparc64@ to get some of the bugs fixed. That isn't a SPARC-specific lack of interest or problem, though. At work I do microkernel-based R&D on ARM and for that QEMU just isn't usable either; it considerably lacks emulation of viable, real ARMv7-based boards, specifically Cortex-A7-based ones, its GIC emulation is foobar etc. Not that it would help me anything, but QEMU doesn't even provide targets of something as popular as the Raspberry Pi boards. Go figure. As for sun4u system emulation, Simics worked okay for me. That was before Wind River bought it, though. Regarding real sun4u hardware, over time a considerable number of machines has been donated for ports work AFAICT. > > Let's just call it what it is, a dead end of the technology tree. > > I move that we do NOT produce 11.0 versions for Sparc64 and it should be > > dropped from the tree. > > I concur. I think sparc64 has had a nice run, but it?s time to recognize > that the run is nearing its end. > Do whatever you want, I'm tired of mere political arguments and of fighting against them. Marius From owner-freebsd-arch@freebsd.org Sun Nov 8 16:02:17 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 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-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: 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 From owner-freebsd-arch@freebsd.org Sun Nov 8 16:14:34 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 C2CDEA290F5; Sun, 8 Nov 2015 16:14:34 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 881B51ACD; Sun, 8 Nov 2015 16:14:34 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: by obdgf3 with SMTP id gf3so124524682obd.3; Sun, 08 Nov 2015 08:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PNgfiR/ZqQ7zZjEpAV3utx+2/KlA12EQs6p1CXmu8ac=; b=RDu1H7BUg5BKiMxJjqxkN0XlpRWJtPlGAqr0Q0sPQHVkONoWhsF6FJP/fLnE+giP9Y vHV/5w/mHEAh9o4Onq7/Nf/sc9FYR+01Y75fa+gZp2FNcvhi9k4GwD1J9SqY8l5lbnd7 8ai5JqZl13eolyI3dxDc4n3iVIC2IIUHO61rUOBuvqiT+wkg6va8/uGw0lmkzpyN+A7P ayOQ1zLbrvEQnXDe6OEbpu4vwX/aZpOTYnzq0g8R6j9Wri0mo2qkZXdhmkqMrPYhvBz0 dycm0RbrK9vzzD3uRQl+cQB91T6AaXvz5kSFaj+S8BlFHqWF+76FMjI0gPcs0x+9BTb+ sLIQ== X-Received: by 10.182.102.5 with SMTP id fk5mr14739053obb.38.1446999273793; Sun, 08 Nov 2015 08:14:33 -0800 (PST) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.202.81.215 with HTTP; Sun, 8 Nov 2015 08:14:04 -0800 (PST) In-Reply-To: <20151108155501.GA1901@alchemy.franken.de> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> From: Royce Williams Date: Sun, 8 Nov 2015 07:14:04 -0900 X-Google-Sender-Auth: qOjahWHJf9lez_IwRnbDPJIt-c8 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Marius Strobl Cc: Warner Losh , sbruno@freebsd.org, sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 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: Sun, 08 Nov 2015 16:14:34 -0000 On Sun, Nov 8, 2015 at 6:55 AM, Marius Strobl wrote: > Over time, linimon@ and me independently tried to get more sparc64 > machines there but failed. As far as I was involved the goal was to > get hardware being offered for donation in the US there but it > turned out that's it's just impossible to coordinate that from over > here. However, I've been told that the primary reason for getting rid > of the collocation at Yahoo is to improve the situation with on-site > maintenance. So getting sparc64 hosts set up it the project cluster > may actually be feasible now. I probably should check with glen@. Take heart, Marius - sparc64 is wanted. I still have this logo on my Ultra 30: http://www.alaska.net/~royce/gfx/the-SPARC-to-serve.jpg If hardware is needed, I would donate to support this. Royce From owner-freebsd-arch@freebsd.org Sun Nov 8 17:16:57 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 2C2F9A29FE2; Sun, 8 Nov 2015 17:16:57 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF81D1281; Sun, 8 Nov 2015 17:16:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 83B761934F2; Sun, 8 Nov 2015 17:16:54 +0000 (UTC) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Cc: sparc64@freebsd.org, freebsd-arch From: Sean Bruno X-Enigmail-Draft-Status: N1110 Message-ID: <563F8385.3090603@freebsd.org> Date: Sun, 8 Nov 2015 09:16:53 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151108155501.GA1901@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Sun, 08 Nov 2015 17:16:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/08/15 07:55, Marius Strobl wrote: > On Wed, Nov 04, 2015 at 04:19:38PM -0700, Warner Losh wrote: >> >>> On Nov 4, 2015, at 12:12 PM, Sean Bruno >>> wrote: >>> >>> So here's the thing, Sparc64 is *just* barely alive in >>> FreeBSD. >> >> Has anybody actually booted it off a newish tree? > > Yes, just works fine there as of r290419. > > root@v215:~ # uname -a FreeBSD v215.zeist.de 11.0-CURRENT FreeBSD > 11.0-CURRENT #1 r290419: Thu Nov 5 23:01:37 CET 2015 > marius@v215.zeist.de:/tmp/obj/usr/src/sys/GENERIC sparc64 > >>> There is exactly 1 Sparc64 machine as a ref box being hosted at >>> Yahoo for the project. No new hardware is on the horizon. > > Over time, linimon@ and me independently tried to get more sparc64 > machines there but failed. As far as I was involved the goal was > to get hardware being offered for donation in the US there but it > turned out that's it's just impossible to coordinate that from > over here. However, I've been told that the primary reason for > getting rid of the collocation at Yahoo is to improve the situation > with on-site maintenance. So getting sparc64 hosts set up it the > project cluster may actually be feasible now. I probably should > check with glen@. Right, so ... we *can* go upon Ebay or accept donations of FreeBSD compatible hardware for Sparc64. My impression, is that this hardware is quite old, but there is a large amount of it available. There is no support for newer Sun/Oracle machines as far as I know, and I think that is more interesting than supporting machines that haven't been manufactured in a decade. If I'm wrong here, I welcome corrections. > > Anyway, how many arm, mips, powerpc and powerpc64 reference > machines are there in the project cluster and available for general > use by developers? If there were, what would you do with them? > According to my experience, the very few !x86 machines that > actually are in there aren't really useful without root access. PPC: 2x power8 (donated/supported by Adrian), 1x Apple Xserve. (at ISC) MIPS: something at Sentex, but I have no knowledge. ARMv6: none, AFAIK ARMv8 (aarch64): Thunder-X at Sentex Support for mips, mips64, armv6 and armv8 are being provided via emulation. Packages are being build in a similar method. Developers on these architectures don't actually need real hardware, they can either use full system emulation or construct an emulated assisted jail via qemu-user mode. For personal use, there are many, *many* Atheros MIPS routers that can be used for development. The EdgeRouter Lite is a very good MIPS64 target. The RPi and BeagleBone Black are excellent ARMv6 targets that are fully supported with packages and releases. Sparc64 machines can be trivially acquired via Ebay. > >>> None of the newer Sparc64 processors have been tested to work >>> on FreeBSD and nobody is clamoring to get them working. > > Unlike x86, sun4u and sun4v CPUs are only designed to be backwards > compatible as far as the userland is concerned, > host-PCI{,e}-bridges aren't compatible etc. So the kernel side > always needs work and it simply isn't a matter of "testing" newer > CPUs and models to work. Thus, the hardware is needed for > developing support, see also below. > > I'm not sure at which point I'd speak of people "clamoring" for > support of some hardware; f. e. there also isn't a request for the > graphics of Haswell and later Intel CPUs to be supported on the > mailing lists every other day but you'll certainly agree that many > are waiting for it. Now there likely are fewer people looking > forward for later sun4u and sun4v processors getting supported but > there definitely are people asking for it, just have a look at the > lists. > Now is the time for those users/people to step up and "clamor" for it. The example of Haswell graphics is a good point. There is an active developer working on the support with instructions on how to use the test branch in github. We don't have an equivalent project ongoing for the Sparc64 target AFAIK. I welcome being proven wrong here. >>> We're moving into a post-gcc base system now, and sparc64 is >>> the obvious "odd arch" here. There's activity to get MIPS >>> moved to clang and active work to get powerpc moved fully to >>> clang. Leaving Sparc64 in base, requires someone to either >>> make clang DTRT or keep gcc 4.2.1-ish alive. > > I don't see why sparc64 would be "the obvious odd arch" in that > regard. The real problem is switching an architecture for which > clang might have gotten en par with GCC after clang was changed to > require C++11 for bootstrap. Given that clang was only the default > on arm and x86 at that point in time, we are now stuck without an > in-tree upgrade path on all other architectures. Granted, that > might be lesser a problem on mips as these machines typically don't > have enough CPU and RAM that self-hosting would be interesting in > the first place. That still puts sparc64 into the same boat as > powerpc and powerpc64, though. It's "obvious" to me from reading mailing lists and IRC chatter. This is a poor justification on my part as it requires participating in these to see the "obviousness" of the argument. I am personally pursuing clang enabled MIPS builds. Others are moving the MIPS target to enable support for gcc from ports. Powerpc developers have been working on clang and the clang intree is built and installed in the powerpc images. From my impression, there hasn't been a similar push intree to do the same type of things for the Sparc64 target. Am I wrong here? > >> There was some work to get clang to do the right thing for >> sparc64. Last I heard, the tree compiles with it. It didn?t boot, >> but at the time gcc-compiled kernels didn?t boot either. I?m not >> sure how this status has moved through time. It would be best to >> ask Marius Strobl, since he?s the only one committing to sparc64 >> sub-tree lately non-global-sweep cleanups. > > Err, I'm sorry to say but pretty much all of these statements are > wrong or at least don't reflect reality properly. As for clang, > initial support for 64-bit SPARC v9 and FreeBSD/sparc64 was added > in the late 3.5.x times (I don't remember the exact version > offhand). Yes, it does compile FreeBSD userland but the majority > of binaries do not work or put differently: For some strange reason > a clang compiled sort(1) doesn't crash _and_ apparently does the > right thing but I wasn't able to find any other program that worked > correctly when compiled with clang. By installing clang-compiled > system libraries one even totally hoses ones system, i. e. then > also sort(1) instantly crashes. With clang 3.6.0 that got even > worse; the front-end was changed to select soft-float by default > but the back-end didn't have support for choosing between hard- and > soft-float for 64-bit SPARC v9 so every compiler invocation just > bailed out. As a side note: I couldn't spot any code that would > suggest that hard-float support is implemented, which should be the > actual default, though. I fixed that (the soft- float defaulting > that is, not implementing hard-float support) and some other > astonishing bugs (or rather: hacked some things into shape), which > got some more things working and IIRC even a clang- compiled kernel > got considerably further. However, I didn't get anywhere near the > bottom of bugs and missing features. Generally, clang on sparc64 > gives more of an impression that it never has faced a compiler > test-suite. I haven't given clang 3.7.0 a try thus far but the > release notes and source changes don't suggest much has improved in > that regard since then. Also, for me a toolchain is just what the > name implies: A tool. If it isn't sufficiently close to 100 % > working I just use another one. > > Regarding GCC-compiled kernles not working on sparc64 at that > point I'm not aware of such a problem in that time frame or > generally of a sparc64-specific breakage in the last couple of > years (there was one in userland a couple of months ago, though). I > mean, sure, the kernel build gets broken regularly as people don't > even compile-test their changes and sometimes that also results in > run-time problems but that certainly isn't what you are referring > to. However, I can't think of a sparc64 kernel breakage that got > beyond that or even was sparc64-specific. What you _might_ be > thinking of in that regard is the following: When 64-bit SPARC v9 > and FreeBSD/sparc64 support initially were added, clang couldn't > cope with code in the sparc64 pcpu.h. There was a patch by jmg@ > floating around which changed pcpu.h so that clang could compile a > kernel. However, that patch conceptually is wrong and results in a > non-working kernel even with GCC. Meanwhile, clang has been taught > to grok at least the code in pcpu.h (but not generally to deal with > the pattern in question), so at least that situation has improved > and said patch is obsolete. > > As for getting forward, the FreeBSD Software License Policy > (https://www.freebsd.org/internal/software-license.html) > specifically allows for existing GPLv2 licensed software in the > FreeBSD source tree to be updated to GPLv3 licensed one. The > initial, longer draft of this policy posted by brooks@ to > developers@ even explicitly mentioned key technologies such as > toolchains of other licenses being allowed when no mature > BSD-licensed alternative exists. So I propose just that: Let's > upgrade binutils and GCC in base to recent versions. Seriously. > That way we 1) don't need to get external toolchain support into > shape, 2) don't need to solve the chicken-and-egg problem of > getting a toolchain onto a machine installed from a distribution > built with an external toolchain and 3) once clang becomes mature > on additional architectures, we have an upgrade path. Don't get me > wrong, I'm only proposing that for !arm and !x86. I'm totally behind this. binutils is so busted and old that this would definitely make my MIPS work much easier. I'm not a binutils maintainer and I'm super confused, since this policy exists, as to why it has not been done yet. > As a side note: A while back I talked to grehan@ and marcel@ > regarding the immaturities of clang and - as expected -, a GPL'ed > toolchain just is no problem for either NetApp or Juniper as the > binaries they ship don't include the toolchain itself. With the > possible exception of the current incarnation of SCO which > apparently sells a FreeBSD-based OS likely having a system > compiler, for the same reason I can't think of why a GPLv3 licensed > toolchain would matter for any of the commercial downstream > consumers of FreeBSD. Thus, I really can't understand all that > aggression regarding making FreeBSD 11 clang-only. > I don't like a mono-culture of toolchains. I don't want to leave unsupported tools and compilers in our system and I see no reason why we shouldn't being considering updating gcc/binutils if it is allowable. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWP4OCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kVLoH/1KeEXLlUAcfe0hGe8A+reXM tlPj19TnXzVEXMJdk3toWv2Do0E4aicZEaHWkIuGyyX24rOgToMPZo72WozHO5KF ZiBCA74mybTkD+yIQ4EnwgABP9ydN5xhNWWRC5Wk0LGvIzgpr8h333zy/vZAftRM +YarUykE7GGVcWzpkbU6n+TOGPQLWIZOaaUXw1Ue/tQzj5wI128bci9fkHLnhCYu 39btB+cj4pqrwmiVcBLAc9OGJSpKJzAsNVEL7OL0LTiDinT4etRvGLtfZ00mgahw FfRt1Rj6cBF2HSoUf7MOYgTfDTY/b4mmro9WnuzHAfd+dXxYKWSmM8QjPyrSE6M= =M0KX -----END PGP SIGNATURE----- From owner-freebsd-arch@freebsd.org Sun Nov 8 17:31:54 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 01465A2938F; Sun, 8 Nov 2015 17:31:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C18831A13; Sun, 8 Nov 2015 17:31:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iodd200 with SMTP id d200so166139058iod.0; Sun, 08 Nov 2015 09:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NgkmwYWB+xUD3pBAZuoOzAfnopeAmqo3jKwZPNS1yfg=; b=PHWx1q0kUy+/pYRJcn/1H6qNwWTy/a4Lctn+fpZPV8qEQF7eh1274Nqh2ASMSkwUjC ALLIYNyGYAj5CVgqb+ylGaAgoPF2Zj7qSb/y+RO/3daQ+wXN1lNuVS+F3cdjv93vwaEC ozfHkQ31hsCMq1L/ev+zbcRMoeBS1U1PqAp07lBLyun5+1x5mbxh0rOoffh661egyW7r j9c4MTsd/dh9VjcvVwHrNN6zZlHGRtZTkcFthbMLXEe5STAPt26j6nfBLNafBczOpbyg gKxf9uw/RQvOf1MaK7ETnDrN1nBIJCtjcuCTgQ4blPLfL9EsInv2N4JUzhfpq4kFa6Oz AinA== MIME-Version: 1.0 X-Received: by 10.107.46.142 with SMTP id u14mr22574883iou.165.1447003913168; Sun, 08 Nov 2015 09:31:53 -0800 (PST) Received: by 10.36.217.196 with HTTP; Sun, 8 Nov 2015 09:31:53 -0800 (PST) In-Reply-To: <563F8385.3090603@freebsd.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> Date: Sun, 8 Nov 2015 09:31:53 -0800 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Adrian Chadd To: Sean Bruno Cc: Marius Strobl , freebsd-arch , sparc64@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Sun, 08 Nov 2015 17:31:54 -0000 [snip] I can definitely acquire sparc64 hardware in the bay area if people are actually able/willing to do platform bringup. The challenge is finding people to do the platform bringup work. I can get T2000 class hardware here if people wish to do sun4v bringup again for the more recent hardware generations. I'd like to see it because it means we can rush to > 512 cpus with reasonably (nowish) available hardware. -adrian From owner-freebsd-arch@freebsd.org Sun Nov 8 17:42:53 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 A92AAA29646; Sun, 8 Nov 2015 17:42:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 94922102B; Sun, 8 Nov 2015 17:42:53 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C09FF18EB; Sun, 8 Nov 2015 17:42:50 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 8 Nov 2015 17:42:09 +0000 From: Glen Barber To: Marius Strobl Cc: Warner Losh , sbruno@freebsd.org, sparc64@freebsd.org, freebsd-arch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151108174209.GA1592@FreeBSD.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20151108155501.GA1901@alchemy.franken.de> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) 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: Sun, 08 Nov 2015 17:42:53 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 08, 2015 at 04:55:01PM +0100, Marius Strobl wrote: > On Wed, Nov 04, 2015 at 04:19:38PM -0700, Warner Losh wrote: > > > On Nov 4, 2015, at 12:12 PM, Sean Bruno wrote: > Over time, linimon@ and me independently tried to get more sparc64 > machines there but failed. As far as I was involved the goal was to > get hardware being offered for donation in the US there but it > turned out that's it's just impossible to coordinate that from over > here. However, I've been told that the primary reason for getting rid > of the collocation at Yahoo is to improve the situation with on-site > maintenance. So getting sparc64 hosts set up it the project cluster > may actually be feasible now. I probably should check with glen@. >=20 > Anyway, how many arm, mips, powerpc and powerpc64 reference machines > are there in the project cluster and available for general use by > developers? Unfortunately, zero arm and mips. We have three powerpc machines (that I know of) being relocated from ISC to another colocation facility, but I am not entirely certain which are powerpc or powerpc64, so cannot give exact numbers. Glen --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWP4lxAAoJEAMUWKVHj+KTLqwP/3CI85+Hof8L03Sjc91bgYEv CLEh0EdikhY6tkwXxxRl2JD0iwwUDRO7Jb3aZhJdhboQOZiqdVoMjJt8Upxyz4RO SuhBAQcGPB2rN+JMEoSIRuntPTRK4izD+pjXeIRjmph647hslTMm1aIrmw+oLMQa CG0MuCYfGKlR2FzOwELSMcP7Q45Ycy0b/6/bMVN0mpe9IKwxXyikkJI3OxbwQj0q +FOb6ara8VpS1ZWPJ6TZ5z7zla/90MmLRnYvw5yJDD9352NyuLFrLey/KoIh7XYt 4w5/Q5kGu08eNbWES2rQo5u3ju/XZy8MgR4rkXwKvP0oWTuydwKmeWbW5waSImsb w091GegI7Uj+MuER7pKicyr/AQ2rWUTW6ZFKP8tkqpKqFQZRymY29Z9+n9Fb8z6N BgzH5XW7q77sOs93OCrnneyiVec013LdDdYyxYO2OEHeK0Co/ATpLH1Te6NW3/Uy 6eiHvM72D2k9QHlixtuzdWkYbm7GpOYtZfq1hEnlXXZQrdFfkiWPhj5hV3ZidG7z BYFIC9iiid1XTZSwgyKBuR6+zAB+ahDk9H3SLFHyt9WG10OcFSDsWDdmswMMFmHl hhIoBIYaj9FgFZUXIrH5TK08OOgeWqtl/6Jjn+3YbvTfn6bem/vmBhkhp0dL3o0z ms6Qi4JWyUr0qP/LB24z =xjvu -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-arch@freebsd.org Sun Nov 8 18:43:41 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 83BFDA29638; Sun, 8 Nov 2015 18:43:41 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4541F75; Sun, 8 Nov 2015 18:43:40 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NXI0079ZC7CQT00@hades.sorbs.net>; Sun, 08 Nov 2015 09:50:02 -0800 (PST) Message-id: <563F89C3.8050007@sorbs.net> Date: Sun, 08 Nov 2015 18:43:31 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Sean Bruno Cc: alexmcwhirter@triadic.us, freebsd-sparc64 , freebsd-arch@freebsd.org Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 References: <563A5893.1030607@freebsd.org> <20151104214451.GF47630@server.rulingia.com> <20151105232431.GE31432@ivaldir.etoilebsd.net> <6189d48d3a178c4ebf501361c75de23f@triadic.us> <563CB6FC.209@freebsd.org> In-reply-to: <563CB6FC.209@freebsd.org> 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: Sun, 08 Nov 2015 18:43:41 -0000 Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 11/06/15 01:18, alexmcwhirter@triadic.us wrote: > >> So is the problem in question the lack of being able to use >> clang/llvm? Or that newer hardware is unsupported? sparc64 supports >> sun4u which is most boxes, Fujitsu Sparc64 boxes also work quite >> well. The only thing really missing is sun4v and a few drivers here >> and there. OpenBSD has support for almost all of the newer >> Sun/Oracle boxes, which shouldn't bee too hard to port over. >> >> http://www.openbsd.org/sparc64.html >> >> Because of the lack of sun4v support i have moved over to a custom >> illumos distro, but one of the things im working on there is to >> replace gcc with clang/llvm. If it means saving the sparc64 port i >> will gladly move some of my work over to freebsd. >> > > problem 1. the base clang/llvm doesn't support the FreeBSD sparc64 > target. This needs work, and hey, if someone wants to spend the time > to get things working, great. Let's move on it and modernize the target. > > problem 2. lack of development hardware in the FreeBSD project. I'm > not asking for people to buy the FreeBSD project 10-15 year old sparc > hardware and send it to us. We don't want it. If there is a push to > modernize support for Sparc machines, we can talk about aquiring new > machines and racking them up as reference boxes. If there are people > interested in modernizing CPU support, by all means, move forward and > do it. Don't let me stop you. > I would like to see it continue on sun4u, as I still have a load of sun4u boxes - quite capable boxes - and some that people can develop on if you want (I cannot code myself on Sun except for generic stuff in C so I'd not be much help on that front.) Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arch@freebsd.org Sun Nov 8 20:46:24 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 97EECA2960D; Sun, 8 Nov 2015 20:46:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BF2F17CA; Sun, 8 Nov 2015 20:46:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ioc74 with SMTP id 74so102561358ioc.2; Sun, 08 Nov 2015 12:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CZJF9kMfHM5d9b0uIwOA0OlOZuGntFzRm1ImZhi8ypA=; b=ge7k61cZz/7kxhsKCHdKUphsKCb3oehg1Vuq+uyb6jeS52ZbkZIyenCjID7M8jaBrv gWxUTSLPWdB71iLB9Rb3og3hTlRaMcgJ5wewrl9tuegA9+TPMWbY7HwGMMpFVxGLwztn iu3krQawWdIMEpMWEx89fJEtMBSpAwNBJ6uo6/7F12t6ICGYxwxCmxg8+Biep+GZ9i4p TINa+sFL2YrHj45slWfq6IeozQZ892KNsP6G2JU77IL+tNlwkeAuQjgbbR3l43rsY3eZ F1kmipRmRWqkWBWqAMAn+uwI+meSdG+cXP5EB4VA51do9gtvIFOf69woP80hCdpierDM vXLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni_cwru_edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CZJF9kMfHM5d9b0uIwOA0OlOZuGntFzRm1ImZhi8ypA=; b=JurekWZLr5bmTbENn9N9V7AfWeSgQRYR2ZHV8oK2G5Y4XLLJJ86QPQKA3hKMd3QYlm yXvnmFaXXFma35KF/7MZeR2zK4vILKg5AOefNT5qWJ3qp2phOrjyHymTtouBPM80tytO zgynaBKOvmgDoMrLv7A6yV6+V3KwePZOvYVD9JHnUa56mdVRnoBRcZK1JwK7wAQDJE1N YcgraWJWUhcX6n5LEz0ThVHJauzV6M65uIckqiMI4YlZzs1APtWgTAyEVfNH4ZYWOA4+ upobN8dMZc1UIlwulsO0n7blnUglphXIrllvHsvywM33mF9QtLg0mSoeNfC/XXs2Qtdu ncUg== MIME-Version: 1.0 X-Received: by 10.107.34.149 with SMTP id i143mr22034860ioi.157.1447015583582; Sun, 08 Nov 2015 12:46:23 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.36.41.138 with HTTP; Sun, 8 Nov 2015 12:46:23 -0800 (PST) In-Reply-To: <20151108155501.GA1901@alchemy.franken.de> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Date: Sun, 8 Nov 2015 14:46:23 -0600 X-Google-Sender-Auth: ixa9KLH6gn8vWlfQjV4UfizTaEU Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Justin Hibbits To: Marius Strobl Cc: Warner Losh , sbruno@freebsd.org, sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 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: Sun, 08 Nov 2015 20:46:24 -0000 On 11/8/15, Marius Strobl wrote: > As for getting forward, the FreeBSD Software License Policy > (https://www.freebsd.org/internal/software-license.html) > specifically allows for existing GPLv2 licensed software in > the FreeBSD source tree to be updated to GPLv3 licensed one. > The initial, longer draft of this policy posted by brooks@ to > developers@ even explicitly mentioned key technologies such > as toolchains of other licenses being allowed when no mature > BSD-licensed alternative exists. So I propose just that: > Let's upgrade binutils and GCC in base to recent versions. > Seriously. That way we 1) don't need to get external toolchain > support into shape, 2) don't need to solve the chicken-and-egg > problem of getting a toolchain onto a machine installed from > a distribution built with an external toolchain and 3) once > clang becomes mature on additional architectures, we have an > upgrade path. Don't get me wrong, I'm only proposing that > for !arm and !x86. > As a side note: A while back I talked to grehan@ and marcel@ > regarding the immaturities of clang and - as expected -, a > GPL'ed toolchain just is no problem for either NetApp or > Juniper as the binaries they ship don't include the toolchain > itself. With the possible exception of the current incarnation > of SCO which apparently sells a FreeBSD-based OS likely having > a system compiler, for the same reason I can't think of why a > GPLv3 licensed toolchain would matter for any of the commercial > downstream consumers of FreeBSD. Thus, I really can't understand > all that aggression regarding making FreeBSD 11 clang-only. > I 100% agree with you on this. If we can update binutils to the latest and greatest, I believe powerpc64 would be able to work with clang. I've backported several patches, with IBM's permission, to binutils for handling new relocations, etc. However, not all patches are straight forward, and currently we're missing something, which is causing odd segfaults in ld(1), when linking as(1). No other binary, only as(1). I've tried looking through it, but the binutils code is a mess. I'm sure the bug that's getting hit was fixed with newer binutils, but have had a very hard time trying to test with it. TL;DR, let's update binutils at the very least, and gcc if it makes sense. We shouldn't be relying on external toolchain for some archs, and internal for others. It completely snubs already second class citizens. Just look at the various build failures we've had because to some people All The World is clang/x86. - Justin From owner-freebsd-arch@freebsd.org Sun Nov 8 21:43:56 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 4CAA5A29930; Sun, 8 Nov 2015 21:43:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C1291B5A; Sun, 8 Nov 2015 21:43:55 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 01B881934F2; Sun, 8 Nov 2015 21:43:53 +0000 (UTC) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Justin Hibbits , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Cc: freebsd-arch , sparc64@freebsd.org From: Sean Bruno Message-ID: <563FC218.6020806@freebsd.org> Date: Sun, 8 Nov 2015 13:43:52 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Sun, 08 Nov 2015 21:43:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/08/15 12:46, Justin Hibbits wrote: > On 11/8/15, Marius Strobl wrote: > >> As for getting forward, the FreeBSD Software License Policy >> (https://www.freebsd.org/internal/software-license.html) >> specifically allows for existing GPLv2 licensed software in the >> FreeBSD source tree to be updated to GPLv3 licensed one. The >> initial, longer draft of this policy posted by brooks@ to >> developers@ even explicitly mentioned key technologies such as >> toolchains of other licenses being allowed when no mature >> BSD-licensed alternative exists. So I propose just that: Let's >> upgrade binutils and GCC in base to recent versions. Seriously. >> That way we 1) don't need to get external toolchain support into >> shape, 2) don't need to solve the chicken-and-egg problem of >> getting a toolchain onto a machine installed from a distribution >> built with an external toolchain and 3) once clang becomes mature >> on additional architectures, we have an upgrade path. Don't get >> me wrong, I'm only proposing that for !arm and !x86. As a side >> note: A while back I talked to grehan@ and marcel@ regarding the >> immaturities of clang and - as expected -, a GPL'ed toolchain >> just is no problem for either NetApp or Juniper as the binaries >> they ship don't include the toolchain itself. With the possible >> exception of the current incarnation of SCO which apparently >> sells a FreeBSD-based OS likely having a system compiler, for the >> same reason I can't think of why a GPLv3 licensed toolchain would >> matter for any of the commercial downstream consumers of FreeBSD. >> Thus, I really can't understand all that aggression regarding >> making FreeBSD 11 clang-only. >> > > > I 100% agree with you on this. If we can update binutils to the > latest and greatest, I believe powerpc64 would be able to work > with clang. I've backported several patches, with IBM's > permission, to binutils for handling new relocations, etc. > However, not all patches are straight forward, and currently we're > missing something, which is causing odd segfaults in ld(1), when > linking as(1). No other binary, only as(1). I've tried looking > through it, but the binutils code is a mess. I'm sure the bug > that's getting hit was fixed with newer binutils, but have had a > very hard time trying to test with it. > > TL;DR, let's update binutils at the very least, and gcc if it > makes sense. We shouldn't be relying on external toolchain for > some archs, and internal for others. It completely snubs already > second class citizens. Just look at the various build failures > we've had because to some people All The World is clang/x86. > > - Justin __________ - From IRC earlier, we discussed whether or not the ports for gcc and binutils for various architectures work. Does the binutils and gcc port for sparc64 work (or powerpc)? We know there are issues with MIPS binutils at this time (at least for MIPS64). sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWP8IVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kn8YH/j/pmsYviQXD1gkB12VDVylo ABg7w+fwQOm6oddJrnk26XDqPpBJOVgSNznbbIhKgqEc3b9Q1vVCMbmXp+24YwdX 8sJ0KQiutlMm5AHf5MYTPZqNWQbgAGVOWcYPC/AIM3f8kI/aB0Rp7R1jSZtsg/BK RVUhYi9vQWxexvvuf6ORV28sYf+OcpGsY3b+RFiT4QcOJFazgC+HwzsW4Iq+6puM mJH4air62r8vrvkP4ZXNBvzl+91LC6CjZEJe6rCNiKhx6CNCLeDqjVN1ysLjtpj7 V9En1uM6Ms5+JCY8JN2xrDcgc7y2Mdf7BAC2STYestgAMWI4F79HzyHrJ+NwIy4= =o607 -----END PGP SIGNATURE----- From owner-freebsd-arch@freebsd.org Sun Nov 8 21:45:29 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 1C0E9A2999F; Sun, 8 Nov 2015 21:45:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB19A1C4B; Sun, 8 Nov 2015 21:45:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igcph11 with SMTP id ph11so15705412igc.1; Sun, 08 Nov 2015 13:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sNvzXFfKPNb30GTFXo1wJn7WRbgIgB0R8R4IZIWGXsg=; b=ruIvNlqyfE1LMbEEwlJCIDHE4+NnUDQ40VtK4T8FQAslOVkOSqUmJH7u9jzrh+Netp r0rgqob2N7vXPaPled6yAiJvgdgrC6U8jgu2/JPSqyWvz0IlrWBMmdbIuNiNctIlfi4s PDamoZdk9JJVHH4zPfd/qnA52Tp5eKnL7yKD9xDhC7yFoBzi0bya7Y/mCLpPtEHCW68r M1pG2aWzH9VrECDeDtyh9B08AsN29Gqd5ZuASeZ6c9oepCW9kgH3j7F9bRIW6w1J+Lis 7aupiy4LGhiTH/WV2BtI6CLCJ1G8xKqKpS6XELl4kH02oIh90MPQp15/HXwWrNOarfjO 22vw== X-Received: by 10.50.108.100 with SMTP id hj4mr16636695igb.97.1447019128123; Sun, 08 Nov 2015 13:45:28 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.158.148 with HTTP; Sun, 8 Nov 2015 13:45:08 -0800 (PST) In-Reply-To: References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> From: Ed Maste Date: Sun, 8 Nov 2015 21:45:08 +0000 X-Google-Sender-Auth: 69QemNgGw4-8T4GvrrfXNq9WrIk Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Justin Hibbits Cc: Marius Strobl , Sean Bruno , freebsd-arch , sparc64@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Sun, 08 Nov 2015 21:45:29 -0000 On 8 November 2015 at 20:46, Justin Hibbits wrote: > > I 100% agree with you on this. If we can update binutils to the > latest and greatest, I believe powerpc64 would be able to work with > clang. I've backported several patches, with IBM's permission, to > binutils for handling new relocations, etc. However, not all patches > are straight forward, and currently we're missing something, which is > causing odd segfaults in ld(1), when linking as(1). No other binary, > only as(1). I've tried looking through it, but the binutils code is a > mess. I'm sure the bug that's getting hit was fixed with newer > binutils, but have had a very hard time trying to test with it. We have support in the tree to use an external binutils automatically - we use this on arm64, which is completely unsupported by the in-tree binutils. External binutils is enabled by setting CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_ARCH}-freebsd/bin/ This happens automatically if the target specifies BINUTILS_BOOTSTRAP in BROKEN_OPTIONS -- for example, arm64 sets BROKEN_OPTIONS+=BINUTILS BINUTILS_BOOTSTRAP GCC GCC_BOOTSTRAP GDB I'd suggest that the first step in any of these discussions is to use this to test building with the binutils port. We know it won't work for mips today because upstream bintuils lacks FreeBSD/mips support. It may work for other targets though. Even if it doesn't the same work needs to be done regardless of whether the target uses an up-to-date binutils from ports or from the src tree. From owner-freebsd-arch@freebsd.org Mon Nov 9 01:43:41 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 0E821A24554 for ; Mon, 9 Nov 2015 01:43:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B06B819D9 for ; Mon, 9 Nov 2015 01:43:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkao63 with SMTP id o63so23603091qka.2 for ; Sun, 08 Nov 2015 17:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OSNQBoQPTLgp1Q+3vzBiviNOBUqYrZe9FoOE+HUH6B0=; b=vrdFTFNRowl1cmHSEpOYVC/zA/k4XiNDkYUDXYdZt4zJ/UA5+KH+NCdY54o2A1GQnI q3oyDFF3lMI8sGZ4dl4CSNAKriGfddpGUhfK1xBvSGdztkfBMnjBxZ2HlyyP6lUOKepB y8xFBCL2/M8mlSsgH1Qy//I69/b1uZzfnPgJigrXjo8mrjsz5MrhS5Xtcl1Gs/Sf1IEp DgHllNmKeu5XMCZmRib1adwf2RvT8rcj+W+GZ/NbfnvZYkZB1lP2qD74KVs4R8NPVLmT b+vi0iYf8YcRIyA9e0+p4L2ahng2EOGDlBRnZLX3HSLztB49SdHCJboGk+Le8AQJKoCs Xyag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OSNQBoQPTLgp1Q+3vzBiviNOBUqYrZe9FoOE+HUH6B0=; b=SHL2FraWJPyTMLQMmU+z7+WNKJAHohYoMJLygcjRajuvWj72K2mz2K+f7UGAzI+ywQ j8/AnKtHumjwyKylSspNzXGGgWqv6Owy4x+GPGs4J1bX7Ju8YUB+F1Me6ployHJ+Oc6c 4pD7+YrNXa6EFtEkvBnvRM6UV1vzyOmjCv7SbM8OWiteMG8hCTb7psbdYsiG7nc+UlKp 78ykEpc4d739s8Dref6ZcQ7I/+ElRRVuG0m6iLcdHxF3JDmruizEpHg0neafE++XPaoQ WrW2CgRdizVq3mrjkrnIpx7trRKdfad92OyO9D2ZHvPNe41o5hf9fR3qkrkWNLl1DqE7 TkBQ== X-Gm-Message-State: ALoCoQmab+EKawiOHMPBd8ej6vbi72SQaM8a5xiTKF1DbPm3lFBU3FLdcH5yAys5I6K5Krs0NzbJ MIME-Version: 1.0 X-Received: by 10.55.40.211 with SMTP id o80mr26286524qko.93.1447033419335; Sun, 08 Nov 2015 17:43:39 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Sun, 8 Nov 2015 17:43:39 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Date: Sun, 8 Nov 2015 18:43:39 -0700 X-Google-Sender-Auth: LjDW_UbRuWn28eleGiK3SVEIdGs Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Warner Losh To: Ed Maste Cc: Justin Hibbits , Sean Bruno , freebsd-arch , sparc64@freebsd.org, Marius Strobl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 09 Nov 2015 01:43:41 -0000 On Sun, Nov 8, 2015 at 2:45 PM, Ed Maste wrote: > On 8 November 2015 at 20:46, Justin Hibbits wrote: > > > > I 100% agree with you on this. If we can update binutils to the > > latest and greatest, I believe powerpc64 would be able to work with > > clang. I've backported several patches, with IBM's permission, to > > binutils for handling new relocations, etc. However, not all patches > > are straight forward, and currently we're missing something, which is > > causing odd segfaults in ld(1), when linking as(1). No other binary, > > only as(1). I've tried looking through it, but the binutils code is a > > mess. I'm sure the bug that's getting hit was fixed with newer > > binutils, but have had a very hard time trying to test with it. > > We have support in the tree to use an external binutils automatically > - we use this on arm64, which is completely unsupported by the in-tree > binutils. External binutils is enabled by setting > CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_ARCH}-freebsd/bin/ > > This happens automatically if the target specifies BINUTILS_BOOTSTRAP > in BROKEN_OPTIONS -- for example, arm64 sets > BROKEN_OPTIONS+=BINUTILS BINUTILS_BOOTSTRAP GCC GCC_BOOTSTRAP GDB > > I'd suggest that the first step in any of these discussions is to use > this to test building with the binutils port. We know it won't work > for mips today because upstream bintuils lacks FreeBSD/mips support. > It may work for other targets though. Even if it doesn't the same work > needs to be done regardless of whether the target uses an up-to-date > binutils from ports or from the src tree. Speaking of CROSS_BINUTILS_PREFIX, we need to unify CROSS*PREFIX stuff with the CROSS_TOOLCHAIN stuff. Two different ways to specify thing. Warner From owner-freebsd-arch@freebsd.org Mon Nov 9 03:21:42 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 AE44BA29F1D; Mon, 9 Nov 2015 03:21:42 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0143.outbound.protection.outlook.com [157.56.110.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3F80183F; Mon, 9 Nov 2015 03:21:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BY2PR05CA027.namprd05.prod.outlook.com (10.141.250.17) by BLUPR0501MB1666.namprd05.prod.outlook.com (10.163.120.149) with Microsoft SMTP Server (TLS) id 15.1.318.15; Mon, 9 Nov 2015 03:21:33 +0000 Received: from BN1BFFO11FD053.protection.gbl (2a01:111:f400:7c10::1:105) by BY2PR05CA027.outlook.office365.com (2a01:111:e400:2c5f::17) with Microsoft SMTP Server (TLS) id 15.1.318.15 via Frontend Transport; Mon, 9 Nov 2015 03:21:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; bsdimp.com; dkim=none (message not signed) header.d=none;bsdimp.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1BFFO11FD053.mail.protection.outlook.com (10.58.145.8) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Mon, 9 Nov 2015 03:21:32 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 8 Nov 2015 19:21:30 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tA93LTD14616; Sun, 8 Nov 2015 19:21:29 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 06562580A9; Sun, 8 Nov 2015 19:21:29 -0800 (PST) To: Warner Losh CC: Ed Maste , Marius Strobl , Sean Bruno , , Justin Hibbits , freebsd-arch , Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 In-Reply-To: References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Comments: In-reply-to: Warner Losh message dated "Sun, 08 Nov 2015 18:43:39 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9912.1447039288.1@chaos> Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2015 19:21:28 -0800 Message-ID: <10153.1447039288@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD053; 1:eBZat4UxdIWnn/87UkvCcDH6XYkaRL6QeIbtBXF/N2a8wsNsLg4nlmRUjBWlbQljxQuydi8rbUgj9URb6Y153FqcO6JSKT6QyA2tJZS59HPMXPso1XtIAOgfikVllgbM48KVuDEyTQ8tkZce8RfTzZsQKaz1wMfuQtcfN2ouMHdnklQrBn3P9wACq7g5WBfv5J12hLWjCQOc5sY8+kNOGAReBIqJshHShT8QK4QxJTwur/ATljTrGALKyGoQkkoDfgzfhHYNhEzSSxxoql2oVyJ21fW5gK2LycsYvALnqHKgDT/0hSp2mfBwxYQ5LCSX0NuLDNRQcXztYBZpmgnzvw== X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(110136002)(19580405001)(50986999)(76176999)(4001430100002)(69596002)(19580395003)(46406003)(6806005)(5007970100001)(87936001)(93886004)(23726002)(77096005)(2950100001)(97756001)(117636001)(50226001)(57986006)(76506005)(33716001)(107886002)(47776003)(11100500001)(86362001)(5008740100001)(81156007)(5001960100002)(106466001)(189998001)(97736004)(50466002)(105596002)(92566002)(16873001)(62816006)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1666; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1666; 2:GKMgM2rBjvwNNG0HjTyqBHzKsHJPYQ2qd16nZ0pbPTMUF+50kTYoVcwiO07kKemeLgvSxfDvPioBOlz3+6dq9O8YU3vkxRyhaBXJMUS4XSz2MKV2CZPf5n0WH6iSEAAv9aN7CoUv8PmuBce8IE+0aN8gx0LFFAXgj0VFaqPJ+0w=; 3:rpselWiDXgVqdM6JawZY5KfQDBGVJ2jRC8KFLlj8SU5NScXpwf+nlZDjBncipIxPlz/aHFcLl7oU+dhaLJH5LUsRRqFnuJzWs1H9xMj022qX5ZPJemM4ymZbgbb73zHbGVymIJvfEKlv0usvMHN+/N/g9f4H2JYLUUWaf1CoWenoZFshsws/4v7skNQT0nLL+nvuRf4wytPWFLaBka6AdXAmf9vQ2WI74D2AbjRY8Zs=; 25:GGObStjflro3fJM7KEuW8dkOsaxexv9ZvTg6Ku0/dJ+nKm+sTw6XVBn/C97DON1yaYUWCmma425xtlEikPvTAmggK4m381X+hvmf6MYyE0P6jN0gaX98Hnmck1DLhUZxc4ich/EDR2Fj6YAP0OXCRIOqSsXgIOUiiCgguEUm4LuhBxDPjFGfRTT5oNdGLqTVY1QKXLNeKqgtV1iPHCYj8vNv27nBhARrERSbmmF2J5hCN12bXAyBsIUL3B5s6oPYzwhLnQHSEn/+x92Um8mg8w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1666; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1666; 20:pYmtvS5NlN6dHWHgoiFU1IWhYFXhXxX18X6eEnSTb9KhTcW82ebe59O8dGP1dywXy/FNyc7OmFwqzRuhqLbN7icI2ee5oF9gdJChWEXaVyqIt4OHbrXgR9jmBWTJmC56o+0TFCUr9a0VWjMKbFUrxQilYBJkud6FzGUpoqoArWP6mQOsjtT916VUI9i5ztJ1VQo3QGWFfQ0NqtY6PfX5JhbMocG9BFltsM85cyqIwYh9myfoaPkpGr/3P8bUBXgF76pksIlmNYyrEGwXZtIfBWrdN4j8KfUbtkiRZ/STjKreb3GRFpnvYVPUB5hzw4Pbj42l4OCVVxhmNioVPfX/Br9TCveuFBwfNO/z+VFstdJXBPJaKv5m2dsUqtRRDRZR0KNX4IoFKLEsnKLN88a0wtj7iz6vwa2y7aMbZmWkNFm7/P+f5k83+zMLWbS3FSUBp+jajCe6Hq6F7QcQxqczdTpdaiSRron4S9hJ5AHdvRteq6EMcmGMzxbdEmWBF9PV; 4:IxqgtYChmfx14GFiOiQv3S29d7i5gw2yuVKEW03IihBCjGhwH6rUM4lLF6zSWW534+yzGJuDvxqQMYUzr3W/rE7b+cBYWz3PLMLDJdgWMoJAYsKZRGLbJuQ3VoEW3R7F6o5HcLR0D3MpIRjhCreFy7jnbDcj/XktDPVSfRZ0prkxGUqmMK7l/jXZZkzPZfIcK1XQv9UOIIYzZkxaoEGZXz3JZqov5+LEPq6mfQdyDDcJXLnhu4Ze5UjX37mrwiexCGWFtlYcg1tEsw++5sKufUPi4dtl+6vPgaeX+bsGEWBMTDj6bQDUOx9ioniGdJ7nmjRsMCPf27j5ohY9lx4tvuXSqU92Yqtp58zh9tbrf0M2QyldIR+vhRTa71lk6O2U X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0501MB1666; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1666; X-Forefront-PRVS: 0755F54DD9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1666; 23:D9P6beJFXvoBhvBektisG3d4fnHrzvYb40RR+w3?= =?us-ascii?Q?oQhUkpH408IWD2LQvMqz9W3WmwHyxR7skKtAxgG0HMrGCkCvFhqSCfnp2hER?= =?us-ascii?Q?VhIbKJCcatOrMytRuTzColsYp2CIeK9HTSJDiCfAVq4+l9PHmoIhUpNeBDxv?= =?us-ascii?Q?gG8KbnaysJS9HKYZD8lnE0+cEyNeqyPgiFRCOD8w7SR7oNok6/NCyaSQNrbo?= =?us-ascii?Q?Hky3PwCpN7asMzq0dzWVLZdM0958XMWlaW2Cc8zjxMGNArVgpTWrbauWrGjk?= =?us-ascii?Q?WM3yuXEf2PDb0UuQTNcZ1FY/WyQlsT7Waty1/nAqlu6+7lXBOGxnQPwQTxqn?= =?us-ascii?Q?HuYqlSv7jDoxGsCEiSqtWKcMucq+KcmE1zxFH75q8/aBTqZVgLn2BSuzKbeM?= =?us-ascii?Q?ugJv4y5Jf/D7WdPNp9WxNB6cOmKKcLjRxjmNjpzoHp2FlENKv3GrWRWsBc1G?= =?us-ascii?Q?61K86F0o3dVOjiwYY9A68lbSqrv+3I6Sh+1w7guxU0UU9aLkZD5LBUhDpo8n?= =?us-ascii?Q?clzX3QO0mGlcKE0co05eBQA9CFOjnH9l3ggJ/XRY1J1LwOy4GZ4iANjdRLzc?= =?us-ascii?Q?azN1jQt5l840stObq8Z83wUfEBXthZcz3kUAvqoWP5pyaIrGpl7bF3VBzgmM?= =?us-ascii?Q?SdDp7fWqRWsyc1WR9iED9dvkIlzX6vnsJIV+CYzy7DEYLB5v5EthiVpTkqmk?= =?us-ascii?Q?hlpv9mkgp6/kIzmvW7kgJUBBoyYvhD3m8E5a6WbklK4hlKi8277E1ra6eWdr?= =?us-ascii?Q?3WrmcEtPtybUCX996VGLshRypLPiPG2yiPX/hgNtxBNwLixvXg16sCVdYEd0?= =?us-ascii?Q?nO4wi6r1r+1ieb6fLNCoZFlFVFsFE6rXA8WCR8eKF8xv1v7BkxDfjiKx+KMH?= =?us-ascii?Q?doHMTYZ629RqHTwC7T7+Wi3aGmob6xcAIp2fRfwrulAmsyioYRTUYd+xn0lJ?= =?us-ascii?Q?WRTBNs60woBDY8irPnbmcnTZZk6nNUkwb/hsMJOJIpUUNgOez4DFGfQ5IA3J?= =?us-ascii?Q?camlmtqcOzvRcKFm1zOOCNTUX88BcPR7fdKYUb9D+2aITL6tSX0g786tPOKf?= =?us-ascii?Q?Jeu8yOixDAvEa/qWxSozXXjSRqghQTLkdblY/ANjYOm22Xj0nKteB8iIMrW+?= =?us-ascii?Q?h9ohl9x799rvkleEWJMgtyKKDkU/EZRRzM92KnnJRHHYKIDDRHcV76w=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1666; 5:myJZFKNyLv/IHPOsd75mh2GpD39BKP2M+0dIej0pi6hYdB1sUmZx/NiVMRmHSd/Cr0rpnmaK/YVyo4sCSbX3BGsmv88QhJ7fQanTj3CAO21b+IOzEYqI3MuTYBv+amNuzxfuGyFVu+auSV5tX1tmsg==; 24:tmoYOy+rffEJzG8fXEWmmOunP3L3C0bfRl1zrbF1bQDw9+9tR5Sutxb5Xw6DlEk9mpCgDPX4zwD+69gW56Rg54sp7uv3u+UAhAIU/E1TLXk=; 20:89Yo+ZaGMoYVivJpxzwfEVc/LU87TPVBWkpY8B1nsbrHwWx31Gt8NQKQXVxP59OSxqwCKRCEYoy0vqwWUtkUdw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2015 03:21:32.0604 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1666 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: Mon, 09 Nov 2015 03:21:42 -0000 Warner Losh wrote: > Speaking of CROSS_BINUTILS_PREFIX, we need to unify CROSS*PREFIX stuff > with the CROSS_TOOLCHAIN stuff. Two different ways to specify thing. I guess that depends on how they are used. We (Juniper) probably took all this to extremes many years ago, and after a few revisions it can easily get confusing. FWIW for a compiler: /volume/hab/FreeBSD/10/amd64/gcc/jnpr/4.2.1/amd64-juniper-junos.8/bin/amd6= 4-juniper-junos-gcc we currently have something like: TOOLCHAIN_PREFIX =3D /volume/hab/FreeBSD/10/amd64 TOOLCHAIN_${MACHINE} =3D gcc/jnpr/4.2.1/amd64-juniper-junos.8 CROSS_TARGET_${MACHINE} =3D amd64-juniper-junos all the VAR[._]${MACHINE} get resolved like: CROSS_TARGET ?=3D ${CROSS_TARGET_${MACHINE}} COMPILER_TYPE ?=3D ${COMPILER_TYPE_${MACHINE}} if CROSS_TARGET is not empty, then CROSS_TARGET_PREFIX =3D ${CROSS_TARGET}- so all the above combine into BUILD_TOOL_PREFIX =3D ${TOOLCHAIN_PREFIX}/${TOOLCHAIN_${MACHINE}}/bin and you can set CC etc to CC.gcc =3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc AS.gcc =3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}as etc From owner-freebsd-arch@freebsd.org Mon Nov 9 23:32:47 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 CCE28A2A98C for ; Mon, 9 Nov 2015 23:32:47 +0000 (UTC) (envelope-from cameronsparr@gmail.com) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 911A31093 for ; Mon, 9 Nov 2015 23:32:47 +0000 (UTC) (envelope-from cameronsparr@gmail.com) Received: by ykdr82 with SMTP id r82so16387356ykd.3 for ; Mon, 09 Nov 2015 15:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ak+SJDbCc/plOP3YZVsLXscPXGdpXu/YzbLJfrF5dpo=; b=dVr85b1xoru2q3NFMRbfJQB3SaeXcDJ+s/E3QVjfIZ4Kn7w6kg2IgzNOnmVGx8iKQU cylTzaK5IEOwToxUjyTBKWZqQI1dvGVSigWtCF5MmE1c5bU78lJ+rmHw6pgJwu/HmRFk SgVClj2VdMM64ovqtioVugHQII3w/GMHvvye3gyoA0wP9j8y3GoY8y2n9B4peJVFoMa/ U5s0ZDNtCX2O7eSQkGCU5Wlu8SPB410gPGB4DBKl4qf+Z/Jpa8oD8mgNOlnKi1QlotEI QKMvcqMzbnP/N96QXLOv3D/VPwSW3h3ZhXxU8jo6uguMCJSLDBmzVK74I84dJCh9Bw/j laiA== MIME-Version: 1.0 X-Received: by 10.13.223.151 with SMTP id i145mr495333ywe.324.1447111966605; Mon, 09 Nov 2015 15:32:46 -0800 (PST) Received: by 10.129.102.68 with HTTP; Mon, 9 Nov 2015 15:32:46 -0800 (PST) Date: Mon, 9 Nov 2015 16:32:46 -0700 Message-ID: Subject: setsockopt() and kern.ipc.maxsockbuf From: Cameron Sparr To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 09 Nov 2015 23:32:47 -0000 Hello, I'm not sure if this is the correct place to do it, but I'd like to put out a proposal for changing the way that the setsockopt() function handles the max socket buffer setting. Currently, it's a bit unintuitive that SO_RCVBUF & SO_SNDBUF can not actually be set to the kern.ipc.maxsockbuf value, even though it is described as being possible in the man page: https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion=2 This is because setsockopt() will error out if the value passed is over the _adjusted_ maximum, which on my system (amd64) turns out to be something like kern.ipc.maxsockbuf * 0.889 (kern.ipc.maxsockbuf * (1 << 11) / (256 + (1 << 11)) = kern.ipc.maxsockbuf * (2048) / (2304)). see here: https://github.com/freebsd/freebsd/blob/master/sys/kern/uipc_sockbuf.c#L420 and here: https://github.com/freebsd/freebsd/blob/master/sys/kern/uipc_sockbuf.c#L63-L64 I believe that the behavior could be made more intuitive by checking if the value passed is under the _actual_ max before erroring out, and if it is under the actual max, then set it to the adjusted max and continue the function, this would be a simple change and would look something like this (apologies for the whitespace diffs): https://github.com/sparrc/freebsd/commit/157f90c55d1d54d33f41c6f7517de1a9c5f5e229 Also, I'm a newb to the freebsd mailing lists, so please let me know if this sort of request should go elsewhere. Thanks all, Cameron From owner-freebsd-arch@freebsd.org Tue Nov 10 04:22:34 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 83175A2BA65 for ; Tue, 10 Nov 2015 04:22:34 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.65.240.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5266D13C3 for ; Tue, 10 Nov 2015 04:22:33 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 22234 invoked from network); 10 Nov 2015 04:30:25 -0000 Received: from c-71-57-141-247.hsd1.fl.comcast.net (HELO ?10.2.1.57?) (AWilcox@Wilcox-Tech.com@71.57.141.247) by mail.foxkit.us with ESMTPA; 10 Nov 2015 04:30:25 -0000 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Sean Bruno , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> Cc: freebsd-arch , sparc64@freebsd.org From: Anna Wilcox X-Enigmail-Draft-Status: N1110 Message-ID: <56417100.5050600@Wilcox-Tech.com> Date: Mon, 9 Nov 2015 22:22:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <563F8385.3090603@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Tue, 10 Nov 2015 04:22:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/11/15 11:16, Sean Bruno wrote: > On 11/08/15 07:55, Marius Strobl wrote: > > Unlike x86, sun4u and sun4v CPUs are only designed to be backwards > > compatible as far as the userland is concerned, > > host-PCI{,e}-bridges aren't compatible etc. So the kernel side > > always needs work and it simply isn't a matter of "testing" newer > > CPUs and models to work. Thus, the hardware is needed for > > developing support, see also below. > > > I'm not sure at which point I'd speak of people "clamoring" for > > support of some hardware; f. e. there also isn't a request for the > > graphics of Haswell and later Intel CPUs to be supported on the > > mailing lists every other day but you'll certainly agree that many > > are waiting for it. Now there likely are fewer people looking > > forward for later sun4u and sun4v processors getting supported but > > there definitely are people asking for it, just have a look at the > > lists. > > Now is the time for those users/people to step up and "clamor" for it. > The example of Haswell graphics is a good point. There is an active > developer working on the support with instructions on how to use the > test branch in github. We don't have an equivalent project ongoing > for the Sparc64 target AFAIK. I welcome being proven wrong here. > > > I don't see why sparc64 would be "the obvious odd arch" in that > > regard. The real problem is switching an architecture for which > > clang might have gotten en par with GCC after clang was changed to > > require C++11 for bootstrap. Given that clang was only the default > > on arm and x86 at that point in time, we are now stuck without an > > in-tree upgrade path on all other architectures. Granted, that > > might be lesser a problem on mips as these machines typically don't > > have enough CPU and RAM that self-hosting would be interesting in > > the first place. That still puts sparc64 into the same boat as > > powerpc and powerpc64, though. > > It's "obvious" to me from reading mailing lists and IRC chatter. This > is a poor justification on my part as it requires participating in > these to see the "obviousness" of the argument. > > I am personally pursuing clang enabled MIPS builds. Others are moving > the MIPS target to enable support for gcc from ports. Powerpc > developers have been working on clang and the clang intree is built > and installed in the powerpc images. From my impression, there hasn't > been a similar push intree to do the same type of things for the > Sparc64 target. Am I wrong here? Just as a further note, I had experimented in January of this year with making a binary pkg mirror for sun4u using my (comparatively sad) Ultra 60 and a cross-build system. Installation was fairly straightforward but I was having issues bringing up Clang and was having many issues trying to build "modern" packages using GCC 4.2.1. See my blog for some insight: http://blog.foxkit.us/search/label/sparc Unfortunately, truth be told, I gave up after the Freenode IRC channel gave me a whole heap of abuse and name-calling for trying to ask for any support with the sparc64 port. I couldn't find the documentation I needed to keep going and nobody wanted to help. If there are others working on this and I am not alone after all, I will gladly pull the Ultra 60 back on to my desk and do what I can to help out. GCC 4.8 or 4.9 would be a huge, huge, huge improvement in particular. - --arw -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWQXD8AAoJEMspy1GSK50U/qIP/0v4ltN6jkC7q5ijz/4x68QC sG8uk6r2Od9w5z8DF2RPLyNIRchvGTpxLMFPtCNX3Skdpchf/dK7wp/BBPjjzYEw BdkjgXEZiJape6YWI8XtbM681YrHoe9nYUkIMuKBKIMiMuhCTuExByca/x43GR8a U0RWbdQgLCRi7SmH4gLgZUTNp0yPhWE5O2IAHNoL+JwMC0Jwd/OjS9Za972+ZvAv 9d4aDmhmwFzdZPPxZps9iVytya27k0FfrY+vc6KHVsn1GHIh9SOcULBmrB6I5XOT D5JXA1OTmPHMhdd7/aY+6HWZO1eOk1kcwIKbKVXJuqNyl0twScHCfuSdE214SfDk CeYCUmIZs7Sh0+tUzIfFQHceD/sRomrXwoMY/6OzMiVGkGq/1A1PdgQheg0E1nbc DMQGV60drqFmVFVrmAKqhE8R7RtfTj5SvwMxjeLTEyPGehyv1mIarSCrebxCj75p mcJWqUiqjGuSIlV+vuEaSc9zbPh+ivAXzJHS0/gqp+WTdmH5LLECzzanspanxdTK 5Xa6KaP7CzcX4O7/uoIuB/tuczQVZGonPbT6apMlUpCPazxGvIgT26g9dGH4VfJM ugvDcfDzme0u04Ts2nkw5D08U/tDZMQfL1C7+BEYxSI811NY83BDrZCIkdX9IzdD ITFrIGCVocsrIlvShE0N =3Dk0k3 -----END PGP SIGNATURE----- From owner-freebsd-arch@freebsd.org Tue Nov 10 04:59:44 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 7C469A2B214; Tue, 10 Nov 2015 04:59:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47DF91379; Tue, 10 Nov 2015 04:59:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iodd200 with SMTP id d200so209291836iod.0; Mon, 09 Nov 2015 20:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0AK6W9SWqIV2dF/rWYqiLrT0ip6i7kfvW1cONrI5TEM=; b=s+tocQ4TRzWI9WwXNErxM3munVRt7i7oAgPj7USdRi3IUf7Mkf2cR3b1dVngDL/5Ra nGB0BuY1r6ePk+QQro51y4GASOX26mrOiuU8DF2Nus9nRsnmXAcWitrhWEj++gJbJywn +JWfDRNhdxPEKWsgvTd9NbHPcZDUnmxe24uOxhf5GS2d/PNDEI4Hb5fga3ttFQnp2dFh jSCIDv8rT8wcPp2p85/qPLSmKq1FfPtDnLt4ZCwzGD1H+2o7qPFx/eWld2ECXt1DvpLQ rvwuIcdmjKtYg09stCyqsmYrZm9E/WFBLYvWsJ1Ip+7Frm7KSslosjDlSJkukKDOWEzd 0Euw== MIME-Version: 1.0 X-Received: by 10.107.46.142 with SMTP id u14mr1806712iou.165.1447131583247; Mon, 09 Nov 2015 20:59:43 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 9 Nov 2015 20:59:43 -0800 (PST) In-Reply-To: <56417100.5050600@Wilcox-Tech.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> Date: Mon, 9 Nov 2015 20:59:43 -0800 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Adrian Chadd To: Anna Wilcox Cc: Sean Bruno , Marius Strobl , sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 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: Tue, 10 Nov 2015 04:59:44 -0000 On 9 November 2015 at 20:22, Anna Wilcox wrote: > > Just as a further note, I had experimented in January of this year with > making a binary pkg mirror for sun4u using my (comparatively sad) Ultra > 60 and a cross-build system. Installation was fairly straightforward > but I was having issues bringing up Clang and was having many issues > trying to build "modern" packages using GCC 4.2.1. > > See my blog for some insight: http://blog.foxkit.us/search/label/sparc Oh wow, cool, you've been busy! That's great. > > Unfortunately, truth be told, I gave up after the Freenode IRC channel > gave me a whole heap of abuse and name-calling for trying to ask for any > support with the sparc64 port. I couldn't find the documentation I > needed to keep going and nobody wanted to help. If there are others > working on this and I am not alone after all, I will gladly pull the > Ultra 60 back on to my desk and do what I can to help out. GCC 4.8 or > 4.9 would be a huge, huge, huge improvement in particular. Ugh, IRC can be jerks. Grab me on efnet (adrian) and i'll direct you into a slightly less posionous channel. :) From owner-freebsd-arch@freebsd.org Tue Nov 10 10:22:13 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 ED193A2B37F for ; Tue, 10 Nov 2015 10:22:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B981618A2; Tue, 10 Nov 2015 10:22:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by igcph11 with SMTP id ph11so46751180igc.1; Tue, 10 Nov 2015 02:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=NCtcJ89pFSyh+NCEQuSYjtSQU6g4ofymsSgd/VcyX5I=; b=hNwGb3GgF8+t8LUm4qHLXCKUFy5eVOPXzewFvNW3/VsVBSiy0JCP5xisn3pPWxadSO o0BlzNfWQ0JOB6RRFHPXPs6D57EMbZOhM2Jfrz9Jc9XuSBOV7aZzEqXvt5L/EGh9l+64 MH4Zxtnc1L1BtwjY5uQzSPlx8Xly8taO+esEwTmFGlrYd2Xii5NZTWbtnN2BKBQyz7D1 jWYwzkNuWRRa4lX4D21FJlfLev97wxD6gD+zFuFr4mwTCcPKEO665pmUDThPeRPRi3Wr B6SniCM5YzCNknuq2jkOPXReMFDsNdMw355PSK4meDnH7op8aj67cOjLUBa3AADFR6at Dk0g== X-Received: by 10.50.62.148 with SMTP id y20mr2932507igr.80.1447150932986; Tue, 10 Nov 2015 02:22:12 -0800 (PST) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id u24sm1163814ioi.14.2015.11.10.02.22.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Nov 2015 02:22:12 -0800 (PST) From: NGie Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Revisiting "Bug 46062 - Remove skel from BSD.root.dist" Date: Tue, 10 Nov 2015 02:22:10 -0800 Message-Id: Cc: remko@FreeBSD.org To: freebsd-arch Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) 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: Tue, 10 Nov 2015 10:22:14 -0000 Hi again, I did some digging around and found a past discussion started by = remko on the topic of removing /usr/share/skel 8 years ago: = https://lists.freebsd.org/pipermail/freebsd-arch/2007-November/007162.html= . The discussion didn=E2=80=99t yield anything (unfortunately) as far = as whether or not the directory should be removed (it=E2=80=99s empty = right now). /etc/skel is used by Linux, NetBSD, OpenBSD, and Solaris for = skeleton files; FreeBSD uses /usr/share/skel instead. Should the path be = linked to /usr/share/skel or deleted (potential patch here: = https://people.freebsd.org/~ngie/remove-etc-skel.patch )? Thanks! -NGie= From owner-freebsd-arch@freebsd.org Tue Nov 10 17:54:46 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 EC8C0A2CD81; Tue, 10 Nov 2015 17:54:46 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF07D1D53; Tue, 10 Nov 2015 17:54:46 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.208] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 6520E193657; Tue, 10 Nov 2015 17:54:40 +0000 (UTC) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Anna Wilcox , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> Cc: freebsd-arch , sparc64@freebsd.org From: Sean Bruno Message-ID: <56422F5F.3090407@freebsd.org> Date: Tue, 10 Nov 2015 09:54:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56417100.5050600@Wilcox-Tech.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Tue, 10 Nov 2015 17:54:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Just as a further note, I had experimented in January of this year > with making a binary pkg mirror for sun4u using my (comparatively > sad) Ultra 60 and a cross-build system. Installation was fairly > straightforward but I was having issues bringing up Clang and was > having many issues trying to build "modern" packages using GCC > 4.2.1. > > See my blog for some insight: > http://blog.foxkit.us/search/label/sparc > > Unfortunately, truth be told, I gave up after the Freenode IRC > channel gave me a whole heap of abuse and name-calling for trying > to ask for any support with the sparc64 port. I couldn't find the > documentation I needed to keep going and nobody wanted to help. If > there are others working on this and I am not alone after all, I > will gladly pull the Ultra 60 back on to my desk and do what I can > to help out. GCC 4.8 or 4.9 would be a huge, huge, huge > improvement in particular. > > --arw > > > Efnet is where a lot of freebsd folks hang out that actually want to *fix* things. If you are looking for us, #bsdmips, #bsdports are where I (sbruno) can be found. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWQi9cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kc6UIAIZvV1tXkDbOLxyEKvF5dWhL pWDoBV2WOGPaEjMaVj7u285JMCKCl8CF9YGj/qDPOPG1UZVdDAWBiCuOJJXinDSq tVYZbmlR661zkCJkICLzX1Fty6QcHvdmzo1qzoeDbVw/WYQVwlrVltp+YdVlXxuL MMSxjdFRMqxn/6D3k1mtW6M/M47Wnkh/Z3kNPLsFySHBWfhBqvMb8IEyU3lJLK1R HHjmOOuL0xYJY4epTcTH+7M2kVUD7a1NZtr/F/Aiu5sBVcQqu3rmoIh4IwtRWNXq mQmJkXCvTgMKpKeoRMDNJ97wG298lPz0uYiR1Tw33fdYkgQFIh2/c08SF5QtSbU= =KxUd -----END PGP SIGNATURE----- From owner-freebsd-arch@freebsd.org Tue Nov 10 18:32:58 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 5ED2BA2B90C for ; Tue, 10 Nov 2015 18:32:58 +0000 (UTC) (envelope-from cameronsparr@gmail.com) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 224EA1336 for ; Tue, 10 Nov 2015 18:32:58 +0000 (UTC) (envelope-from cameronsparr@gmail.com) Received: by ykba77 with SMTP id a77so8659558ykb.2 for ; Tue, 10 Nov 2015 10:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oOfr9RMnahTjsosSUdxqKrcJlwkWq8QpuADu8uc6NJU=; b=ImZ8cKZXA86ECMTkvnC0mzZ9lTK9LGyAVP2uEalT23oF4d440nPNjE3F9KaID1D2u6 lD33Kt41HbSD7KwWLKSA133NGktgqNtDmnjR0t33N1kCpoEgnzH7oupJ3qOnHQoACzKy d1ZbyB0s+3RRaUdAoPQetMzbsU5rPXu3ZLHLrQU2U9dCeYFSpVEB0Zm+4brjwPdv69DS yn39b5wDnY99oNweJAgC/QgaUhVKOawvcCkd+QTYjyfUntUS7juoVtk9GordhkO3/Wck kl3dL9Y5LM98nA+xy5+7/jXFUc3cE5jMxcs1Gyzi8UirpNP72mcz1ccrdCfuLDkLngVV q6+A== MIME-Version: 1.0 X-Received: by 10.129.156.193 with SMTP id t184mr4278220ywg.177.1447180377200; Tue, 10 Nov 2015 10:32:57 -0800 (PST) Received: by 10.129.102.68 with HTTP; Tue, 10 Nov 2015 10:32:57 -0800 (PST) Date: Tue, 10 Nov 2015 11:32:57 -0700 Message-ID: Subject: setsockopt() handling of kern.ipc.maxsockbuf limit From: Cameron Sparr To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Tue, 10 Nov 2015 18:32:58 -0000 Sent an email yesterday already but I'm just bumping this one as I've submitted a something through bugzilla to track this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204438 I also added a little more details there comparing the behavior to how Linux handles the same setsockopt function. From owner-freebsd-arch@freebsd.org Tue Nov 10 22:10:51 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 5AF6CA2CAF8; Tue, 10 Nov 2015 22:10:51 +0000 (UTC) (envelope-from jacob.ritorto@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E946E1AAF; Tue, 10 Nov 2015 22:10:50 +0000 (UTC) (envelope-from jacob.ritorto@gmail.com) Received: by wmec201 with SMTP id c201so22450842wme.1; Tue, 10 Nov 2015 14:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bFuTZ4+mFaK9Xdo66PCw7SfqoHSp46JAEh7ypV3Zhw0=; b=yp1obvlBXKfkzOuXNABIvliOltSiNWTFthN+1Kk0N1cd+lc97ocfcP7Zc9SvmT4Hxi GQHdo+HLRkn6Kyw4rEePPJ9Q2tB/fbCaOi8bJBX4ByMCL7cuPxxdEv1Gotea93iJ45oq pcnT/Ay0PYb28UyYVSmOFrwFLB4YRr+uDrMekX/CrFFcCFpkJFyMaAjhY4RDv2EwxA/U mRN8prxKZmNn122e8kNMJzpSW3CUbAsJnWjPmF56YKUe/D+cSQ0raFzxFSzd5rFRYqYt xsNTMhWss0uXO4LjcptIhigZpBYrO2uxTUYZUSJgHx2lqFHAq841dzjkZb4gfGHEDqLx /g8g== MIME-Version: 1.0 X-Received: by 10.194.159.100 with SMTP id xb4mr6320119wjb.136.1447193448448; Tue, 10 Nov 2015 14:10:48 -0800 (PST) Received: by 10.27.14.98 with HTTP; Tue, 10 Nov 2015 14:10:48 -0800 (PST) In-Reply-To: <56422F5F.3090407@freebsd.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <56422F5F.3090407@freebsd.org> Date: Tue, 10 Nov 2015 17:10:48 -0500 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Jacob Ritorto To: "freebsd-sparc64@freebsd.org" , freebsd-arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Tue, 10 Nov 2015 22:10:51 -0000 Just to put it out there, I looked at FreeBSD on SPARC sometime last year and found it to be working but lacking current development libs, graphics and desktop stuff so badly that it was essentially unusable, so I reverted to an Illumos-based distro. Sorry. If there's call for, desire and hope of making modern FreeBSD plus most ports work _well_ on this platform, then I'm all in to help. I have lots of sparc64 machines: ultra 1,2,5, sunblade 150 and 2000, netra 1 and some t-1000/2000 boxes, too (and quite a load of 32-bit sparc machines, come to think of it). Would like to help with the effort if you can find a use for me. I've not done much sparc assembly but have done some c and could certainly help to test stuff. Familiar with git, svn, etc. and building software, bug filing, etc.. thx jake On Tue, Nov 10, 2015 at 12:54 PM, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > Just as a further note, I had experimented in January of this year > > with making a binary pkg mirror for sun4u using my (comparatively > > sad) Ultra 60 and a cross-build system. Installation was fairly > > straightforward but I was having issues bringing up Clang and was > > having many issues trying to build "modern" packages using GCC > > 4.2.1. > > From owner-freebsd-arch@freebsd.org Tue Nov 10 22:26:42 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 4A811A2CE29 for ; Tue, 10 Nov 2015 22:26:42 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) 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 29C72148D for ; Tue, 10 Nov 2015 22:26:42 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 27532A2CE28; Tue, 10 Nov 2015 22:26:42 +0000 (UTC) Delivered-To: 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 0CEE6A2CE27 for ; Tue, 10 Nov 2015 22:26:42 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A38DA148A; Tue, 10 Nov 2015 22:26:41 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmvv187 with SMTP id v187so30717828wmv.1; Tue, 10 Nov 2015 14:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=XPH2Gwpt+E4sRfSI8wFrm0w8LBy2/7HmIIwrhc50cK4=; b=zMDgAP+NHTR2jPPieNgvmD2J9cLvocmfyRE7uJhIQ0qfg/2Re4yVc0QtoktJbJblU4 PVX73pve8LAjTX3IvtGNi2PCLJOcCOONR/BGHOsF2Gz69rqqM62Hh6NSFfaZCZ69NgO9 p+c67EQfpBO+Suei2CQ7ehgm25I/0IzSdaiIzlATIXLbz2plaNKwoMO5SGVILhS9AKIg AkxMwBRLfrJS1BSonWxx1HbSjHQpzShOhoqDS5AoggBu4AVr+GycEZX8xUC6NFO7U/gV g7+H+cTlDtFnY694Lt3Blg2YMjGKZWx3BuK+zS38irVkJdEw2xyduNAvpDfQFkZqMJAk K8Iw== X-Received: by 10.194.114.70 with SMTP id je6mr6409921wjb.7.1447194400154; Tue, 10 Nov 2015 14:26:40 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id at4sm5803963wjc.9.2015.11.10.14.26.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2015 14:26:39 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 10 Nov 2015 23:26:37 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org Cc: ache@FreeBSD.org, marino@FreeBSD.org Subject: Question about ASCII and nl_langinfo (locale work) Message-ID: <20151110222636.GN10134@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mkHYMT4O8DyWoHkb" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) 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: Tue, 10 Nov 2015 22:26:42 -0000 --mkHYMT4O8DyWoHkb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, When merging the new collation, the locales has been reworked. ache@ raised a good point about LOCALE C and POSIX and by extension the locales US-ASCII: should we take the opportunity to change that: First a desciption of the situation: nl_langinfo is not normalised each OS can return the encoding they want. While it is pretty obvious about what should be returned for for regular encodings (iso-8859* or UTF-8), for C and POSIX locales, FreeBSD used to return US-ASCII (and does it again since today). Lots of third party application (python, perl, tcl etc) tries to figure out the encoding by matching against a table of "known" output of nl_langinfo() The thing is not all are aware that FreeBSD uses US-ASCII, for example tcl does not. which means tcl is not able to determine what encoding is needed for the C and POSIX locales. On Linux they to return ANSI_X3.4-1968 (also known as US-ASCII) and most application knows what linux returns. That means we need to teach all upstream about US-ASCII all the time. The proposals are: - Do not change what we have always done. - Change it to something that makes sense "C" (what we tried with "POSIX" which was a very bad idea, but "C" seems to be commonly recognised by application as ASCII) - Let's report the same as Linux, that will simplify portability - Let's be obvious and report ASCII (also commonly recognised by applications) The next question is if we change the above, would it make sense to also report ASCII for ASCII locales: - en_AU.US-ASCII - en_CA.US-ASCII - en_GB.US-ASCII - en_NZ.US-ASCII - en_US.US-ASCII - en_ZA.US-ASCII Which would require some work or should we make them return ASCII or even ANSI_X3.4-1968. Please share your opinion here Best regards, Bapt --mkHYMT4O8DyWoHkb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZCbxwACgkQ8kTtMUmk6Ez/4gCgiMNoUGncG+seIgNwrgnKpv7J X0UAoKz2dTIiak5OmV7hXTFDtwrSiwJ0 =jqIF -----END PGP SIGNATURE----- --mkHYMT4O8DyWoHkb-- From owner-freebsd-arch@freebsd.org Tue Nov 10 22:27:40 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 1D698A2CE60; Tue, 10 Nov 2015 22:27:40 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 016A9156C; Tue, 10 Nov 2015 22:27:39 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NXM00EB9EOOYY00@hades.sorbs.net>; Tue, 10 Nov 2015 14:34:02 -0800 (PST) Message-id: <56426F52.80709@sorbs.net> Date: Tue, 10 Nov 2015 23:27:30 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Anna Wilcox Cc: Sean Bruno , Marius Strobl , sparc64@freebsd.org, freebsd-arch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> In-reply-to: <56417100.5050600@Wilcox-Tech.com> 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: Tue, 10 Nov 2015 22:27:40 -0000 Anna Wilcox wrote: > Unfortunately, truth be told, I gave up after the Freenode IRC channel > gave me a whole heap of abuse and name-calling for trying to ask for any > support with the sparc64 port. I couldn't find the documentation I > Odd, I didn't see that (I'm there most of the time) but yeah they can be a harsh crowd.. I also asked about sparc there didn't get anywhere so dropped it ( I have a U60 (Sol10), a E450(Sol8), 2xE3500's(Sol10), 2xE3000's (decommissioned) and 2 Netra T1's (running FBSD9.2 currently) - and was looking to changing them all to FreeBSD - but then I realized there was little chance of patches so gave up... until this thread. ) -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arch@freebsd.org Wed Nov 11 01:50:59 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 9DFC3A2AA8D for ; Wed, 11 Nov 2015 01:50:59 +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 7A41013D6; Wed, 11 Nov 2015 01:50:59 +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 92898B95B; Tue, 10 Nov 2015 20:50:58 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Cc: NGie Cooper , remko@freebsd.org Subject: Re: Revisiting "Bug 46062 - Remove skel from BSD.root.dist" Date: Tue, 10 Nov 2015 10:20:25 -0800 Message-ID: <1580231.TzCMMyCl6z@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Nov 2015 20:50:58 -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 01:50:59 -0000 On Tuesday, November 10, 2015 02:22:10 AM NGie Cooper wrote: > Hi again, > =09I did some digging around and found a past discussion started by r= emko on the topic of removing /usr/share/skel 8 years ago: https://list= s.freebsd.org/pipermail/freebsd-arch/2007-November/007162.html . The di= scussion didn=E2=80=99t yield anything (unfortunately) as far as whethe= r or not the directory should be removed (it=E2=80=99s empty right now)= . /etc/skel is used by Linux, NetBSD, OpenBSD, and Solaris for skeleton= files; FreeBSD uses /usr/share/skel instead. Should the path be linked= to /usr/share/skel or deleted (potential patch here: https://people.fr= eebsd.org/~ngie/remove-etc-skel.patch )? Removing /etc/skel you mean? It's empty, but /usr/share/skel is not em= pty. Does anything outside of the base system use /etc/skel or /usr/share/sk= el? --=20 John Baldwin From owner-freebsd-arch@freebsd.org Wed Nov 11 05:54:47 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 ACCE3A22BE1 for ; Wed, 11 Nov 2015 05:54:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51C7B1790 for ; Wed, 11 Nov 2015 05:54:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkas77 with SMTP id s77so8404048qka.0 for ; Tue, 10 Nov 2015 21:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yCaiO9dIS4gR0WnQ+WNMsZ1CqUcRzpclKOO22DpazL4=; b=C/b52v/Ex1VugdbvwkDBRjPqwfjYJuBZksDfNCPJKASVUf2OZddgiLOy9ydE1w+gsO /N/T8WGaZRYzWrE9pozTMIE2Oz7Muw2pRBzdb+8P7V9cO5+L6KFkNYrO0TAsLiZcch+4 IGXq+XczRobjgUKPJK/E/9xkyQzZZAqJQEyULInVdOV5nZhZzaAMf2xiNX95vf/3FWTS W+LibkyttC/JLst/0XHf16rJR0ErsH7cxK/vJ6pg2Erj8KBW/MtDh69oD8Qi3LgXBeWc 7SAqSjR4oIh5TKu5QBkKXwsRoOIbSK2HOQee9qGjuZS0b9pDlmrX5XT7Wco9QXQC+vtz 60Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yCaiO9dIS4gR0WnQ+WNMsZ1CqUcRzpclKOO22DpazL4=; b=cNx0+ZJZx4lvrwyo9aFdFPfZFaOF8Jh9UMr9Xxz3L1eTtxyKWle1T5ptvmV3wptf8+ UWfpf2k5FO3nawCw4uP3niionv4pYHYTb70VuEusCoq/uTQZvA8TChsobV+nNxafjSNz eho5pFPZSdDYJiUyi9P1CRty8STPFlkT8AY98JAHUmYGB3Q27gyxMZygRJ7rAGVm7Zmj xCIVJJkqn8gik+kyVqVy39QKYe2D3+snMeah/XhFmUHO3mk8IcQbunVFSxPB90gJo01h UppQeC5bJXA5J/DblCnOZNGrlOkVCySgpIy5cDlBOPzONa6vSHzwK1t/rAmmJ03STA2p +joQ== X-Gm-Message-State: ALoCoQlzttc0poTxgo/G79yDKvNR+DAlmJFv1rhZh1QnHsfRQeQVPZpTUXlhwsUSch5nAdBB32e8 MIME-Version: 1.0 X-Received: by 10.55.23.170 with SMTP id 42mr8853994qkx.42.1447221286195; Tue, 10 Nov 2015 21:54:46 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 10 Nov 2015 21:54:46 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <56417100.5050600@Wilcox-Tech.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> Date: Tue, 10 Nov 2015 22:54:46 -0700 X-Google-Sender-Auth: DvkZXFauBGmGTBZw9Tx1wa65x_w Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Warner Losh To: Anna Wilcox Cc: Sean Bruno , Marius Strobl , sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 05:54:47 -0000 On Mon, Nov 9, 2015 at 9:22 PM, Anna Wilcox wrote: > > Just as a further note, I had experimented in January of this year with > making a binary pkg mirror for sun4u using my (comparatively sad) Ultra > 60 and a cross-build system. Installation was fairly straightforward > but I was having issues bringing up Clang and was having many issues > trying to build "modern" packages using GCC 4.2.1. > > See my blog for some insight: http://blog.foxkit.us/search/label/sparc > > Unfortunately, truth be told, I gave up after the Freenode IRC channel > gave me a whole heap of abuse and name-calling for trying to ask for any > support with the sparc64 port. I couldn't find the documentation I > needed to keep going and nobody wanted to help. If there are others > working on this and I am not alone after all, I will gladly pull the > Ultra 60 back on to my desk and do what I can to help out. GCC 4.8 or > 4.9 would be a huge, huge, huge improvement in particular. > sparc64 is the odd-man out currently. However, even if clang doesn't work, the gcc external toolchain works well for other platforms. If it makes sprac64 more viable, then so much the better. There should even be a 5.0 gcc port that's keyed into the new CROSS_TARGET stuff, if that works for the ports. If the many other offers of help fall through, then I'd be happy to act as a backup to get patches into the tree. If there's enough people working on this, we may win from getting more developers into the project and it may be viable for another release cycle. While nothing is definite, if nothing is done the outcome is certain. As for the bozos on IRC on Freenode, I'm just glad that you spoke up about what you'd done. That's the best revenge when I've had people discourage me in the past: to show them what's possible when you step away from the can't do attitude. So, have you found the docs you need? Warner From owner-freebsd-arch@freebsd.org Wed Nov 11 06:55:42 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 871C1A2B88C for ; Wed, 11 Nov 2015 06:55:42 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DEAC118E for ; Wed, 11 Nov 2015 06:55:41 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) X-ASG-Debug-ID: 1447224940-08ca040e8524e920001-RYubVt Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id phvaTssl2Ia7gcah (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Nov 2015 22:55:40 -0800 (PST) X-Barracuda-Envelope-From: jkh@mail.turbofuzz.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.8.0.30] (unknown [10.8.0.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 75D0AA01D1; Tue, 10 Nov 2015 22:55:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3108\)) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Jordan Hubbard X-ASG-Orig-Subj: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 In-Reply-To: Date: Tue, 10 Nov 2015 22:55:38 -0800 Cc: Anna Wilcox , freebsd-arch , Sean Bruno , sparc64@freebsd.org, Marius Strobl Content-Transfer-Encoding: quoted-printable Message-Id: <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> To: Warner Losh X-Mailer: Apple Mail (2.3108) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1447224940 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 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 06:55:42 -0000 > On Nov 10, 2015, at 9:54 PM, Warner Losh wrote: >=20 > sparc64 is the odd-man out currently. However, even if clang doesn't > work, the gcc external toolchain works well for other platforms. If it = makes > sprac64 more viable, then so much the better.=20 Hi Warner, I hate to be a voice of pragmatism here when we=E2=80=99re having so = much fun discussing it from an architectural perspective, but=E2=80=A6 What=E2=80=99s the actual goal (from a future market relevance = perspective) of putting resources, any resources, into sparc64? I think = that=E2=80=99s the key question that needs to get asked and answered = here since we all know that: 1) FreeBSD is not NetBSD - it has never historically supported =E2=80=9Cx8= 6 alternative architectures=E2=80=9D just because they existed and might = be technically interesting to port to, there had to be some sort of user = community numbers to justify the time and energy expended for the = project as a whole (and even in an all-volunteer driven project, there = is simply no such thing as =E2=80=9Cfree=E2=80=9D - everything has a = cost somewhere). As phk noted earlier in the thread, the ALPHA port was an exception to = this rule simply because it was the first-ever 64 bit port for FreeBSD = and we knew it would buy us some much-needed 64 bit cleanliness, but it = also fell off the support roadmap and into the history books once = ALPHA=E2=80=99s market relevance had clearly ended. NetBSD/alpha still exists, all the way up to and including NetBSD 7.0, = because their slogan is =E2=80=9COf course it runs NetBSD.=E2=80=9D = Again, FreeBSD !=3D NetBSD. The emphasis on market share is and always = has been a key differentiator for FreeBSD and part of both its own = slogans and mission statement. 2) Sparc64 global market share has declined significantly since Oracle = purchased Sun, leaving Oracle and Fujitsu as the only two significant = players in that market. Sure, putting =E2=80=9Cold equipment to work=E2=80= =9D is also always a tempting objective, but it=E2=80=99s one that = really requires viewing through an objective lens since the perspective = of someone who owns said "old equipment" is rather more biased than the = perspective of the market as a whole. The market as a whole appears to = consist (in terms of global server market share): HP (x64) 27.6% IBM (x64) 22.9% DELL (x64) 16.4% All others (x64): 24% (combined estimate, including Cisco and = Huawei) Total: 90.9% [ Source: Gartner ] That leaves 9.1% for the rest of the server industry, which includes = Itanium, POWER4 and SPARC64. We can also probably safely assume that = even amongst that tiny 9% pie slice, vendors are focused on the future = since their overall market share is declining (about 5% annually), which = begs the question: Is FreeBSD/SPARC64 aiming at the T5, even while = Oracle themselves are shifting emphasis to lower-cost x64 systems for = which FreeBSD is already competitive, or is it really just trying to = keep some older collection of increasingly power/performance inefficient = (by comparison) alive? Again, what=E2=80=99s the long-term goal of supporting this = architecture? The old adage about =E2=80=9Cpicking your battles=E2=80=9D = applies here, no matter how enthusiastic the small community of = remaining SPARC users might be, which is why I am risking lightning = bolts of wrath from SPARC zealots in even daring to ask the question. = :-) Thanks, - Jordan From owner-freebsd-arch@freebsd.org Wed Nov 11 08:45:01 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 AFEC0A1FF38; Wed, 11 Nov 2015 08:45:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E35A17B1; Wed, 11 Nov 2015 08:45:00 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id tAB8ieLP080021 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Nov 2015 19:44:46 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id tAB8iX5V094214 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Nov 2015 19:44:34 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id tAB8iWvX094213; Wed, 11 Nov 2015 19:44:32 +1100 (AEDT) (envelope-from peter) Date: Wed, 11 Nov 2015 19:44:32 +1100 From: Peter Jeremy To: Jordan Hubbard Cc: sparc64@freebsd.org, freebsd-arch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151111084432.GC67251@server.rulingia.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Wed, 11 Nov 2015 19:44:47 +1100 (AEDT) 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 08:45:01 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Nov-10 22:55:38 -0800, Jordan Hubbard wrot= e: >Again, what=E2=80=99s the long-term goal of supporting this architecture? The things that sparc64 give us that x86 doesn't are big-endian and strict alignment. In theory, MIPS, PPC and ARM can give us both of those but I'm non sure whether we actually have any big-endian variants of them. --=20 Peter Jeremy --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWQv/wXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0Mw8P/0wJZuT/QdnrIfHfU0mdTWAg 0QdPoBQ2Amg0Sn6p0Pt2sWSY3JjKSL2HG7LhAr0v6nB41rU/v5QPSA/x5iCrjvMy z38kbkOYRH2qx4+b2d2bcDKPxXIYu5Dp55cM2BDOhkAM+Qw5BsJfN7zq48qQwndj UNtNrwUdQJK3zzLCPFXehmWTzg3B5nBRI0CDJarfI1NxVuFJR45TU+n9A6TBDxt8 PWJNNSHsQynqW+m/c+xaKUrMTaCYVI6MUVrxf7HcNm8lRhZ6f3t75phzsc5bHHGC 2859XRmbxBlF3xpSPCAuDFavD0N09rcCuxjEm8tH9gOhehltDSTrMDa4zZ8v+e5u O387oM+yivjWkr0NUYhuwklcB2CSe74gdlEka2u/HaUwSJtGP4d200B5Q3SE6zft 29Qdnlt3516K4zroHVFpoh+DEhvxdJHRH0uMigG7s159SqAALsNxw4nWhngqtSAV Gfgv1uvkKfrzdqexx7iynTY9Xtf3Yh//f7vwxfJFaPR0Altj4aa/gN9h1I32KyMW ccx4oUJwRzhgsyudNe8yEloWaowpHmIpxh3FrUBZgNV5kFAo8WaN9C8BXSL7tJML Ll9aJzFPU+TVSB6qmIKumHdiIKOUXcsiBV1DW6M6+TYUGOgmauvXrGcYqNEI757q 9faF0hkMJAZKlASalkfn =KnTq -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-arch@freebsd.org Wed Nov 11 12:28:26 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 8D01AA2B70D for ; Wed, 11 Nov 2015 12:28:26 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 530DE1F05 for ; Wed, 11 Nov 2015 12:28:26 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 4C016681C for ; Wed, 11 Nov 2015 13:28:24 +0100 (CET) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: freebsd-arch@freebsd.org References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <20151111084432.GC67251@server.rulingia.com> From: Jan Bramkamp Message-ID: <56433467.1040000@rlwinm.de> Date: Wed, 11 Nov 2015 13:28:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151111084432.GC67251@server.rulingia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 12:28:26 -0000 On 11/11/15 09:44, Peter Jeremy wrote: > On 2015-Nov-10 22:55:38 -0800, Jordan Hubbard wrote: >> Again, what’s the long-term goal of supporting this architecture? > > The things that sparc64 give us that x86 doesn't are big-endian and > strict alignment. In theory, MIPS, PPC and ARM can give us both of > those but I'm non sure whether we actually have any big-endian > variants of them. > These days the cheapest new MIPS64 system you can get is a Ubiquiti EdgeRouter Lite with dual-core 500MHz Cavium Octeon 1+. I don't know if they support little-endian but the FreeBSD port to them uses big-endian. Since the u-boot bootloader isn't locked down you can just modify the startup script and boot from either TFTP or local USB storage. From owner-freebsd-arch@freebsd.org Wed Nov 11 14:00:42 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 2A6FDA2CD18; Wed, 11 Nov 2015 14:00:42 +0000 (UTC) (envelope-from alexmcwhirter@triadic.us) Received: from SMTP.Tech.Triadic.US (smtp.tech.triadic.us [98.102.61.98]) by mx1.freebsd.org (Postfix) with ESMTP id ECF3C17C5; Wed, 11 Nov 2015 14:00:41 +0000 (UTC) (envelope-from alexmcwhirter@triadic.us) Received: from localhost (unknown [10.128.0.32]) by SMTP.Tech.Triadic.US (Postfix) with ESMTP id 7C3BC1040681; Wed, 11 Nov 2015 08:53:10 -0500 (EST) X-Virus-Scanned: amavisd-new at Tech.Triadic.US Received: from SMTP.Tech.Triadic.US ([IPv6:::ffff:10.128.0.24]) by localhost (Milter1.Tech.Triadic.US [IPv6:::ffff:10.128.0.32]) (amavisd-new, port 10024) with LMTP id jZLD4M9QBgTK; Wed, 11 Nov 2015 08:53:09 -0500 (EST) Received: from [10.0.0.185] (cpe-24-29-169-98.cinci.res.rr.com [24.29.169.98]) by SMTP.Tech.Triadic.US (Postfix) with ESMTPSA id B70921040434; Wed, 11 Nov 2015 08:52:59 -0500 (EST) Date: Wed, 11 Nov 2015 09:00:11 -0500 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> X-Android-Message-ID: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> In-Reply-To: <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> From: Alex McWhirter To: Jordan Hubbard Cc: Warner Losh , Sean Bruno , freebsd-arch , sparc64@freebsd.org, Anna Wilcox , Marius Strobl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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 14:00:42 -0000 VGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBtb3N0IG9mIHRoZSBkaXNjb250aW51ZWQgYXJjaGl0ZWN0 dXJlcyBhbmQgU1BBUkMgaXMgdGhhdCBPcmFjbGUgaXMgc2hvd2luZyBtb3JlIGFuZCBtb3JlIGlu dGVyZXN0IGluIGRldmVsb3BpbmcgdGhlaXIgU1BBUkMgcGxhdGZvcm0uIEFscGhhIHdhcyBraWxs ZWQgYnkgSFAsIEl0YW5pdW0gaXMgc29vbiB0byBiZSBraWxsZWQgYnkgSW50ZWwgLCBtaXBzIHdh cyBtb3JlIG9yIGxlc3Mga2lsbGVkIHdoZW4gc2dpIHdlbnQgdW5kZXIuIFRoZSBtb3N0IGltcG9y dGFudCBhc3BlY3QgaXMgdGhhdCBTUEFSQyBtYWNoaW5lcyBhcmUgc3RpbGwgYmVpbmcgYnVpbHQg YW5kIE9yYWNsZSBoYXMgbm8gcGxhbnMgdG8ga2lsbCBpdCBpbiB0aGUgbmVhciBmdXR1cmUuCgpJ ZiB5b3UgY29uc2lkZXIgdGhlIGFybSBwb3J0LCB3aGVuIGl0IGNvbWVzIHRvIGFsdGVybmF0aXZl IG9wZXJhdGluZyBzeXN0ZW1zIGl0IHByb2JhYmx5IGhhcyBldmVuIGEgc21hbGxlciBtYXJrZXQg c2hhcmUgdGhhbiBzcGFyYy4gVGhlIG9ubHkgdGhpbmcgcmVhbGx5IGRyaXZpbmcgdGhhdCBtYXJr ZXQgdG93YXJkcyBhIGRpcmVjdGlvbiBpbiB3aGljaCBhbHRlcm5hdGl2ZSBvcGVyYXRpbmcgc3lz dGVtcyBiZWNvbWUgbW9yZSBmZWFzaWJsZSBpcyBBTUQncyBwbGF0Zm9ybS4gQW5kIGV2ZW4gaW4g dGhhdCBjYXNlIGl0IHdpbGwgbGlrZWx5IGJlIGEgbmljaGUgYXJjaGl0ZWN0dXJlIGFuZCBwcm9i YWJseSBoYXZlIGFuIGV2ZW4gc21hbGxlciBtYXJrZXQgc2hhcmUgdGhhbiBzcGFyYywgYXQgbGVh c3QgaW4gdGhlIGVhcmx5IGRheXMgYW55d2F5cy4KCkFzIGxvbmcgYXMgdGhlIGhhcmR3YXJlIGlz IHN0aWxsIGJlaW5nIG1hbnVmYWN0dXJlZCwgdGhlcmUgYXJlIHBlb3BsZSB3aG8gd2FudCBhbHRl cm5hdGl2ZSBvcGVyYXRpbmcgc3lzdGVtcywgYW5kIHRoZXJlIGFyZSBkZXZlbG9wZXJzIHdobyB1 bmRlcnN0YW5kIHRoZSBoYXJkd2FyZSwgdGhlbiB0aGUgZmVhc2liaWxpdHkgZm9yIHRoZSBGcmVl QlNEIHBvcnQgZXhpc3RzIGluIG15IG9waW5pb24uIElsbHVtb3MgaGFzIGJlZW4gdmVyaWZpZWQg b24gdGhlIHQ0IHdoaWNoIHByb2JhYmx5IG1lYW5zIHRoZSB0NSB3b3JrcyBhcyB3ZWxsLiBBcyBm YXIgYXMgdGhlIFQgNiBvciBUIDcgaXMgY29uY2VybmVkIGl0IG1heSBiZSAgZGlmZmVyZW50LgoK SSd2ZSBzYXQgaW4gb24gbXkgb3duIGZhaXIgc2hhcmUgb2YgT3JhY2xlIG1lZXRpbmdzIG92ZXIg dGhlIHBhc3QgZmV3IG1vbnRocywgYW5kIHRoZXkgYXJlIGRvaW5nIGV2ZXJ5dGhpbmcgaW4gdGhl aXIgcG93ZXIgdG8gcHVzaCB0aGVpciBjdXN0b21lcnMgb24gc3BhcmMgYW5kIFNvbGFyaXMuIAoK QWxleCBzZW50IHRoZSBtZXNzYWdlLCBidXQgaGlzIHBob25lIHNlbnQgdGhlIHR5cG9zLi4uCgpP biBOb3YgMTEsIDIwMTUgMTo1NSBBTSwgSm9yZGFuIEh1YmJhcmQgPGpraEBtYWlsLnR1cmJvZnV6 ei5jb20+IHdyb3RlOgo+Cj4KPiA+IE9uIE5vdiAxMCwgMjAxNSwgYXQgOTo1NCBQTSwgV2FybmVy IExvc2ggPGltcEBic2RpbXAuY29tPiB3cm90ZToKPiA+IAo+ID4gc3BhcmM2NCBpcyB0aGUgb2Rk LW1hbiBvdXQgY3VycmVudGx5LiBIb3dldmVyLCBldmVuIGlmIGNsYW5nIGRvZXNuJ3QKPiA+IHdv cmssIHRoZSBnY2MgZXh0ZXJuYWwgdG9vbGNoYWluIHdvcmtzIHdlbGwgZm9yIG90aGVyIHBsYXRm b3Jtcy4gSWYgaXQgbWFrZXMKPiA+IHNwcmFjNjQgbW9yZSB2aWFibGUsIHRoZW4gc28gbXVjaCB0 aGUgYmV0dGVyLgo+Cj4gSGkgV2FybmVyLAo+Cj4gSSBoYXRlIHRvIGJlIGEgdm9pY2Ugb2YgcHJh Z21hdGlzbSBoZXJlIHdoZW4gd2XigJlyZSBoYXZpbmcgc28gbXVjaCBmdW4gZGlzY3Vzc2luZyBp dCBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGVyc3BlY3RpdmUsIGJ1dOKApgo+Cj4gV2hhdOKAmXMg dGhlIGFjdHVhbCBnb2FsIChmcm9tIGEgZnV0dXJlIG1hcmtldCByZWxldmFuY2UgcGVyc3BlY3Rp dmUpIG9mIHB1dHRpbmcgcmVzb3VyY2VzLCBhbnkgcmVzb3VyY2VzLCBpbnRvIHNwYXJjNjQ/wqAg SSB0aGluayB0aGF04oCZcyB0aGUga2V5IHF1ZXN0aW9uIHRoYXQgbmVlZHMgdG8gZ2V0IGFza2Vk IGFuZCBhbnN3ZXJlZCBoZXJlIHNpbmNlIHdlIGFsbCBrbm93IHRoYXQ6Cj4KPiAxKSBGcmVlQlNE IGlzIG5vdCBOZXRCU0QgLSBpdCBoYXMgbmV2ZXIgaGlzdG9yaWNhbGx5IHN1cHBvcnRlZCDigJx4 ODYgYWx0ZXJuYXRpdmUgYXJjaGl0ZWN0dXJlc+KAnSBqdXN0IGJlY2F1c2UgdGhleSBleGlzdGVk IGFuZCBtaWdodCBiZSB0ZWNobmljYWxseSBpbnRlcmVzdGluZyB0byBwb3J0IHRvLCB0aGVyZSBo YWQgdG8gYmUgc29tZSBzb3J0IG9mIHVzZXIgY29tbXVuaXR5IG51bWJlcnMgdG8ganVzdGlmeSB0 aGUgdGltZSBhbmQgZW5lcmd5IGV4cGVuZGVkIGZvciB0aGUgcHJvamVjdCBhcyBhIHdob2xlIChh bmQgZXZlbiBpbiBhbiBhbGwtdm9sdW50ZWVyIGRyaXZlbiBwcm9qZWN0LCB0aGVyZSBpcyBzaW1w bHkgbm8gc3VjaCB0aGluZyBhcyDigJxmcmVl4oCdIC0gZXZlcnl0aGluZyBoYXMgYSBjb3N0IHNv bWV3aGVyZSkuCj4KPiBBcyBwaGsgbm90ZWQgZWFybGllciBpbiB0aGUgdGhyZWFkLCB0aGUgQUxQ SEEgcG9ydCB3YXMgYW4gZXhjZXB0aW9uIHRvIHRoaXMgcnVsZSBzaW1wbHkgYmVjYXVzZSBpdCB3 YXMgdGhlIGZpcnN0LWV2ZXIgNjQgYml0IHBvcnQgZm9yIEZyZWVCU0QgYW5kIHdlIGtuZXcgaXQg d291bGQgYnV5IHVzIHNvbWUgbXVjaC1uZWVkZWQgNjQgYml0IGNsZWFubGluZXNzLCBidXQgaXQg YWxzbyBmZWxsIG9mZiB0aGUgc3VwcG9ydCByb2FkbWFwIGFuZCBpbnRvIHRoZSBoaXN0b3J5IGJv b2tzIG9uY2UgQUxQSEHigJlzIG1hcmtldCByZWxldmFuY2UgaGFkIGNsZWFybHkgZW5kZWQuCj4K PiBOZXRCU0QvYWxwaGEgc3RpbGwgZXhpc3RzLCBhbGwgdGhlIHdheSB1cCB0byBhbmQgaW5jbHVk aW5nIE5ldEJTRCA3LjAsIGJlY2F1c2UgdGhlaXIgc2xvZ2FuIGlzIOKAnE9mIGNvdXJzZSBpdCBy dW5zIE5ldEJTRC7igJ3CoMKgIEFnYWluLCBGcmVlQlNEICE9IE5ldEJTRC7CoCBUaGUgZW1waGFz aXMgb24gbWFya2V0IHNoYXJlIGlzIGFuZCBhbHdheXMgaGFzIGJlZW4gYSBrZXkgZGlmZmVyZW50 aWF0b3IgZm9yIEZyZWVCU0QgYW5kIHBhcnQgb2YgYm90aCBpdHMgb3duIHNsb2dhbnMgYW5kIG1p c3Npb24gc3RhdGVtZW50Lgo+Cj4gMikgU3BhcmM2NCBnbG9iYWwgbWFya2V0IHNoYXJlIGhhcyBk ZWNsaW5lZCBzaWduaWZpY2FudGx5IHNpbmNlIE9yYWNsZSBwdXJjaGFzZWQgU3VuLCBsZWF2aW5n IE9yYWNsZSBhbmQgRnVqaXRzdSBhcyB0aGUgb25seSB0d28gc2lnbmlmaWNhbnQgcGxheWVycyBp biB0aGF0IG1hcmtldC7CoCBTdXJlLCBwdXR0aW5nIOKAnG9sZCBlcXVpcG1lbnQgdG8gd29ya+KA nSBpcyBhbHNvIGFsd2F5cyBhIHRlbXB0aW5nIG9iamVjdGl2ZSwgYnV0IGl04oCZcyBvbmUgdGhh dCByZWFsbHkgcmVxdWlyZXMgdmlld2luZyB0aHJvdWdoIGFuIG9iamVjdGl2ZSBsZW5zIHNpbmNl IHRoZSBwZXJzcGVjdGl2ZSBvZiBzb21lb25lIHdobyBvd25zIHNhaWQgIm9sZCBlcXVpcG1lbnQi IGlzIHJhdGhlciBtb3JlIGJpYXNlZCB0aGFuIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgbWFya2V0 IGFzIGEgd2hvbGUuwqAgVGhlIG1hcmtldCBhcyBhIHdob2xlIGFwcGVhcnMgdG8gY29uc2lzdCAo aW4gdGVybXMgb2YgZ2xvYmFsIHNlcnZlciBtYXJrZXQgc2hhcmUpOgo+Cj4gSFAgKHg2NCkgMjcu NiUKPiBJQk0gKHg2NCkgMjIuOSUKPiBERUxMICh4NjQpIDE2LjQlCj4gQWxsIG90aGVycyAoeDY0 KTogMjQlIChjb21iaW5lZCBlc3RpbWF0ZSwgaW5jbHVkaW5nIENpc2NvIGFuZCBIdWF3ZWkpCj4g VG90YWw6IDkwLjklCj4KPiBbIFNvdXJjZTogR2FydG5lciBdCj4KPiBUaGF0IGxlYXZlcyA5LjEl IGZvciB0aGUgcmVzdCBvZiB0aGUgc2VydmVyIGluZHVzdHJ5LCB3aGljaCBpbmNsdWRlcyBJdGFu aXVtLCBQT1dFUjQgYW5kIFNQQVJDNjQuwqDCoCBXZSBjYW4gYWxzbyBwcm9iYWJseSBzYWZlbHkg YXNzdW1lIHRoYXQgZXZlbiBhbW9uZ3N0IHRoYXQgdGlueSA5JSBwaWUgc2xpY2UsIHZlbmRvcnMg YXJlIGZvY3VzZWQgb24gdGhlIGZ1dHVyZSBzaW5jZSB0aGVpciBvdmVyYWxsIG1hcmtldCBzaGFy ZSBpcyBkZWNsaW5pbmcgKGFib3V0IDUlIGFubnVhbGx5KSwgd2hpY2ggYmVncyB0aGUgcXVlc3Rp b246wqAgSXMgRnJlZUJTRC9TUEFSQzY0IGFpbWluZyBhdCB0aGUgVDUsIGV2ZW4gd2hpbGUgT3Jh Y2xlIHRoZW1zZWx2ZXMgYXJlIHNoaWZ0aW5nIGVtcGhhc2lzIHRvIGxvd2VyLWNvc3QgeDY0IHN5 c3RlbXMgZm9yIHdoaWNoIEZyZWVCU0QgaXMgYWxyZWFkeSBjb21wZXRpdGl2ZSwgb3IgaXMgaXQg cmVhbGx5IGp1c3QgdHJ5aW5nIHRvIGtlZXAgc29tZSBvbGRlciBjb2xsZWN0aW9uIG9mIGluY3Jl YXNpbmdseSBwb3dlci9wZXJmb3JtYW5jZSBpbmVmZmljaWVudCAoYnkgY29tcGFyaXNvbikgYWxp dmU/Cj4KPiBBZ2Fpbiwgd2hhdOKAmXMgdGhlIGxvbmctdGVybSBnb2FsIG9mIHN1cHBvcnRpbmcg dGhpcyBhcmNoaXRlY3R1cmU/wqAgVGhlIG9sZCBhZGFnZSBhYm91dCDigJxwaWNraW5nIHlvdXIg YmF0dGxlc+KAnSBhcHBsaWVzIGhlcmUsIG5vIG1hdHRlciBob3cgZW50aHVzaWFzdGljIHRoZSBz bWFsbCBjb21tdW5pdHkgb2YgcmVtYWluaW5nIFNQQVJDIHVzZXJzIG1pZ2h0IGJlLCB3aGljaCBp cyB3aHkgSSBhbSByaXNraW5nIGxpZ2h0bmluZyBib2x0cyBvZiB3cmF0aCBmcm9tIFNQQVJDIHpl YWxvdHMgaW4gZXZlbiBkYXJpbmcgdG8gYXNrIHRoZSBxdWVzdGlvbi4gOi0pCj4KPiBUaGFua3Ms Cj4KPiAtIEpvcmRhbgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiBmcmVlYnNkLXNwYXJjNjRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gaHR0 cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc3BhcmM2NAo+ IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXNwYXJjNjQtdW5zdWJz Y3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-arch@freebsd.org Wed Nov 11 14:22:50 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 EB421A2B0F1; Wed, 11 Nov 2015 14:22:50 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id C98B61044; Wed, 11 Nov 2015 14:22:49 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NXN00I7XMWRLM00@hades.sorbs.net>; Wed, 11 Nov 2015 06:29:19 -0800 (PST) Message-id: <56434F34.6040707@sorbs.net> Date: Wed, 11 Nov 2015 15:22:44 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Alex McWhirter Cc: Jordan Hubbard , Anna Wilcox , freebsd-arch , sparc64@freebsd.org, Sean Bruno , Marius Strobl , Warner Losh Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 References: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> In-reply-to: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> 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 14:22:51 -0000 Alex McWhirter wrote: > The difference between most of the discontinued architectures and SPARC is that Oracle is showing more and more interest in developing their SPARC platform. Problem is they are killing it off with the business model. > If you consider the arm port, when it comes to alternative operating systems it probably has even a smaller market share than sparc. Isn't the Raspberry PI ARM? (mind you FreeBSD would have to try and catch up to Linux for that one - though it (the platform) is popular.) > I've sat in on my own fair share of Oracle meetings over the past few months, and they are doing everything in their power to push their customers on sparc and Solaris. > > They should consider what worked for Sun and what has killed their market share off. My experience has been in the past that Sun hardware had a massive following on the secondhand market... Oracle pretty much killed it... and along with it went the admins. I used to admin as part of teams datacenters full of Sun boxes, now I don't know where I can even find a datacenter with a Sun/Oracle box in it - except mine... and all mine are being depreciated. FreeBSD has an opportunity to fill the void in the secondhand Oracle (Sun) Hardware market if people want to take it.... but I seriously don't see why anyone would buy new Oracle boxes and shove FreeBSD on them - unless their admins already manage FreeBSD on older + Intel hardware. -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arch@freebsd.org Wed Nov 11 15:29:05 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 906FBA2C17D; Wed, 11 Nov 2015 15:29:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x244.google.com (mail-ig0-x244.google.com [IPv6:2607:f8b0:4001:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B90E1643; Wed, 11 Nov 2015 15:29:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcqf20 with SMTP id qf20so3545586igc.0; Wed, 11 Nov 2015 07:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y2DS7Hf+Bf1NXd9iBy2CRpUyaidco158z4IuzkcuKl0=; b=breTa14v3ucwp82fQq+8n4P/rlY5Gb6S7TBSkQfifTsut/RCv13flXXBVqB1tv4/st taJtPUcq2E7gxiVH5UGvBaqeSyWi15q4ecpo352NVvdotPSGBzSQTDcKmre81ylhK2v9 +vwi1IVKHrx7kLhZvFApj+5JFgYFVJaawl5gvwrfArAV+SvsKJ8Eee3HDcveBW0hScb5 6LRWqsT1Jq1WXrTEwFs60pADg06zT8J4ti9mOQjcabADxI3QVaMOUFGdHTD8e+34wUNe VopfqCsAH6b5PWAamEq+u8CumlHugH/3T5NePG+G9FVkkXtqXZkrE7OkB8xTF9S1myxB JvnQ== MIME-Version: 1.0 X-Received: by 10.50.73.228 with SMTP id o4mr32978267igv.37.1447255744649; Wed, 11 Nov 2015 07:29:04 -0800 (PST) Received: by 10.36.217.196 with HTTP; Wed, 11 Nov 2015 07:29:04 -0800 (PST) In-Reply-To: <56434F34.6040707@sorbs.net> References: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> <56434F34.6040707@sorbs.net> Date: Wed, 11 Nov 2015 07:29:04 -0800 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Adrian Chadd To: Michelle Sullivan Cc: Alex McWhirter , Anna Wilcox , freebsd-arch , sparc64@freebsd.org, Sean Bruno , Warner Losh , Marius Strobl , Jordan Hubbard Content-Type: text/plain; charset=UTF-8 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 15:29:05 -0000 On 11 November 2015 at 06:22, Michelle Sullivan wrote: > Alex McWhirter wrote: >> The difference between most of the discontinued architectures and SPARC is that Oracle is showing more and more interest in developing their SPARC platform. > > Problem is they are killing it off with the business model. > >> If you consider the arm port, when it comes to alternative operating systems it probably has even a smaller market share than sparc. > > Isn't the Raspberry PI ARM? (mind you FreeBSD would have to try and > catch up to Linux for that one - though it (the platform) is popular.) > > >> I've sat in on my own fair share of Oracle meetings over the past few months, and they are doing everything in their power to push their customers on sparc and Solaris. >> >> > They should consider what worked for Sun and what has killed their > market share off. > > My experience has been in the past that Sun hardware had a massive > following on the secondhand market... Oracle pretty much killed it... > and along with it went the admins. I used to admin as part of teams > datacenters full of Sun boxes, now I don't know where I can even find a > datacenter with a Sun/Oracle box in it - except mine... and all mine are > being depreciated. > > > FreeBSD has an opportunity to fill the void in the secondhand Oracle > (Sun) Hardware market if people want to take it.... but I seriously > don't see why anyone would buy new Oracle boxes and shove FreeBSD on > them - unless their admins already manage FreeBSD on older + Intel hardware. > As always, someone has to write and debug the code. Users are only as good as the revenue to generate to cover development/debugging/deployment costs. So if you're a sparc64 user, how much would you be willing to pay for freebsd/sparc64 support and development? I'm all for keeping an architecture like sparc around, as long as there's active development and active users. MIPS has both. ARM has both. Powerpc has both. Sparc is missing some active developers, but it has plenty of FreeBSD users that speak up (and more users that only speak up privately.) So, if you want to see sparc64 support continue, this requires a grass roots effort to get more development happening - either users need to step up, or someone has to start contributing money. -adrian From owner-freebsd-arch@freebsd.org Wed Nov 11 16:07:43 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 8A9E6A2CBD7; Wed, 11 Nov 2015 16:07:43 +0000 (UTC) (envelope-from bmcgover@cisco.com) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher IDEA-CBC-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 333851C48; Wed, 11 Nov 2015 16:07:42 +0000 (UTC) (envelope-from bmcgover@cisco.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5509; q=dns/txt; s=iport; t=1447258063; x=1448467663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2yMrpUDoa3XlR2OyDVRlfBUYMb5Pn1xjTY5ijJc//tY=; b=NqRB2jJw+i135/6zfYH/jycRflG7CKIPXSPb2/PidFbrjec3X/4bff3X J4OWj2/5Biq5Swq3/AOs1wGrb/YaAbtrfyvzBuDf8sJQZroax+jlRl+/6 XRLpjQC3dgEMNANC2ixeEo5Z7oMaZaxwi4py+hQsURi7+VSvJqi4mgud5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLBQCDZkNW/5NdJa1egztTbwbADxcKhSVKAoFFOxEBAQEBAQEBgQqENAEBAQMBAQEBSyALBQsCAQgOAwEDAQEBLicBCQEXBggCBAEHBgEEAQcMBQQEiAUIDcRUAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVIN4gQaEOwEBAQQJDoRgBZZIAYUchR+CY4FilniDcQE3LIIRHYFWcgeEBwcXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,276,1444694400"; d="scan'208";a="207281183" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 11 Nov 2015 16:07:36 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tABG7ZUn016338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 16:07:36 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 Nov 2015 11:07:35 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Wed, 11 Nov 2015 11:07:35 -0500 From: "Brian McGovern (bmcgover)" To: Jordan Hubbard , Warner Losh CC: Marius Strobl , Anna Wilcox , "sparc64@freebsd.org" , "Sean Bruno" , freebsd-arch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Thread-Topic: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Thread-Index: AQHRGj3TBhRT1Czn10uKLkw9qAAqPJ6SsdyAgAJMRgCAAawjAIAAEQIAgABGZRk= Date: Wed, 11 Nov 2015 16:07:35 +0000 Message-ID: References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> , <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> In-Reply-To: <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.121] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 16:07:43 -0000 I have to step in on Jordan's side on this one. As a recently-former lab ad= min (June), we were - and I assume continue to - chucking Sun Sparc hardwar= e 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 em= ergency case which is predestined to emergency at some point, but we're not= even considering giving the boxes another life as second tier hardware - t= he x86/64 space offers far superior metrics in terms of price/performance/s= upport/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 pr= oject 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 b= roader x86 (and even ARM) community; then again, I expect just about everyo= ne has such a list. -B ________________________________________ From: owner-freebsd-sparc64@freebsd.org = on behalf of Jordan Hubbard Sent: Wednesday, November 11, 2015 1:55:38 AM To: Warner Losh Cc: Marius Strobl; Anna Wilcox; sparc64@freebsd.org; Sean Bruno; freebsd-ar= ch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about S= parc64 > On Nov 10, 2015, at 9:54 PM, Warner Losh wrote: > > sparc64 is the odd-man out currently. However, even if clang doesn't > work, the gcc external toolchain works well for other platforms. If it ma= kes > sprac64 more viable, then so much the better. Hi Warner, I hate to be a voice of pragmatism here when we=92re having so much fun dis= cussing it from an architectural perspective, but=85 What=92s the actual goal (from a future market relevance perspective) of pu= tting resources, any resources, into sparc64? I think that=92s the key que= stion that needs to get asked and answered here since we all know that: 1) FreeBSD is not NetBSD - it has never historically supported =93x86 alter= native architectures=94 just because they existed and might be technically = interesting to port to, there had to be some sort of user community numbers= to justify the time and energy expended for the project as a whole (and ev= en in an all-volunteer driven project, there is simply no such thing as =93= free=94 - everything has a cost somewhere). As phk noted earlier in the thread, the ALPHA port was an exception to this= rule simply because it was the first-ever 64 bit port for FreeBSD and we k= new it would buy us some much-needed 64 bit cleanliness, but it also fell o= ff the support roadmap and into the history books once ALPHA=92s market rel= evance had clearly ended. NetBSD/alpha still exists, all the way up to and including NetBSD 7.0, beca= use their slogan is =93Of course it runs NetBSD.=94 Again, FreeBSD !=3D N= etBSD. The emphasis on market share is and always has been a key different= iator for FreeBSD and part of both its own slogans and mission statement. 2) Sparc64 global market share has declined significantly since Oracle purc= hased Sun, leaving Oracle and Fujitsu as the only two significant players i= n that market. Sure, putting =93old equipment to work=94 is also always a = tempting objective, but it=92s one that really requires viewing through an = objective lens since the perspective of someone who owns said "old equipmen= t" is rather more biased than the perspective of the market as a whole. Th= e market as a whole appears to consist (in terms of global server market sh= are): HP (x64) 27.6% IBM (x64) 22.9% DELL (x64) 16.4% All others (x64): 24% (combined estimate, including Cisco and Huawei) Total: 90.9% [ Source: Gartner ] That leaves 9.1% for the rest of the server industry, which includes Itaniu= m, POWER4 and SPARC64. We can also probably safely assume that even among= st that tiny 9% pie slice, vendors are focused on the future since their ov= erall market share is declining (about 5% annually), which begs the questio= n: Is FreeBSD/SPARC64 aiming at the T5, even while Oracle themselves are s= hifting emphasis to lower-cost x64 systems for which FreeBSD is already com= petitive, or is it really just trying to keep some older collection of incr= easingly power/performance inefficient (by comparison) alive? Again, what=92s the long-term goal of supporting this architecture? The ol= d adage about =93picking your battles=94 applies here, no matter how enthus= iastic the small community of remaining SPARC users might be, which is why = I am risking lightning bolts of wrath from SPARC zealots in even daring to = ask the question. :-) Thanks, - Jordan _______________________________________________ freebsd-sparc64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Wed Nov 11 16:32:45 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 2C393A2C302; Wed, 11 Nov 2015 16:32:45 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C72B11396; Wed, 11 Nov 2015 16:32:44 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wmvv187 with SMTP id v187so64066232wmv.1; Wed, 11 Nov 2015 08:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W63TpRQgiN2SM7t49g1Qoh/S15MOE1DTG9r1yLeXz6g=; b=xz+wTtU9qWZVnRlyzKveGrxpe0dBAUIvGjJx7vyQTHLgDJ78nmygLTokXrUGcGvrqX YIXAoiCG1crVkcxoXiGHh24+EWhF3Of6S8ZgEG/Pi7SoRfw27dO14sAEdQ7zof4gqcPt +cQ23BbpIcyuVFxbJMhn2XnCgF8HHzzAAIf+iY96c0N3oqpqEhswbSgedKn+UEgbgdNO UMRH2ybBpah8HLColZ405AbgBtVcdJExy80s0vJxC6ivmQ9TP9U5KFSIWJXSTMFLup4T x2zwPhE5RnhxrPPtNab+CmLP+REfEtN4hTa89Gvki/uBnfO5yZN3WYUKWz26BO019OWa z5Zw== X-Received: by 10.194.209.195 with SMTP id mo3mr10715346wjc.16.1447259563141; Wed, 11 Nov 2015 08:32:43 -0800 (PST) Received: from [192.168.1.193] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.gmail.com with ESMTPSA id v191sm26052997wmd.24.2015.11.11.08.32.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Nov 2015 08:32:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Jukka Ukkonen X-Mailer: iPad Mail (13B143) In-Reply-To: Date: Wed, 11 Nov 2015 18:32:37 +0200 Cc: Michelle Sullivan , Anna Wilcox , freebsd-arch , Marius Strobl , Sean Bruno , Jordan Hubbard , sparc64@freebsd.org, Warner Losh Content-Transfer-Encoding: 7bit Message-Id: References: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> <56434F34.6040707@sorbs.net> To: Adrian Chadd 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 16:32:45 -0000 > I'm all for keeping an architecture like sparc around, as long as > there's active development and active users. MIPS has both. ARM has > both. Powerpc has both. Sparc is missing some active developers, but > it has plenty of FreeBSD users that speak up (and more users that only > speak up privately.) So, if you want to see sparc64 support continue, > this requires a grass roots effort to get more development happening - > either users need to step up, or someone has to start contributing > money. Right, I am one of those who until now have only said something privately. So, I think it is time for me to say this on a bit more public forum. I could test something for sparc64 when I have a suitable moment. I have an idle V240 which I intended to be a compatibility test system anyhow. I cannot promise to do much of active development, though. Obviously some compatibility patches now and then is not going to be a problem. This being a hobby only for me and my real daily life being elsewhere, most of the heavy lifting would have to be done by others. I like the idea, though, that the sparc64 MMU keeps one on tip-toe with the memory alignment. In fact I see that as the biggest benefit in saving freebsd/sparc64. Additionally there is the admittedly very small possibility that Oracle might change its mind about how to position the hardware on the market, if several open OS environments keep the architecture supported to some level. So, if you accept little occasional help with testing and patching, I'm in. --jau From owner-freebsd-arch@freebsd.org Wed Nov 11 16:59:12 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 B4FE5A2C131 for ; Wed, 11 Nov 2015 16:59:12 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 8F00013B3 for ; Wed, 11 Nov 2015 16:59:12 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8C74CA2C130; Wed, 11 Nov 2015 16:59:12 +0000 (UTC) Delivered-To: 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 73ACAA2C12F for ; Wed, 11 Nov 2015 16:59:12 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E5AF13B2 for ; Wed, 11 Nov 2015 16:59:11 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by lfs39 with SMTP id 39so19567671lfs.3 for ; Wed, 11 Nov 2015 08:59:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=SBf4UVyvt1WZvnKAma7rk0rWP2YS5XlaJeIbm4T0e80=; b=mzie8vAKN2NqWn8yMbRhZfpJu4mPVsdVS5EUOv4i3k1bBuK2zRwmMiuraM+qcBK6RX LOtAKNW9s9ZxznGhUUgt0Za/zNb6ejaglTf2xd6efxOSUOh4RYGAzytbx0pBspHTqHuG 6dn4PkZkRJd0egU2X9ImORsI0fyQ0d5D1QI3OBWEFcTE6hGQBaBp6VjeXzf9RSPYb0V9 X24y4DebdW6BYOk2B6np+hMAmMSYlE4ROGhtgCP/LBeB6bDFKVqIOYC71ZYb55Sqmp0W yKh8U6kuKzD0J91SnLBMTT2PzaR2nSsVNLokZINMAv6GXk7qtU8ifYtfJBzx86J1Qxbb O8hw== X-Gm-Message-State: ALoCoQlYzrWkMEMlyRcY0wWRK29ouUhZusUx/a+0cDSneX6mLNLr6Q0qNyowadgd67j7j0T2nWQC X-Received: by 10.25.164.66 with SMTP id n63mr4862771lfe.24.1447261143838; Wed, 11 Nov 2015 08:59:03 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id l5sm1573105lbc.36.2015.11.11.08.59.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Nov 2015 08:59:02 -0800 (PST) Subject: Re: Question about ASCII and nl_langinfo (locale work) To: Baptiste Daroussin , arch@FreeBSD.org References: <20151110222636.GN10134@ivaldir.etoilebsd.net> Cc: marino@FreeBSD.org From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <564373D4.9060403@freebsd.org> Date: Wed, 11 Nov 2015 19:59:00 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110222636.GN10134@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WOi1xwjF4OwIh33LElCU88o1WHUGgOhCM" 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 16:59:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WOi1xwjF4OwIh33LElCU88o1WHUGgOhCM Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 11.11.2015 1:26, Baptiste Daroussin wrote: > The thing is not all are aware that FreeBSD uses US-ASCII, for example = tcl does > not. which means tcl is not able to determine what encoding is needed f= or the C > and POSIX locales. >=20 > On Linux they to return ANSI_X3.4-1968 (also known as US-ASCII) and mos= t > application knows what linux returns. >=20 > That means we need to teach all upstream about US-ASCII all the time. >=20 > The proposals are: > - Do not change what we have always done. > - Change it to something that makes sense "C" (what we tried with "POSI= X" which > was a very bad idea, but "C" seems to be commonly recognised by appli= cation as > ASCII) > - Let's report the same as Linux, that will simplify portability > - Let's be obvious and report ASCII (also commonly recognised by applic= ations) Just repeating my opinion in this new thread. Since POSIX don't tell anything certain, we should be Linux compatible here to have less surprise, i.e.: 1) Return "ANSI_X3.4-1968" for C/POSIX locale (was "US-ASCII"). 2) Return "ASCII" for *.US-ASCII locales (was "US-ASCII"). Typical Linux program knows nothing about our "US-ASCII", and porting handles it rarely. Not doing that leads to hidden, hard to find bugs like still present right now in our tcl ports. For all that years tcl don't understand FreeBSD-native nl_langinfo() "US-ASCII" and falls back to "iso8859-1" (it understands Linux "ANSI_X3.4-1968" and "ASCII" of course). --=20 http://ache.vniz.net/ --WOi1xwjF4OwIh33LElCU88o1WHUGgOhCM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWQ3PUAAoJEKUckv0MjfbKFXMH/1pN9IiceIv5m/MIPoUDY/97 ICsZTP8kcfLBNA8CvsbhSmkk6cFbyoxd704sjiVgzx/clrEQJcH5H3bibObuR+Y0 CBd9F2meXIf2jqD0GT3fr9XfN/Lxss+6g3nNK850p0GnrxqPjKdNFIiqNP3CAecS vytnl7tm/NMMaWTHT4tePgB9I8WXgOqxqrSiPTnwqO4T99Fus6rqNUqaOphxDusW MO3w4ZB0q3Zft55tgEEF11XpvJZuBAkEs7JWUSU9hBOXmySSBlcCFZDl2uON1725 /LcD5qYqpiZUMt6b4g2AxkLgZtGMckrSuP89ZGiXX5e9kBkJcEUdCreaGspEVJY= =0kNf -----END PGP SIGNATURE----- --WOi1xwjF4OwIh33LElCU88o1WHUGgOhCM-- From owner-freebsd-arch@freebsd.org Wed Nov 11 17:34:52 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 40597A2CF41; Wed, 11 Nov 2015 17:34:52 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2BABE144A; Wed, 11 Nov 2015 17:34:51 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NXN00I9KVSSLM00@hades.sorbs.net>; Wed, 11 Nov 2015 09:41:21 -0800 (PST) Message-id: <56437C34.5050603@sorbs.net> Date: Wed, 11 Nov 2015 18:34:44 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Adrian Chadd Cc: Alex McWhirter , Anna Wilcox , freebsd-arch , sparc64@freebsd.org, Sean Bruno , Warner Losh , Marius Strobl , Jordan Hubbard Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 References: <64302b19-9f33-4267-af44-7fc30ea4bf3d@email.android.com> <56434F34.6040707@sorbs.net> In-reply-to: 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 17:34:52 -0000 Adrian Chadd wrote: > On 11 November 2015 at 06:22, Michelle Sullivan wrote: > >> Alex McWhirter wrote: >> >>> The difference between most of the discontinued architectures and SPARC is that Oracle is showing more and more interest in developing their SPARC platform. >>> >> Problem is they are killing it off with the business model. >> >> >>> If you consider the arm port, when it comes to alternative operating systems it probably has even a smaller market share than sparc. >>> >> Isn't the Raspberry PI ARM? (mind you FreeBSD would have to try and >> catch up to Linux for that one - though it (the platform) is popular.) >> >> >> >>> I've sat in on my own fair share of Oracle meetings over the past few months, and they are doing everything in their power to push their customers on sparc and Solaris. >>> >>> >>> >> They should consider what worked for Sun and what has killed their >> market share off. >> >> My experience has been in the past that Sun hardware had a massive >> following on the secondhand market... Oracle pretty much killed it... >> and along with it went the admins. I used to admin as part of teams >> datacenters full of Sun boxes, now I don't know where I can even find a >> datacenter with a Sun/Oracle box in it - except mine... and all mine are >> being depreciated. >> >> >> FreeBSD has an opportunity to fill the void in the secondhand Oracle >> (Sun) Hardware market if people want to take it.... but I seriously >> don't see why anyone would buy new Oracle boxes and shove FreeBSD on >> them - unless their admins already manage FreeBSD on older + Intel hardware. >> >> > > As always, someone has to write and debug the code. > Generally I can debug (and I can write some) code, and am happy to do so, however, my experience of code for hardware... a big fat zero (unless you count writing printer drivers in z80 and 6502 for personal (home) computers back in the 80's :) )... my experience of Sparc32/64 that sits under the C compiler... another big fat zero... However I'm happy to help if I can. > Users are only as good as the revenue to generate to cover > development/debugging/deployment costs. > > So if you're a sparc64 user, how much would you be willing to pay for > freebsd/sparc64 support and development? > My FreeBSD Sparc64 in current use is: A RADIUS server running on a T1 A not finished build server where I was going to integrate it into my local Jenkins and build packages... however when I found very little support and the whole "you will run pkgng whether you want to or not" shit went off I stopped working on it and build my own ports tree that currently builds both old style and new style packages - and was uptodate as of August (had a couple of hardware failures locally that has prevented me on keeping up from August.) > I'm all for keeping an architecture like sparc around, as long as > there's active development and active users. MIPS has both. ARM has > both. Powerpc has both. Sparc is missing some active developers, but > it has plenty of FreeBSD users that speak up (and more users that only > speak up privately.) So, if you want to see sparc64 support continue, > this requires a grass roots effort to get more development happening - > either users need to step up, or someone has to start contributing > money. > > There is currently Zero chance of getting any money for development from $employer - pkgng ensured that - in fact with the exception of my machines nothing is running FreeBSD @ $employer now... such is life. Regards, -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arch@freebsd.org Wed Nov 11 17:37:12 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 0F162A2CFF1 for ; Wed, 11 Nov 2015 17:37:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 E5E2415E3 for ; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E20B6A2CFEF; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) Delivered-To: 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 C79BFA2CFED; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A969315E1; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 9E9C81D10; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 6D0391250E; Wed, 11 Nov 2015 17:37:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 2yTal8NQwY8S; Wed, 11 Nov 2015 17:37:09 +0000 (UTC) To: "current@freebsd.org" , arch@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com EB78712507 From: Bryan Drewery Subject: bsd.subdir.mk: Recursing on dependent targets Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <56437CC4.9050103@FreeBSD.org> Date: Wed, 11 Nov 2015 09:37:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3pDErRMH1A8x7NxdsecQfmlnxeOBSodaB" 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 17:37:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3pDErRMH1A8x7NxdsecQfmlnxeOBSodaB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The current behavior of bsd.subdir.mk has a very surprising behavior that I think is wrong and think that changing it will have no real impact= =2E Consider: SUBDIR_TARGETS=3D all foo all: foo If you call 'make foo' it will recurse 'foo' on all sub-directories as expected. If you call 'make all' it will recurse 'foo' in all sub-directories and then recurse 'all' in all sub-directories which then again calls 'foo' in sub-directories! So technically 'foo' is called 3 times in some directories do to 'all' implicitly calling it as well. Here's a contrived example with 'all' and 'buildconfig' which is prone to this problem now. ~/svn/base/usr.bin/bsdiff # make all|grep buildconfig|grep bsdiff/subdir =3D=3D=3D> bsdiff/subdir (buildconfig) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir =3D=3D=3D> bsdiff/subdir (buildconfig) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir Full: ~/svn/base/usr.bin/bsdiff # make all =3D=3D=3D> bsdiff (buildconfig) =3D=3D=3D> bsdiff/subdir (buildconfig) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff =3D=3D=3D> bspatch (buildconfig) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bspatch buildconfig=3D/root/svn/base/usr.bin/bsdiff =3D=3D=3D> bsdiff (all) =3D=3D=3D> bsdiff/subdir (buildconfig) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff =3D=3D=3D> bsdiff/subdir (all) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir =3D=3D=3D> bspatch (all) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bspatch With the change I would like to make, to only recurse on *called* targets, the result is: ~/svn/base/usr.bin/bsdiff # make all|grep buildconfig|grep bsdiff/subdir buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir ~/svn/base/usr.bin/bsdiff # make all buildconfig=3D/root/svn/base/usr.bin/bsdiff =3D=3D=3D> bsdiff (all) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff =3D=3D=3D> bsdiff/subdir (all) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bsdiff/subdir =3D=3D=3D> bspatch (all) buildconfig=3D/root/svn/base/usr.bin/bsdiff/bspatch The potential problem I see with this is if someone has some top-level target like 'buildit' that is not in SUBDIR_TARGETS but it depends on targets which are in SUBDIR_TARGETS, such as 'all'. This would now no longer recurse on those. I think this would be worth an UPDATING entry that 'buildit' needs to be added into SUBDIR_TARGETS or called explicitly with ${MAKE}, but I also want to be sure I'm not missing something here about this being 'expected behavior'. From my own experience I don't expect this to be an actual problem. --=20 Regards, Bryan Drewery --3pDErRMH1A8x7NxdsecQfmlnxeOBSodaB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWQ3zEAAoJEDXXcbtuRpfPMn8H/RZy2gu4yvZoERgF4ys6eiWu 2K8o4SXinpBvekTzsPkGZ7gq+wKJFHanOp0WKUIP0wFdtVDukC/wuDIpS69ksO3d kfh/QfAGP039GKq5qeKtKI894EB6TZL2TZydZbB6D6Mwt8KS1KtzlFeBCu9b2eKL 9mRw2cqRwGksBGwFx6MowGW5hgXwfz2RAwz/TNO9dRR4hvR7SFWTs/JRLNAYfO/C HoabhSScGS+wS1VP3BpuMzPaPKvZU9eayT88xqR1wsQiM8T3Z2z+FbGCVLPplndl wYrF7drLJxWX+W4bLnYxuhCdXijKdYDT53c74UVYXHQpbEispkygAKGEwN8Dxfw= =Btk/ -----END PGP SIGNATURE----- --3pDErRMH1A8x7NxdsecQfmlnxeOBSodaB-- From owner-freebsd-arch@freebsd.org Wed Nov 11 17:51:01 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 4DE32A2C4E6 for ; Wed, 11 Nov 2015 17:51:01 +0000 (UTC) (envelope-from jhs@berklix.com) 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 325AF10A7 for ; Wed, 11 Nov 2015 17:51:01 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 307B0A2C4E4; Wed, 11 Nov 2015 17:51:01 +0000 (UTC) Delivered-To: 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 2FE91A2C4E3; Wed, 11 Nov 2015 17:51:01 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2F3A10A5; Wed, 11 Nov 2015 17:50:59 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B226613.dip0.t-ipconnect.de [91.34.102.19]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id tABHoxnj021937; Wed, 11 Nov 2015 18:50:59 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id tABHon9l057474; Wed, 11 Nov 2015 18:50:50 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id tABHobN5095068; Wed, 11 Nov 2015 18:50:49 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201511111750.tABHobN5095068@fire.js.berklix.net> To: Bryan Drewery cc: "current@freebsd.org" , arch@freebsd.org Subject: Re: bsd.subdir.mk: Recursing on dependent targets From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 11 Nov 2015 09:37:08 -0800." <56437CC4.9050103@FreeBSD.org> Date: Wed, 11 Nov 2015 18:50:37 +0100 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 17:51:01 -0000 Hi Bryan & all, I'm in a rush so will read yours again later, but will quickly mention I've long ago added a load of *-recursive macros to my Mk/ but never submitted them, they are under http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/ (but it seems something in apache httpd.conf is truncing file names, which should appear as eg bsd.port.subdir.mk.reinstall-recursive.REL=8.2-RELEASE.diff etc ) Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com Reply After previous text to preserve context, as in a play script. Indent previous text with > Insert new lines before 80 chars. Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc. From owner-freebsd-arch@freebsd.org Wed Nov 11 17:56:33 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 955F3A2C728 for ; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 76A341631 for ; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 72DDDA2C726; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) Delivered-To: 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 725A9A2C724; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 59867162F; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 537421452; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 0CF27125C7; Wed, 11 Nov 2015 17:56:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id XhK7WLiMJE3l; Wed, 11 Nov 2015 17:56:25 +0000 (UTC) Subject: Re: bsd.subdir.mk: Recursing on dependent targets DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 7AC5D125C0 To: "Julian H. Stacey" References: <201511111750.tABHobN5095068@fire.js.berklix.net> Cc: "current@freebsd.org" , arch@freebsd.org From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56438149.2020204@FreeBSD.org> Date: Wed, 11 Nov 2015 09:56:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201511111750.tABHobN5095068@fire.js.berklix.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1m4Jj4SC13lSadP19lWObnOlVE6QVhAjX" 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 17:56:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1m4Jj4SC13lSadP19lWObnOlVE6QVhAjX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/11/2015 9:50 AM, Julian H. Stacey wrote: > Hi Bryan & all, > I'm in a rush so will read yours again later, but will quickly mention > I've long ago added a load of *-recursive macros to my Mk/ > but never submitted them, they are under > http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/ >=20 > (but it seems something in apache httpd.conf is truncing file names, > which should appear as eg > bsd.port.subdir.mk.reinstall-recursive.REL=3D8.2-RELEASE.diff > etc ) >=20 This should not be impacted since it does not use bsd.subdir.mk. I'm not planning to modify bsd.port.subdir.mk at all. --=20 Regards, Bryan Drewery --1m4Jj4SC13lSadP19lWObnOlVE6QVhAjX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWQ4FJAAoJEDXXcbtuRpfPrxEH/i/TGHCEySAQW6OG2XOHKIG4 b7D4hHpEOBIhdye5jD/1nGYIBJX6lBQEV7beYl3Uob6IL6KDGWOy0+al0TlolooP Qf0sXHhxhWEIDnLfrBS2VzxECaFXJw8CGB/x3jIPQAK3KQc+jy2pr4wK7dEDBtOW Dnj+/xIX6DTc+gv8suT4rC6b0+2+qFg1g0X8OqeihMEarG09C8iIpQhnnKkQX2iZ vNOJca++uzvWRyojQUBvcTb6UzpBpBcbWmRAqUQPaZo5yymob0kOLmR8q2zXccn/ t7pHJMliRIssYtaBSsJ1DXD0FbLdLqpK/+0MgOPB+AxWvwL2smioTQB1RuhXEZU= =fXex -----END PGP SIGNATURE----- --1m4Jj4SC13lSadP19lWObnOlVE6QVhAjX-- From owner-freebsd-arch@freebsd.org Wed Nov 11 17:59:35 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 ADF4DA2C7ED for ; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 9008D19AD for ; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8DE03A2C7EB; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) Delivered-To: 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 8D637A2C7EA; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7567319AC; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 6FBED1607; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 312C3125DA; Wed, 11 Nov 2015 17:59:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id UOFoF4CMk1sy; Wed, 11 Nov 2015 17:59:33 +0000 (UTC) Subject: Re: bsd.subdir.mk: Recursing on dependent targets DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 87E74125D5 To: "current@freebsd.org" , arch@FreeBSD.org References: <56437CC4.9050103@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56438204.1000109@FreeBSD.org> Date: Wed, 11 Nov 2015 09:59:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56437CC4.9050103@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VQNTLBs9E6rrhuG6axOdvENnelj9Th1pr" 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 17:59:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VQNTLBs9E6rrhuG6axOdvENnelj9Th1pr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2015 9:37 AM, Bryan Drewery wrote: >=20 > With the change I would like to make, to only recurse on *called* > targets This also has the benefit of no longer having 'realinstall' be a thing that bsd.subdir.mk needs to care about. Just recursing 'install' would handle all of the ordering and targets in each subdir. --=20 Regards, Bryan Drewery --VQNTLBs9E6rrhuG6axOdvENnelj9Th1pr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWQ4IEAAoJEDXXcbtuRpfPUmMH/2+8RsyvwV0mSKdgrnKeUU/e fBv9bnipFxjUxJgf/+ol+gV47IQL3npqaDu0N3+wXJaGuM9YMvOfBB2i8S22VIuH sVwzKGzx/cieJ002niPoCjhqVne8sORGJzBfwvYPQLJdDW6ktjQc0+A+YEawg2Yk w8/vzuzCO9xv+ZUQpngrrdJ8vI8/W2ig3N+2O7DC4H3+CN1YaxTOKBhw32C0QFUu repddbd1l+ZL1X46Wxk72U/FafRqiW+9HiEckXyrcN/jkbIBncC7OAuRTacT9LIT VUVy3g4BBDMm5V55idtJhZxEQUfCzAlYl/wbL4NArNUWbfvanqH3M7+O0gmvdsg= =4Tlh -----END PGP SIGNATURE----- --VQNTLBs9E6rrhuG6axOdvENnelj9Th1pr-- 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 From owner-freebsd-arch@freebsd.org Wed Nov 11 19:35:39 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 05305A2B6E6; Wed, 11 Nov 2015 19:35:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B58A81C66; Wed, 11 Nov 2015 19:35:38 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id tABJZcLF008119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Nov 2015 11:35:38 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id tABJZb7D008118; Wed, 11 Nov 2015 11:35:37 -0800 (PST) (envelope-from jmg) Date: Wed, 11 Nov 2015 11:35:37 -0800 From: John-Mark Gurney To: Peter Jeremy Cc: Jordan Hubbard , freebsd-arch , sparc64@freebsd.org Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151111193536.GU65715@funkthat.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <20151111084432.GC67251@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151111084432.GC67251@server.rulingia.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 11 Nov 2015 11:35:38 -0800 (PST) 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 19:35:39 -0000 Peter Jeremy wrote this message on Wed, Nov 11, 2015 at 19:44 +1100: > On 2015-Nov-10 22:55:38 -0800, Jordan Hubbard wrote: > >Again, what???s the long-term goal of supporting this architecture? > > The things that sparc64 give us that x86 doesn't are big-endian and > strict alignment. In theory, MIPS, PPC and ARM can give us both of > those but I'm non sure whether we actually have any big-endian > variants of them. I'm running an ARMv4 BE machine (AVILA board), and a MIPS64 BE machine, the EdgeRouter Lite... FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r283010M: Sun May 17 10:16:08 PDT 2015 jmg@carbon.funkthat.com:/a/obj/arm.armeb/a/home/jmg/FreeBSD.svn/HEAD/sys/AVILA arm FreeBSD erl.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r289393M: Thu Oct 15 17:02:12 PDT 2015 jmg@carbon.funkthat.com:/a/obj/mips.mips64/a/home/jmg/FreeBSD.svn/HEAD/sys/ERL mips -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Wed Nov 11 21:53:41 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 9C7F9A2C7E1; Wed, 11 Nov 2015 21:53:41 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84E36135A; Wed, 11 Nov 2015 21:53:41 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tABLrXRP009005 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Nov 2015 13:53:34 -0800 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Peter Jeremy , Jordan Hubbard References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <20151111084432.GC67251@server.rulingia.com> Cc: freebsd-arch , sparc64@freebsd.org From: Nathan Whitehorn Message-ID: <5643B8DD.9060006@freebsd.org> Date: Wed, 11 Nov 2015 13:53:33 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151111084432.GC67251@server.rulingia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVZL+OFW00lKcfPzr49z89OjkjD/onNYVQIW/ySzc/mNVnl6xl2zT0xgOIY+kR8jcExqfClbMF6ftVu9axwXb4o55P/qZoqdCDI= X-Sonic-ID: C;XKxnp76I5RGUNL0U9jFv0A== M;SOO8p76I5RGUNL0U9jFv0A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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 21:53:41 -0000 We currently only support big-endian on PowerPC (32 and 64-bit). We might support little-endian PowerPC at some point -- Linux is moving in that direction -- but I'm not sure we have the userbase to warrant it. -Nathan On 11/11/15 00:44, Peter Jeremy wrote: > On 2015-Nov-10 22:55:38 -0800, Jordan Hubbard wrote: >> Again, what’s the long-term goal of supporting this architecture? > The things that sparc64 give us that x86 doesn't are big-endian and > strict alignment. In theory, MIPS, PPC and ARM can give us both of > those but I'm non sure whether we actually have any big-endian > variants of them. > From owner-freebsd-arch@freebsd.org Thu Nov 12 17:40:50 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 D2132A2D195 for ; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 B63081907 for ; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id B309DA2D193; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) Delivered-To: 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 988D6A2D192; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEC01905; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 76E6E11F3; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 35832146A1; Thu, 12 Nov 2015 17:40:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id rBLPL9ilTI0G; Thu, 12 Nov 2015 17:40:44 +0000 (UTC) To: current@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 0A98B1469B From: Bryan Drewery Subject: [CFT] build: WITH_FAST_DEPEND and WITH_CCACHE_BUILD Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <5644CF1C.9020709@FreeBSD.org> Date: Thu, 12 Nov 2015 09:40:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M8vn7GDFg4xth8WrijkLOHfFUXraq9SSg" X-Mailman-Approved-At: Thu, 12 Nov 2015 19:50:48 +0000 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: Thu, 12 Nov 2015 17:40:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M8vn7GDFg4xth8WrijkLOHfFUXraq9SSg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Recently I have introduced two new features into the build. These apply to anything using /usr/share/mk including buildworld, buildkernel, universe, etc. - The first is WITH_FAST_DEPEND. Please see the commit for its full description, benefits and discussion. It saves 16-30% in build times without gimmicks or risk. It avoids running the preprocessor twice in the build and only runs it during compilation. This is a feature that's 14 years overdue. https://svnweb.freebsd.org/changeset/base/290433 There was a problem with the GCC build, but that has been fixed. I intend to enable this *by default* for the src buildworld/etc... build in a few weeks. I do need to schedule a ports exp-run with this as well to see if anything outside of the src tree is broken by it, which I very much doubt. If you have a downstream fork of FreeBSD, please import r290433 and r290629 and give me feedback on any issues you encounter. There is 1 gotcha that I realized. People running 'make depend' manually may actually want to see a .depend file generated without having to compile first. I may add support for that somehow but am not sure yet. It may be a 'make mkdep' target. - The second is WITH_CCACHE_BUILD. This replaces the previous suggestion of modifying CC and CXX in /etc/make.conf. This is purposely chosen to match the ports name. It can save up to 65% build times when combined with WITH_FAST_DEPEND. This fixes all known issues with buildworld+ccache. There is a rare problem that can occur with header detection that is documented in the ccache manpage in the DIRECT MODE section. **It is only useful for frequent builders who do not use -DNO_CLEAN and want a reliable incremental build. It is not useful for people who build infrequently.** See commit for further details and stats. I do not intend to ever support enabling this by default. I just intend to update the devel/ccache pkg-message to suggest using it once it is known to work for all. https://svnweb.freebsd.org/changeset/base/290526 Thanks! Bryan Drewery --M8vn7GDFg4xth8WrijkLOHfFUXraq9SSg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWRM8cAAoJEDXXcbtuRpfPPKsIANgaJynN8UWGTgI6R7OWgT0s UHIy15+vsE9HVrQ8yvITp5lVOtI0xp69RmHhI6B+xje2VfYv/2brmUcW3kL4LK3K s17oYX7Nz9xNSLdASNeboet77cygpG5lycElU/XpD0GJ4tVUsWBlf5M/xydh/UG7 gBnHV4cCFXJ/fbpnHdY58cTJl8p08ngG+KUVBM3+HkihZ4Zy+e9QizRqvpf9VcgS HWP6wQniQ+qdNYzlOMyoLrDzoZM8yNPlkOg/m/ToeacNji4K4I9Igp768e60FJKB 153jNhrA8gMvO2wVCIH+llO79yzVqlrXpF8viw7o4vSMoxfqc2dhxWrcyP+2aPc= =/hq/ -----END PGP SIGNATURE----- --M8vn7GDFg4xth8WrijkLOHfFUXraq9SSg-- From owner-freebsd-arch@freebsd.org Thu Nov 12 22:36:56 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 5B8CAA2DF32 for ; Thu, 12 Nov 2015 22:36:56 +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 3766D1157 for ; Thu, 12 Nov 2015 22:36:56 +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 9F004B915 for ; Thu, 12 Nov 2015 17:36:54 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) Date: Thu, 12 Nov 2015 14:36:42 -0800 Message-ID: <111428878.dys4vNKReT@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <4121266.HXN5YIfUMj@ralph.baldwin.cx> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <5166205.rtMjEmhvmo@ralph.baldwin.cx> <4121266.HXN5YIfUMj@ralph.baldwin.cx> 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); Thu, 12 Nov 2015 17:36:54 -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: Thu, 12 Nov 2015 22:36:56 -0000 On Monday, August 31, 2015 02:21:19 PM John Baldwin wrote: > On Wednesday, August 12, 2015 10:50:20 AM John Baldwin wrote: > > On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote: > > > Many debuggers (recent gdb and lldb) support cross-architecture debugging > > > just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for > > > remote targets already, but I wanted it to also support cross-debugging for > > > vmcores. > > > > > > The existing libkvm/kgdb code in the tree has some limited support for > > > cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) > > > and custom kgdb for each target platform. However, gdb (and lldb) both > > > support multiple targets in a single binary, so I'd like to have a single > > > kgdb binary that can cross-debug anything. > > > > > > I started hacking on libkvm last weekend and have a prototype that I've used > > > (along with some patches to my kgdb port) to debug an amd64 vmcore on an > > > i386 machine and vice versa. > > > > > > ... > > > > > > What I'm mostly after is comments on the API, etc. Once that is settled I > > > will move forward on converting and/or stubbing the other backends (the > > > stub route would be to only support other backends on native systems for > > > now). > > > > I guess this is closer to a nuclear power plant than a bikeshed judging by the > > feedback. I have ported the rest of the MD backends and verified that the > > updated libkvm passes a universe build (including various static assertions > > for the duplicated constants in other backends). What I have not done is any > > runtime testing and I would like to ask for help with that now. In particular > > I need someone to test that kgdb and/or ps works against a native core dump > > on all platforms other than amd64 and i386. Note that some of the trickiness > > is that the backends now have to make runtime decisions for things that were > > previously compile-time decisions. The biggest one affected by this is the > > MIPS backend as that backend handles three ABIs (mipso32, mipsn32, and mipsn64). > > I believe I have the handling for that correct (mips[on]32 use 32-bit KSEGs > > where as mipsn64 uses the extended segments and compat32 KSEGS, and mipso32 > > uses 32-bit PTEs and mipsn32/n64 both use 64-bit PTEs) (plus both endians > > for both in theory). The ARM backend also handles both endians (in theory). > > > > Another wrinkle is that sparc64 uses its own dump format instead of writing > > out an ELF file. I had to convert the header structures to use fixed-width > > types to be cross-friendly. It would be good to ensure that a new libkvm > > can read a vmcore from an old kernel and vice versa to make sure my conversion > > is correct (I added an explicit padding field that I believe was implicit > > before). > > > > The code is currently available for review in phabric at > > https://reviews.freebsd.org/D3341 > > > > To test, you can run 'arc patch D3341' in a clean tree to apply the patch. > > I've just rebased this to port aarch64's minidump support. I just need people > willing and able to test on non-x86. Testing with the in-tree kgdb using an > updated libkvm would be sufficient. After a lot of crickets, I have updated the manpages for the new API. I will commit this "soon". If you want kgdb to keep working on your non-x86 platform, this is your chance to test this before it hits the tree. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Nov 12 23:41:56 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 94F6AA2EAC0 for ; Thu, 12 Nov 2015 23:41:56 +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 41DEE13AD; Thu, 12 Nov 2015 23:41:55 +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 tACNflD5076204 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Nov 2015 00:41:47 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id tACNfljo076203; Fri, 13 Nov 2015 00:41:47 +0100 (CET) (envelope-from marius) Date: Fri, 13 Nov 2015 00:41:46 +0100 From: Marius Strobl To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) Message-ID: <20151112234146.GA76156@alchemy.franken.de> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <5166205.rtMjEmhvmo@ralph.baldwin.cx> <4121266.HXN5YIfUMj@ralph.baldwin.cx> <111428878.dys4vNKReT@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111428878.dys4vNKReT@ralph.baldwin.cx> 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]); Fri, 13 Nov 2015 00:41:47 +0100 (CET) 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: Thu, 12 Nov 2015 23:41:56 -0000 On Thu, Nov 12, 2015 at 02:36:42PM -0800, John Baldwin wrote: > On Monday, August 31, 2015 02:21:19 PM John Baldwin wrote: > > On Wednesday, August 12, 2015 10:50:20 AM John Baldwin wrote: > > > On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote: > > > > Many debuggers (recent gdb and lldb) support cross-architecture debugging > > > > just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for > > > > remote targets already, but I wanted it to also support cross-debugging for > > > > vmcores. > > > > > > > > The existing libkvm/kgdb code in the tree has some limited support for > > > > cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) > > > > and custom kgdb for each target platform. However, gdb (and lldb) both > > > > support multiple targets in a single binary, so I'd like to have a single > > > > kgdb binary that can cross-debug anything. > > > > > > > > I started hacking on libkvm last weekend and have a prototype that I've used > > > > (along with some patches to my kgdb port) to debug an amd64 vmcore on an > > > > i386 machine and vice versa. > > > > > > > > ... > > > > > > > > What I'm mostly after is comments on the API, etc. Once that is settled I > > > > will move forward on converting and/or stubbing the other backends (the > > > > stub route would be to only support other backends on native systems for > > > > now). > > > > > > I guess this is closer to a nuclear power plant than a bikeshed judging by the > > > feedback. I have ported the rest of the MD backends and verified that the > > > updated libkvm passes a universe build (including various static assertions > > > for the duplicated constants in other backends). What I have not done is any > > > runtime testing and I would like to ask for help with that now. In particular > > > I need someone to test that kgdb and/or ps works against a native core dump > > > on all platforms other than amd64 and i386. Note that some of the trickiness > > > is that the backends now have to make runtime decisions for things that were > > > previously compile-time decisions. The biggest one affected by this is the > > > MIPS backend as that backend handles three ABIs (mipso32, mipsn32, and mipsn64). > > > I believe I have the handling for that correct (mips[on]32 use 32-bit KSEGs > > > where as mipsn64 uses the extended segments and compat32 KSEGS, and mipso32 > > > uses 32-bit PTEs and mipsn32/n64 both use 64-bit PTEs) (plus both endians > > > for both in theory). The ARM backend also handles both endians (in theory). > > > > > > Another wrinkle is that sparc64 uses its own dump format instead of writing > > > out an ELF file. I had to convert the header structures to use fixed-width > > > types to be cross-friendly. It would be good to ensure that a new libkvm > > > can read a vmcore from an old kernel and vice versa to make sure my conversion > > > is correct (I added an explicit padding field that I believe was implicit > > > before). > > > > > > The code is currently available for review in phabric at > > > https://reviews.freebsd.org/D3341 > > > > > > To test, you can run 'arc patch D3341' in a clean tree to apply the patch. > > > > I've just rebased this to port aarch64's minidump support. I just need people > > willing and able to test on non-x86. Testing with the in-tree kgdb using an > > updated libkvm would be sufficient. > > After a lot of crickets, I have updated the manpages for the new API. I will > commit this "soon". If you want kgdb to keep working on your non-x86 > platform, this is your chance to test this before it hits the tree. > What exact test procedure do you suggest for full coverage of an architecture? Marius From owner-freebsd-arch@freebsd.org Fri Nov 13 23:12:42 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 C5ADFA2E8AE for ; Fri, 13 Nov 2015 23:12:42 +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 8648B1EA9 for ; Fri, 13 Nov 2015 23:12:42 +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 A5060B989; Fri, 13 Nov 2015 18:12:40 -0500 (EST) From: John Baldwin To: Marius Strobl Cc: freebsd-arch@freebsd.org Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) Date: Fri, 13 Nov 2015 11:50:37 -0800 Message-ID: <5385051.zAN7Yc63R0@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20151112234146.GA76156@alchemy.franken.de> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <111428878.dys4vNKReT@ralph.baldwin.cx> <20151112234146.GA76156@alchemy.franken.de> 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); Fri, 13 Nov 2015 18:12:40 -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: Fri, 13 Nov 2015 23:12:42 -0000 On Friday, November 13, 2015 12:41:46 AM Marius Strobl wrote: > On Thu, Nov 12, 2015 at 02:36:42PM -0800, John Baldwin wrote: > > On Monday, August 31, 2015 02:21:19 PM John Baldwin wrote: > > > On Wednesday, August 12, 2015 10:50:20 AM John Baldwin wrote: > > > > On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote: > > > > > Many debuggers (recent gdb and lldb) support cross-architecture debugging > > > > > just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for > > > > > remote targets already, but I wanted it to also support cross-debugging for > > > > > vmcores. > > > > > > > > > > The existing libkvm/kgdb code in the tree has some limited support for > > > > > cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) > > > > > and custom kgdb for each target platform. However, gdb (and lldb) both > > > > > support multiple targets in a single binary, so I'd like to have a single > > > > > kgdb binary that can cross-debug anything. > > > > > > > > > > I started hacking on libkvm last weekend and have a prototype that I've used > > > > > (along with some patches to my kgdb port) to debug an amd64 vmcore on an > > > > > i386 machine and vice versa. > > > > > > > > > > ... > > > > > > > > > > What I'm mostly after is comments on the API, etc. Once that is settled I > > > > > will move forward on converting and/or stubbing the other backends (the > > > > > stub route would be to only support other backends on native systems for > > > > > now). > > > > > > > > I guess this is closer to a nuclear power plant than a bikeshed judging by the > > > > feedback. I have ported the rest of the MD backends and verified that the > > > > updated libkvm passes a universe build (including various static assertions > > > > for the duplicated constants in other backends). What I have not done is any > > > > runtime testing and I would like to ask for help with that now. In particular > > > > I need someone to test that kgdb and/or ps works against a native core dump > > > > on all platforms other than amd64 and i386. Note that some of the trickiness > > > > is that the backends now have to make runtime decisions for things that were > > > > previously compile-time decisions. The biggest one affected by this is the > > > > MIPS backend as that backend handles three ABIs (mipso32, mipsn32, and mipsn64). > > > > I believe I have the handling for that correct (mips[on]32 use 32-bit KSEGs > > > > where as mipsn64 uses the extended segments and compat32 KSEGS, and mipso32 > > > > uses 32-bit PTEs and mipsn32/n64 both use 64-bit PTEs) (plus both endians > > > > for both in theory). The ARM backend also handles both endians (in theory). > > > > > > > > Another wrinkle is that sparc64 uses its own dump format instead of writing > > > > out an ELF file. I had to convert the header structures to use fixed-width > > > > types to be cross-friendly. It would be good to ensure that a new libkvm > > > > can read a vmcore from an old kernel and vice versa to make sure my conversion > > > > is correct (I added an explicit padding field that I believe was implicit > > > > before). > > > > > > > > The code is currently available for review in phabric at > > > > https://reviews.freebsd.org/D3341 > > > > > > > > To test, you can run 'arc patch D3341' in a clean tree to apply the patch. > > > > > > I've just rebased this to port aarch64's minidump support. I just need people > > > willing and able to test on non-x86. Testing with the in-tree kgdb using an > > > updated libkvm would be sufficient. > > > > After a lot of crickets, I have updated the manpages for the new API. I will > > commit this "soon". If you want kgdb to keep working on your non-x86 > > platform, this is your chance to test this before it hits the tree. > > > > What exact test procedure do you suggest for full coverage of an > architecture? Just ensuring that kgdb and things like ps -M -N still work. Btw, Mark Linimon tried to generate a crashdump for me on his sparc64 running HEAD recently so I could test the updated kgdb but it failed to generate a dump. I was hoping that the thread on sparc64 with the guy from qemu would result in working qemu as that would let me do the testing I need for this and kgdb locally. -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Nov 14 11:14:23 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 C9F0BA2DFC0 for ; Sat, 14 Nov 2015 11:14:23 +0000 (UTC) (envelope-from elizabeth@interlinked.me) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.65.240.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B0481092 for ; Sat, 14 Nov 2015 11:14:23 +0000 (UTC) (envelope-from elizabeth@interlinked.me) Received: (qmail 21794 invoked from network); 14 Nov 2015 11:22:29 -0000 Received: from ip68-13-249-237.ok.ok.cox.net (HELO ?192.168.1.156?) (EMyers@wilcox-tech.com@68.13.249.237) by mail.foxkit.us with ESMTPA; 14 Nov 2015 11:22:29 -0000 Message-ID: <5646D19C.9010304@interlinked.me> Date: Sat, 14 Nov 2015 00:15:56 -0600 From: Elizabeth Myers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Brian McGovern (bmcgover)" , Jordan Hubbard , Warner Losh CC: freebsd-arch , Anna Wilcox , "sparc64@freebsd.org" , Sean Bruno , Marius Strobl Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> , <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Sat, 14 Nov 2015 11:14:24 -0000 On 11/11/15 10:07, Brian McGovern (bmcgover) 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. That doesn't mean there isn't a market for it. You might not see the value, but others clearly do. There are plenty of SPARC machines still in production worldwide. Sticking your head in the sand won't make them go away. Comparing SPARC collectors to people who collect BETAMAX is not only rude, it's also wrong. > > 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... I am sure the PowerPC users of FreeBSD would really /love/ to hear your ideas about niche communities in FreeBSD. PowerPC is these days primarily the domain of collectors, especially the big-endian stuff (IBM seems to be pushing little-endian furiously). > > 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 seems like you're handwaving the problem away with some nebulous definition of "project resources." If someone or some people want to maintain it, and continue using it, that is their business. If that constitutes "project resources," then I suppose you are instructing people, "go spend your time doing something more productive?" I am pretty sure it is their choice to spend time on whatever they please. But that's just me. On 11/11/15 00:55, Jordan Hubbard wrote: > Hi Warner, > > I hate to be a voice of pragmatism here when we’re having so much fun discussing it from an architectural perspective, but… Whilst you're having so much fun criticising people for their choice in architecture... > > What’s the actual goal (from a future market relevance perspective) of putting resources, any resources, into sparc64? I think that’s the key question that needs to get asked and answered here since we all know that: As I said above, go ask the PowerPC people this. I am sure they would dismiss you as a bad troll. > > 1) FreeBSD is not NetBSD - it has never historically supported “x86 alternative architectures” just because they existed and might be technically interesting to port to, there had to be some sort of user community numbers to justify the time and energy expended for the project as a whole (and even in an all-volunteer driven project, there is simply no such thing as “free” - everything has a cost somewhere). You are seriously going to use "we're not NetBSD" as an argument? OK, then FreeBSD should only support x86, just like it used to, because "this isn't NetBSD" and it is the dominant architecture in the server, laptop, and desktop world. FreeBSD is obviously a populist operating system and should only work on the latest greatest hardware also. /s > > As phk noted earlier in the thread, the ALPHA port was an exception to this rule simply because it was the first-ever 64 bit port for FreeBSD and we knew it would buy us some much-needed 64 bit cleanliness, but it also fell off the support roadmap and into the history books once ALPHA’s market relevance had clearly ended. ALPHA hardware was expensive (three figures), bulky, and not something very many people had lying around. This is all still true. There are plenty of SPARC's in the wild - and I am willing to bet there are more working SPARCs than working ALPHA machines. > > NetBSD/alpha still exists, all the way up to and including NetBSD 7.0, because their slogan is “Of course it runs NetBSD.” Again, FreeBSD != NetBSD. The emphasis on market share is and always has been a key differentiator for FreeBSD and part of both its own slogans and mission statement. Linux has far more users than NetBSD and supports things FreeBSD would never even dream of supporting. Linux is oriented at the masses (just about anything with users). Are you proposing that Linux should remove support for marginal architectures too just because "they're not popular and there's only a few maintainers?" > > 2) Sparc64 global market share has declined significantly since Oracle purchased Sun, leaving Oracle and Fujitsu as the only two significant players in that market. Sure, putting “old equipment to work” is also always a tempting objective, but it’s one that really requires viewing through an objective lens since the perspective of someone who owns said "old equipment" is rather more biased than the perspective of the market as a whole. The market as a whole appears to consist (in terms of global server market share): > > HP (x64) 27.6% > IBM (x64) 22.9% > DELL (x64) 16.4% > All others (x64): 24% (combined estimate, including Cisco and Huawei) > Total: 90.9% > > [ Source: Gartner ] There are still TOP500 supercomputers that run SPARC. https://en.wikipedia.org/wiki/TOP500#/media/File:Processor_families_in_TOP500_supercomputers.svg - the share has even grown slightly. I am sure there are still dozens of deployments of SPARC out there that nobody is revealing numbers on. Also, PowerPC probably has less than a few percent of total desktop and laptop users - go ahead, propose removing support for those too I suppose? /s > > That leaves 9.1% for the rest of the server industry, which includes Itanium, POWER4 and SPARC64. We can also probably safely assume that even amongst that tiny 9% pie slice, vendors are focused on the future since their overall market share is declining (about 5% annually), which begs the question: Is FreeBSD/SPARC64 aiming at the T5, even while Oracle themselves are shifting emphasis to lower-cost x64 systems for which FreeBSD is already competitive, or is it really just trying to keep some older collection of increasingly power/performance inefficient (by comparison) alive? Itanium is practically dead. I would wager SPARC64 and POWER have about the same marketshare. If people still want to support the architecture, then I think the overall marketshare is frankly inconsequential to the argument. > > Again, what’s the long-term goal of supporting this architecture? The old adage about “picking your battles” applies here, no matter how enthusiastic the small community of remaining SPARC users might be, which is why I am risking lightning bolts of wrath from SPARC zealots in even daring to ask the question. :-) Well you seem keen to pick this battle. If this architecture is so insignificant, then why chime in with all these numbers and arguments about how FreeBSD isn't NetBSD? Either you have a chip on your shoulder, something to prove, or just don't care about the minority as it somehow offends you. And yes, I have a giant chip on my shoulder too. I don't like it when people decide to steamroller because something isn't their favourite thing or "I don't use it at my job and I'm not paid to touch it so screw the people who use this." It's a crappy attitude to have, although it's extremely common. How about you just leave the happy minority alone? :) -- Regards, Elizabeth From owner-freebsd-arch@freebsd.org Sat Nov 14 12:19:19 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 A0DF1A2D04B for ; Sat, 14 Nov 2015 12:19:19 +0000 (UTC) (envelope-from freebsd.contact@marino.st) 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 85B3F1907 for ; Sat, 14 Nov 2015 12:19:19 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: by mailman.ysv.freebsd.org (Postfix) id 84C37A2D04A; Sat, 14 Nov 2015 12:19:19 +0000 (UTC) Delivered-To: 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 6BCC0A2D047 for ; Sat, 14 Nov 2015 12:19:19 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 027B01904; Sat, 14 Nov 2015 12:19:15 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 51F9343BC5; Sat, 14 Nov 2015 06:19:07 -0600 (CST) Subject: Re: Question about ASCII and nl_langinfo (locale work) To: Andrey Chernov , Baptiste Daroussin , arch@FreeBSD.org References: <20151110222636.GN10134@ivaldir.etoilebsd.net> <564373D4.9060403@freebsd.org> Reply-To: marino@freebsd.org From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <564726B8.7060308@marino.st> Date: Sat, 14 Nov 2015 13:19:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <564373D4.9060403@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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: Sat, 14 Nov 2015 12:19:19 -0000 On 11/11/2015 5:59 PM, Andrey Chernov wrote: > On 11.11.2015 1:26, Baptiste Daroussin wrote: >> The thing is not all are aware that FreeBSD uses US-ASCII, for example tcl does >> not. which means tcl is not able to determine what encoding is needed for the C >> and POSIX locales. >> >> On Linux they to return ANSI_X3.4-1968 (also known as US-ASCII) and most >> application knows what linux returns. >> >> That means we need to teach all upstream about US-ASCII all the time. >> >> The proposals are: >> - Do not change what we have always done. >> - Change it to something that makes sense "C" (what we tried with "POSIX" which >> was a very bad idea, but "C" seems to be commonly recognised by application as >> ASCII) >> - Let's report the same as Linux, that will simplify portability >> - Let's be obvious and report ASCII (also commonly recognised by applications) > > Just repeating my opinion in this new thread. > > Since POSIX don't tell anything certain, we should be Linux compatible > here to have less surprise, i.e.: > 1) Return "ANSI_X3.4-1968" for C/POSIX locale (was "US-ASCII"). > 2) Return "ASCII" for *.US-ASCII locales (was "US-ASCII"). > Typical Linux program knows nothing about our "US-ASCII", and porting > handles it rarely. > > Not doing that leads to hidden, hard to find bugs like still present > right now in our tcl ports. For all that years tcl don't understand > FreeBSD-native nl_langinfo() "US-ASCII" and falls back to "iso8859-1" > (it understands Linux "ANSI_X3.4-1968" and "ASCII" of course). > As a DragonFly representative (and probably the person that would implement it), I can accept Andrey's proposal. What it would mean: 1) "ANSI_X3.4-1968" would be the one return value of nl_langinfo(CODESET) that is not in the output of "locale -m" 2) This would require an alteration to usr.bin/locale to add this "ANSI_X3.4-1968" if not found (similar to how it's done for US-ASCII 3) At the same time usr.bin/locale would be modified to change check from "US-ASCII" to "ASCII" 4) The locale tools would have to be modified to change all source and map references from "US-ASCII" to "ASCII" and the six LC* generating makefiles regenerated 5) nl_langinfo would be changed to return "ANSI_X3.4-1968" instead of "US-ASCII" if the encoding equals "NONE" 6) the "make upgrade" utility would need to remove *.US-ASCII locales 7) Do we really need 6 ".ASCII" locales? It has very limited use, I'd suggest just having "en_US.ASCII" and that it. Dump en_AU, en_ZA, en_GB, etc. We can keep all 6 if we want, but if we are removing US-ASCII anyway, we should limit the locales to what makes sense. Alternatively FreeBSD could link US-ASCII => ASCII and have both variations but I think DragonFly will just drop US-ASCII in this case. What nl_langinfo(CODESET) returns has to be reflected in the locale name (with the exception of "ANSI_X3.4-1968") so there has to be e.g. en_US.ASCII as a valid locale if US-ASCII is changed. There might be other changes necessary if "US-ASCII" is changed; I'd have to do a thorough review. To get started, I think this needs to be decided: A) confirm we want locale -m and nl_langinfo(CODESET) to return "ANSI_X3.4-1968" for C/POSIX locales B) Confirm renaming US-ASCII locales to ASCII C) (FreeBSD only) Decide if you want to conserve US-ASCII locales with symlinks. nl_langinfo(CODESET) will return "ASCII" for these symlinked locales D) Decide the set of "ASCII" locales are really needed. (I suggest one, en_US.ASCII) Thanks, John From owner-freebsd-arch@freebsd.org Sat Nov 14 17:16:30 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 759CAA2F90B for ; Sat, 14 Nov 2015 17:16:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 261171B88 for ; Sat, 14 Nov 2015 17:16:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkfo3 with SMTP id o3so77399004qkf.1 for ; Sat, 14 Nov 2015 09:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jL310iG4kp+VRhZiXKLrwqc08dV7STFVvOfVADpHOTo=; b=Za6S79yIsgCRrzejopjl7yefUGlQIJkzmC69lBFF2QPUHCJDN7RF9EcpyN2cvztYFE 9wtOhZrMFA+k750WFZECZtncAOdOpDRkyJ2tCIxN3+MQtgQ1SJcQF1+9yjaB1HuPxIKd n8qzoMa9Aq3WzHox0JBI0TB7Etvcj9AhDF9dO1UVx6zR7upJuhxEPYbMSoBTFN+7TVRZ IYu8o5AGI9vfWezfEHWMd/DiC6WRMbs4pXootOripm7XAgP4EyedC1bX1fno/cQXWilN auSKOeQX9IBFpZ/g4pCAfTKpLZJBbto9LFXkhrkJhezFnVOgDSDWCQGBFgZqIawVh4wu ZYBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jL310iG4kp+VRhZiXKLrwqc08dV7STFVvOfVADpHOTo=; b=WuMBxPsJ0EZN1/zA2zvp/ziDdTOuYh+oIH6FaVoy071nCsZylZEX7AgkJI4J5HOE1x 0iH6DvZoy6B7RekDzFwMEUIfPjy5O2jrQIx4DqttqcWUbkfuMPlFs3qHGD+p7E39IOdW UMxRfpJCx+169/70Gco0xe/Tb9iNyFNGs+UddiaDixXyHSQcbm7EGFD2etxO/yiq+Dt/ tGEZMLJR8NIaKYLeN3NGXKVnyyo5Cq6/gtH30oqcLsdBUjjkNgKD8yNnZKcdLjYPe1NE b0FRF6BLHwlhrkRwEYETmvh6ltyjf0e0vcsat4JvQT6/1M0pRlz2zt2WqLrpBSvFEztG NiZw== X-Gm-Message-State: ALoCoQn9mN4V3LOuv1v1/cEWRBse04gvIXVhlnU0MKltrb+mw6SD/iP68BYrqQMm2jNjB7gBV+tW MIME-Version: 1.0 X-Received: by 10.55.21.65 with SMTP id f62mr28381468qkh.46.1447521389132; Sat, 14 Nov 2015 09:16:29 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Sat, 14 Nov 2015 09:16:28 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <5646D19C.9010304@interlinked.me> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> Date: Sat, 14 Nov 2015 10:16:28 -0700 X-Google-Sender-Auth: vqPm-WLmHdfGHk249Gt9ofeyifI Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Warner Losh To: Elizabeth Myers Cc: "Brian McGovern (bmcgover)" , Jordan Hubbard , freebsd-arch , Anna Wilcox , "sparc64@freebsd.org" , Sean Bruno , Marius Strobl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sat, 14 Nov 2015 17:16:30 -0000 On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers wrote: > You are seriously going to use "we're not NetBSD" as an argument? You noticed I didn't reply to it. The argument is completely lame. FreeBSD runs today in a variety of markets. Some new, some not so new. The thing that makes each of these areas unique is that there's a thriving community around them, FreeBSD still runs well enough on these machines to get something done, and when things break, they get fixed in a timely manner. Alpha was removed because it got broken by some changes, and stayed broken for a long time despite repeated requests to fix it. Sparc64 is on the cusp of that: some minor things are broken, but have been fixed. The current crisis is due to the end of life of gcc in the tree and its fallout coupled with some neglect of the port due to time constraints. At first I was all for removal. With more data, I'm less sure. If the promises are kept made in this thread, it looks to remain viable for a while, though the lack of a qemu-user solution means that packages for a slow platform (where they are really quite useful) will remain limited. Maybe there's enough hardware around that third-party pkg repos can fill the gap, maybe not. I think we should experiment with this model and see what it produces. Give the branching of 11 as the deadline to show something viable... Warner From owner-freebsd-arch@freebsd.org Sat Nov 14 17:51:24 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 132EFA2F269; Sat, 14 Nov 2015 17:51:24 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C6A641919; Sat, 14 Nov 2015 17:51:23 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id CD1F54F418; Sat, 14 Nov 2015 17:51:16 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id tAEHpExZ074354; Sat, 14 Nov 2015 17:51:14 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh cc: Elizabeth Myers , Anna Wilcox , "Brian McGovern \(bmcgover\)" , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 In-reply-to: From: "Poul-Henning Kamp" References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74352.1447523474.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Nov 2015 17:51:14 +0000 Message-ID: <74353.1447523474@critter.freebsd.dk> 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: Sat, 14 Nov 2015 17:51:24 -0000 -------- In message , Warner Losh writes: >At first I was all for removal. With more data, I'm less sure. If the >promises are kept made in this thread, it looks to remain viable for a >while, [...] And in the end that is always what it boils down to: Platform XYZ will be supported as long as somebody is willing to support i= t. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Sat Nov 14 17:54:34 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 96DADA2F378; Sat, 14 Nov 2015 17:54:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [66.135.54.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEBE1B7B; Sat, 14 Nov 2015 17:54:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 4DC4B56083; Sat, 14 Nov 2015 11:54:33 -0600 (CST) Date: Sat, 14 Nov 2015 11:54:33 -0600 From: Mark Linimon To: Elizabeth Myers Cc: "Brian McGovern (bmcgover)" , Jordan Hubbard , Warner Losh , Marius Strobl , Anna Wilcox , "sparc64@freebsd.org" , Sean Bruno , freebsd-arch Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151114175433.GA19271@lonesome.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5646D19C.9010304@interlinked.me> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 14 Nov 2015 17:54:34 -0000 On Sat, Nov 14, 2015 at 12:15:56AM -0600, Elizabeth Myers wrote: > If that constitutes "project resources," then I suppose you are > instructing people, "go spend your time doing something more productive?" In the principle of fairness, let me play devil's advocate for a moment. - it does take some time for re@ to release and test sparc64 images. - having sparc64 in 'make universe' does require developers to spend more time regression-testing their (non-sparc64) changes. OTOH once an architecture is removed from 'make universe' it's effectively dead, as bitrot sets in instantly. mcl From owner-freebsd-arch@freebsd.org Sat Nov 14 20:04:54 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 95ED6A2FDB4; Sat, 14 Nov 2015 20:04:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 514B6115E; Sat, 14 Nov 2015 20:04:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id tAEK4puu065003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Nov 2015 12:04:51 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id tAEK4o7U065002; Sat, 14 Nov 2015 12:04:50 -0800 (PST) (envelope-from jmg) Date: Sat, 14 Nov 2015 12:04:50 -0800 From: John-Mark Gurney To: Mark Linimon Cc: Elizabeth Myers , Anna Wilcox , freebsd-arch , Marius Strobl , Sean Bruno , Jordan Hubbard , "sparc64@freebsd.org" , Warner Losh Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151114200450.GH65715@funkthat.com> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <20151114175433.GA19271@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151114175433.GA19271@lonesome.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 14 Nov 2015 12:04:51 -0800 (PST) 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: Sat, 14 Nov 2015 20:04:54 -0000 Mark Linimon wrote this message on Sat, Nov 14, 2015 at 11:54 -0600: > On Sat, Nov 14, 2015 at 12:15:56AM -0600, Elizabeth Myers wrote: > > If that constitutes "project resources," then I suppose you are > > instructing people, "go spend your time doing something more productive?" > > In the principle of fairness, let me play devil's advocate for a moment. > > - it does take some time for re@ to release and test sparc64 images. > > - having sparc64 in 'make universe' does require developers to spend > more time regression-testing their (non-sparc64) changes. Considering the number of breakages that happen that would have been caught by make universe, it is clear that few developers run this target, so not really a valid argument... Also, we have universe11{a,b} in the cluster to help cut down the time.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."