From owner-freebsd-arch@freebsd.org Sun Oct 8 19:17:22 2017 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 CC4FDE3DB9F for ; Sun, 8 Oct 2017 19:17:22 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4C474530 for ; Sun, 8 Oct 2017 19:17:21 +0000 (UTC) (envelope-from peter@rulingia.com) Received: by mailman.ysv.freebsd.org (Postfix) id E5C3CE3DB9C; Sun, 8 Oct 2017 19:17:21 +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 E54E5E3DB9B for ; Sun, 8 Oct 2017 19:17:21 +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 "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19F4B74525 for ; Sun, 8 Oct 2017 19:17:20 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v98Im72O022203 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Oct 2017 05:48:14 +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 v98Im086092273 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Oct 2017 05:48:00 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v98Im0Mu092272; Mon, 9 Oct 2017 05:48:00 +1100 (AEDT) (envelope-from peter) Date: Mon, 9 Oct 2017 05:48:00 +1100 From: Peter Jeremy To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171008184800.GD36522@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 19:17:23 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Oct-05 16:28:44 -0700, Warner Losh wrote: >I'd like to start a conversation about the viability of making C++11 a hard >requirement for bootstrapping FreeBSD and setting a specific deadline for >doing so. I don't have any specific objection and the suggested timeframe sounds reasonable to me. >I'd like to propose we do this 12/31/17. Any architectures that can't meet >this timeline will be disconnected from universe at that time and deleted >3/31/18. Note that FreeBSD is an international project. Using abbreviated US-format dates can be ambiguous. Please either use ISO standard dates (2017-12-31) or a variant with the abbreviated month name (2017-Dec-31) to reduce the scope for confusion. --=20 Peter Jeremy --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJZ2nLgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs08V0P/3bY/K6DmeWdCcQudHvjmS28 /tRKidm79EOyhv4V36jtvJBPdRmk77dr+xQFSpq8n7f1UbUnt1qchx/mLGirbOa9 fLFf5BXocaM8jm3ER2IJlD0/1uKP5QhzLMeWkEZyxPFsJeMw8Bmp7TQMkBHb68/W un/fDpYvMWDVHPYmJneV6IEiUQG2e2deNMLQZUe+3QxTKGwG2c9EIsH9lzXKzR6y 4AwMXH2bhvfFntsv/qm7B/arhXVGQErxJRmaXm/jEi8cpiYZ5CVuhIrJpQHFrqDn Hplw0foxYsviyF/ZEFw/k8/S3tVHX1NgbRTPaNtvV4op4QnQhYmK6bt+ThnWLPSX 6o6GpLvKN7zhEkyTSOQFmgtHyatjONhzIS+dxwTAnrgYg3R7xEePc8x6aepIXvvo lcyMkWsJbAPwUHZq8ALyTN65qD3+g46w5YDYQZQlpUij/Ot6lF9Pyty853UBp+zb E93AVxvhpXhv9lAk+ADjjZALfPZ0iov732YmKlACdsu7s532TwdxHgQfAfiWYnRY z3IEOODF66sNrm9+zoXPESBdn6LLAgboFtjtb9zhOz/hcSXQJllKk6Mo110Ezah+ Vj7m+9JKNotQxmUVhmTO9dz7KKDDhkOgPli2drBV1QUDXEth9GY2snev7Wcb7yNu Ngs7E+b0WBJXqLLyFl7m =kgu5 -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From owner-freebsd-arch@freebsd.org Mon Oct 9 05:09:06 2017 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 CA44DE25333 for ; Mon, 9 Oct 2017 05:09:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 72D9E720CF; Mon, 9 Oct 2017 05:09:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-10-148.dyn.iinet.net.au [115.166.10.148]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9958rgG065387 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 8 Oct 2017 22:08:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: lua in zfs To: Andriy Gapon , Ian Lepore , Warner Losh Cc: "freebsd-arch@freebsd.org" References: <1506614109.31939.20.camel@freebsd.org> From: Julian Elischer Message-ID: <17197084-f116-7047-6688-16a0daa7f8e1@freebsd.org> Date: Mon, 9 Oct 2017 13:08:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 05:09:07 -0000 On 29/9/17 12:50 am, Andriy Gapon wrote: > On 28/09/2017 19:44, Andriy Gapon wrote: >> On 28/09/2017 18:55, Ian Lepore wrote: >>> Iirc, the big difference between 5.2.x and 5.3 is that the latter added >>> support for integers.  It seems like that would be a good thing, in the >>> kernel. >> I am sure that the ZFS Lua represents numbers as integers and has no floating >> point support at all. > > Some more info: > https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/fs/zfs/lua/README.zfs > I suggest as a point to feed back to the originators that a name change may be in order.. klua (kernel lua) perhaps. From owner-freebsd-arch@freebsd.org Mon Oct 9 05:11:38 2017 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 A8147E253D3 for ; Mon, 9 Oct 2017 05:11:38 +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 3B22F72A62 for ; Mon, 9 Oct 2017 05:11:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9951DCK004640 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 8 Oct 2017 22:01:13 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Nathan Whitehorn Message-ID: Date: Sun, 8 Oct 2017 22:01:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVY3W547ktyH4fmrPvelVsOXOR5c/+JLjVZlTxvneW0d+AEG8Erw3nkZ6VRjdhjGWv/I1jp6coryUwGVKHDSsBPdSRtFJ9l9tiI= X-Sonic-ID: C;ggh0366s5xGFD4KfRUfeDw== M;tOHC366s5xGFD4KfRUfeDw== 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.23 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 Oct 2017 05:11:38 -0000 On 10/06/17 00:20, Baptiste Daroussin wrote: > On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>> I'd like to start a conversation about the viability of making C++11 a hard >>> requirement for bootstrapping FreeBSD and setting a specific deadline for >>> doing so. >>> >>> This discussion is motivated by an ask from the jemalloc folks to use a >>> limited subset of C++11 inside of malloc in such a way that is C safe (so >>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>> discussion in another forum, and isn't appropriate for this thread because >>> this has become a frequent request (but if you have opinions, please find >>> the thread in current@ about it). I don't know the timeline of their plans >>> to do this. >>> >>> I'd like to take the rather vague plans we've had "before 12" and create a >>> timeline for removal of gcc 4.2 coupled with a requirement for support in >>> clang or a working external toolchain. This requirement would be coupled >>> with the requirement that the external toolchain support C++11 constructs. >>> >>> I'd like to propose we do this 12/31/17. Any architectures that can't meet >>> this timeline will be disconnected from universe at that time and deleted >>> 3/31/18. >>> >>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are >>> ready for this change and mips* would be ready for this change with an >>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect that >>> a newer version of gcc as an external toolchain could work. >> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). However, >> it requires external ld.bfd. I know that there ld.lld can link a working >> mips64 world with some patches (notably the multigot patch). mips works fine >> with external GCC. riscv is already using external GCC that is C++11-capable. >> >> The problem with external GCC is that you can cross-build a world + kernel >> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, >> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >> started on ports to cross-build binutils and gcc packages via the base/* >> ports, but those are not yet finished / fully tested. I don't think anyone >> has thought about how release builds will work either with only an external >> toolchain available. (I'm pretty sure sparc64 has booted fine with >> external GCC, it's just in the same boat as mips with regard to /usr/bin/cc.) > Actually I did test those and they were working (tested in qemu) they were > working fine. I have given up working on them due to the lack of interested by > the community (by interest I mean people really testing, working on it, not just > saying "hey nice sounds cool"). > > As for the boot when I initially worked on external toolchain sparc64 was my > guinea pig and so yes it worked an booted just fine. So far as I know, we never solved any of the infrastructural problems associated with this concept: 1. Providing built releases with a /usr/bin/cc 2. Coversioning base and in-ports toolchain, including ensuring commit atomicity between toolchains and libc 3. Adding a dependency on ports for src, including out-of-tree code that has to be fetched from external servers 4. Getting make universe to do the right thing We really need to solve those. If we go the external toolchain route, which it is not clear to me is the best option, #2 and #1 are quite complex problems. I think that, frankly, a deadline in two months to solve this set of political problems we have had for two years is probably crazy, but maybe making the status quo unsustainable will finally force progress. Also, are there any directions for how to build a toolchain from the base ports? I haven't been able to figure it out -- the README starts with "pkg install", but that doesn't get me very far on platforms without binary packages, which are the ones this is meant to target. -Nathan From owner-freebsd-arch@freebsd.org Mon Oct 9 05:26:55 2017 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 B6AFBE25984 for ; Mon, 9 Oct 2017 05:26:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 4894E7616E for ; Mon, 9 Oct 2017 05:26:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id i38so7837730iod.2 for ; Sun, 08 Oct 2017 22:26:55 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=yzTwLyGNDftZLEP3nQrns89bw7Sej8S7ql1QYA/0JHI=; b=IO0UTOHED2xYYujgeUeU3emJZpzA/No7vzKY/2oZjfZUHJneqE8+kqMvNGyEskv5Ta Uk8zNxzY3kOFWBM0JBpdeUGKFEUeZiq5u0Y4KwRm00lTo35L58Ui/rmEvZz5acUTlvTN R/imu0T3E9Qe1OPZb9tVkHLzAGgeaV18wKyBfo+3myr7wavek8d9q8JhsVO7DJ4LG2RR ujNdWZQuEsExKYmhWsWASPCNzSq0X4VL0YQd0ixlB3U3IK4JYoOFYjYks+jb3ThgrARn FQWpqSLVEG2WnaGsgcz4Mqz0Fe05sg3NHj6uK8LydsgW7hkeNamLj9ovt+9e31a8op90 BL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yzTwLyGNDftZLEP3nQrns89bw7Sej8S7ql1QYA/0JHI=; b=fvvp8zZCZQ/Id6V/IWS97cWOHSIbHdyULlS38mtmKjsiniJzP8hRXNvFB96RDVJk0U 0lWQrsEmYY39OuIzuyBJeNs9rTg+T3/L7+p+vEvLj2UrBQmDRVzxDhCsyp6m8wC1BON7 3Q1lDEr3UD36XbzDkFl39+rCsNel4trUO2mOwECrkXV857UbFGBS5J7RCkS0/IqfMhN9 o9cErnzzuKRTCv/XNR1jWlCleWj2MtUHSSUKv4Ho+tnq2VVL5CruwWtI5I0Jas2OKdYC TkdGi8CHCpoa+sz7FAStV0FxNVte/8EhGlFxesaGYJsZqJq2tQLy2LdxLeiQL32bagQA cZOQ== X-Gm-Message-State: AMCzsaXZHmkNo3SyW8ryxSrVE+SUb2DBRgoNw/QyGsylFOWMXDzDbdZf UDlmLsz7RLfXWLG7H2fHEO/n9oBj92rNF+useiMyZA== X-Google-Smtp-Source: AOwi7QAlKAFNKzJag/FgLEm2Pn2AlV9Lo+C0yRVpEvRR3sjPSv8jiFTTHUskc24uh6FI6aGzAgpLAcR1zJ5FvK7gFcQ= X-Received: by 10.107.135.202 with SMTP id r71mr3862665ioi.26.1507526814427; Sun, 08 Oct 2017 22:26:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Sun, 8 Oct 2017 22:26:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Warner Losh Date: Sun, 8 Oct 2017 23:26:53 -0600 X-Google-Sender-Auth: nHonnO7aCyfewxA8jvmPhRQ9Z2E Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Nathan Whitehorn Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 05:26:55 -0000 On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn wrote: > > > On 10/06/17 00:20, Baptiste Daroussin wrote: > >> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >> >>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>> >>>> I'd like to start a conversation about the viability of making C++11 a >>>> hard >>>> requirement for bootstrapping FreeBSD and setting a specific deadline >>>> for >>>> doing so. >>>> >>>> This discussion is motivated by an ask from the jemalloc folks to use a >>>> limited subset of C++11 inside of malloc in such a way that is C safe >>>> (so >>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>>> discussion in another forum, and isn't appropriate for this thread >>>> because >>>> this has become a frequent request (but if you have opinions, please >>>> find >>>> the thread in current@ about it). I don't know the timeline of their >>>> plans >>>> to do this. >>>> >>>> I'd like to take the rather vague plans we've had "before 12" and >>>> create a >>>> timeline for removal of gcc 4.2 coupled with a requirement for support >>>> in >>>> clang or a working external toolchain. This requirement would be coupled >>>> with the requirement that the external toolchain support C++11 >>>> constructs. >>>> >>>> I'd like to propose we do this 12/31/17. Any architectures that can't >>>> meet >>>> this timeline will be disconnected from universe at that time and >>>> deleted >>>> 3/31/18. >>>> >>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are >>>> ready for this change and mips* would be ready for this change with an >>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect >>>> that >>>> a newer version of gcc as an external toolchain could work. >>>> >>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). >>> However, >>> it requires external ld.bfd. I know that there ld.lld can link a working >>> mips64 world with some patches (notably the multigot patch). mips works >>> fine >>> with external GCC. riscv is already using external GCC that is >>> C++11-capable. >>> >>> The problem with external GCC is that you can cross-build a world + >>> kernel >>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, >>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >>> started on ports to cross-build binutils and gcc packages via the base/* >>> ports, but those are not yet finished / fully tested. I don't think >>> anyone >>> has thought about how release builds will work either with only an >>> external >>> toolchain available. (I'm pretty sure sparc64 has booted fine with >>> external GCC, it's just in the same boat as mips with regard to >>> /usr/bin/cc.) >>> >> Actually I did test those and they were working (tested in qemu) they were >> working fine. I have given up working on them due to the lack of >> interested by >> the community (by interest I mean people really testing, working on it, >> not just >> saying "hey nice sounds cool"). >> >> As for the boot when I initially worked on external toolchain sparc64 was >> my >> guinea pig and so yes it worked an booted just fine. >> > > So far as I know, we never solved any of the infrastructural problems > associated with this concept: > 1. Providing built releases with a /usr/bin/cc > 2. Coversioning base and in-ports toolchain, including ensuring commit > atomicity between toolchains and libc > 3. Adding a dependency on ports for src, including out-of-tree code that > has to be fetched from external servers > 4. Getting make universe to do the right thing > > We really need to solve those. If we go the external toolchain route, > which it is not clear to me is the best option, #2 and #1 are quite complex > problems. I think that, frankly, a deadline in two months to solve this set > of political problems we have had for two years is probably crazy, but > maybe making the status quo unsustainable will finally force progress. > External toolchains have been in flight for 5 or more years now. It's time they land. Though the requirements for them have never included cross-threading between /usr/src and /usr/ports like you suggest above, and those sorts of things won't be sorted by my deadlines (which are closer to 3 months). Nor, imho, should they. > Also, are there any directions for how to build a toolchain from the base > ports? I haven't been able to figure it out -- the README starts with "pkg > install", but that doesn't get me very far on platforms without binary > packages, which are the ones this is meant to target. External toolchains are by definition external. Not part of the tree nor integrated into the tree. How you get them depends on the external toolchain and is unspecified. You get a lower level of integration than you do with in-tree toolchains, not the same level with reach-overs into some external repo. Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 05:45:40 2017 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 8AD10E260C9 for ; Mon, 9 Oct 2017 05:45:40 +0000 (UTC) (envelope-from wlosh@bsdimp.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 EE3297E39A for ; Mon, 9 Oct 2017 05:45:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id E5B6FE260C8; Mon, 9 Oct 2017 05:45:39 +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 E2ADEE260C7 for ; Mon, 9 Oct 2017 05:45:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 72F917E38C for ; Mon, 9 Oct 2017 05:45:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id j140so7083462itj.1 for ; Sun, 08 Oct 2017 22:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=QzBUkz56odmNNwY79LOnRS0x8MwVJSshT0CpI718WhU=; b=IPQAlKcFZESCU3Je1KRt2OaB21Qoy2Z3LGffbDPxYJtPo8bfumCbJ+ef+PgsKYmtWv EnYgzg3S13uIiXtceaviEtt/kR3mMpIKDD6RQr/ZJLDO8A7WxlKzwVJ/tmyVEKfXWFaw 0cYFZtYGHbJiZA2VCiEIxxvc38rP+aN1vxyV9i6IX4rOyhRXKweAzTq6rukAwcIux25/ XVN6uNEb/Vux+ZevvGubeYqM3NBOb4BBT6GEPOphu0job8lSpDBHfKL+B/mW8MGNs99t jUzkZEvj8FZhHRj+uSUkie1HfPnZIYRgbQJS3PxX3Eic+SouTKDfi8aOw3hRuUyBL/is l2qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=QzBUkz56odmNNwY79LOnRS0x8MwVJSshT0CpI718WhU=; b=PstAkmSk7DpXOWAQyyH1G//e2sdsbZPu8gFHldomOmcQzIpCR9GkWv6BfyiBvROomr AmHmibHZPt9U+VNG7BfsSHkN7y87zVvif8K4Lqo03ktvXmWU1FDsgcMymWKkqmIHRDx+ OZZWjojkzKsEEJ/M+e7L2yrQeqrCSu9c9Ik5wIwIky9XbyAe41QK7DyaZCIHNW3oizp0 BmNI7e2N7TMh7Xi+rDFGlPvkOV6p91BbFxp9MlGfR74/zdcWV+3+1VJxgz7/AJ/RzVEF SEGruXzE6PaCOQgWftCpKEjX9xZGGnB/Xqowrc+4EXn3so+RGiUc/thWR2LkEx4T7goc tZtA== X-Gm-Message-State: AMCzsaXi1nStEryar6YQwTF4UkAggn7D2CWBkim00X6BlPMoAzYdTB7w z7U7jOLNm4A6Bq02oZDSbTetfuqiar1xVfQfudbnVQ== X-Google-Smtp-Source: AOwi7QB82+cls6E1SZIg4ug7jzV2ZEALMuIgqfpue4r+kJuDDXvW+CBMUVEQctfzjj8rMOjeYr1jGUkkvs4c4ThLyaw= X-Received: by 10.36.201.4 with SMTP id h4mr12671216itg.26.1507527938271; Sun, 08 Oct 2017 22:45:38 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Sun, 8 Oct 2017 22:45:37 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] From: Warner Losh Date: Sun, 8 Oct 2017 23:45:37 -0600 X-Google-Sender-Auth: u-cCHr6IPPmrXyyzMsOOgObF4Bc Message-ID: Subject: deorbiting /usr/lib/libstand.a, moving to sysboot To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 05:45:40 -0000 I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are really parts of the boot loader with an unstable API and shouldn't be installed into the system. It's really a private library to the boot loader. Further, I'd like to move the whole shooting match into sys/boot/libsa (the name change is on purpose to break anything that used libstand). With these changes, one can cd sys/boot and do a make clean; make all and have it not depend (too much) on the host computer. It will also let us clean up a lot of the cut and paste and only half working implementations of this idea we have now in a clean way. We can also move the files in sys/boot/common that aren't actually part of /boot/loader into libsa since there's would be no good reason to keep them separate (though ultra-tiny loaders can cherry pick individual files, or compile things in a custom way if that's really needed). I've been cleaning up the sys/boot Makefile technical debt and this will go a long way towards disentangling things (though there's a lot to do besides these fixes). History is against FreeBSD's practice, btw. We're the only BSD that cross-threads like this (dragonfly may also, I haven't checked, but they got it from us if so). NetBSD/OpenBSD have sys/lib/libsa for this stuff. 4.4bsd had each arch build its own libsa.a from files living in sys/ARCH/stand. 4.2BSD did install things as /usr/lib/libsa.a, but it was from inside of sys/stand and friends. v7 had a similar structure to 4.2BSD, but with files living in different directories (they installed libsa.a into /usr/lib, but again from sys directories). Since we've ditched the 4.4BSD structure that NetBSD/OpenBSD evolved, I don't think it makes sense to go the sys/lib route (since this is only used in the boot loader) Since sys/boot programs know its internals so much that claims of independence would be hard to sustain. Having it in sys/boot would also help the POLA this change might cause by fixing a POLA breakage now (it fixes when libstand API changes break the naive build, as well as ensuring hacks to libstand will get built when a new boot loader is built). So we invented the current situation, we can change it since nothing outside the boot loader uses it (and if there are out-of-tree examples that use it, they could be converted to the new structure). Any objections to my moving forward with this (assume I'll help people fix any in-flight work this disrupts)? I know the plans are a little vague, but I was hoping to get rough consensus while I came up with woking code and go all IETF old-school on the problem. Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 06:49:50 2017 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 61FD1E272C2; Mon, 9 Oct 2017 06:49:50 +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 "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A8B2669EC; Mon, 9 Oct 2017 06:49:48 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v996nbcW024600 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Oct 2017 17:49:44 +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 v996nVT9095657 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Oct 2017 17:49:31 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v996nVDg095656; Mon, 9 Oct 2017 17:49:31 +1100 (AEDT) (envelope-from peter) Date: Mon, 9 Oct 2017 17:49:31 +1100 From: Peter Jeremy To: "K. Macy" Cc: "A. Wilcox" , Mark Linimon , freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171009064931.GC93566@server.rulingia.com> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 06:49:50 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Oct-07 19:06:29 +0000, "K. Macy" wrote: >On Sat, Oct 7, 2017 at 10:41 Mark Linimon wrote: > >> On Thu, Oct 05, 2017 at 07:12:28PM -0500, A. Wilcox wrote: >> > That doesn't change the fact that sparc64 still exists, and with Oracle >> > laying off Solaris as well, FreeBSD becomes a "way out" for people >> > heavily invested (DC full of sparc64 gear, or such). >> >> I have thought for some time that we've been a "way out" for Solaris >> sites wanting to keep ZFS and not deal with licensing issues, and have >> worked to keep sparc64 alive. (AFAIK FreeBSD is the only open source >> sparc64/zfs solution?) AFAIK Illumos still supports sparc64 and is probably an easier migration for Solaris sites so I don't think that argument holds. Also, we run into the same situation we had with Alpha - a basically dead architecture that only runs on old equipment. Unless there's a critical mass of FreeBSD developers that are willing to keep it running, we're better off killing it quickly, rather than letting it soak up developer effort. >My recollection of sparc64 from sun4v work was that unsupported operations >would trap in to the kernel which would in turn trap in to a user space >handler for floating point emulation. Yes. I did some poking at that some time ago. The userland package is basically a complete single/double/quad precision IEEE FP implementation (see /usr/src/lib/libc/sparc64/fpu). I have a test suite for it but it hasn't been committed and I'd need to check if it's developed any bitrot. --=20 Peter Jeremy --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJZ2xv7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0vUkP/RD8kmph383cMaY7/kybA62m wfT9tKR7XZf3cAUbOWyQ8MRKJ2M+H2JzuVPMVkR8EVUtTnsvUUrBuJ4jMdepSTPM sMTsEf6aIX9tKIiwiKdHmFVljWCYvmbWwMhRoQKoWg59IVRRpfgj8twmHYts9V/P 7WRNKE/husblOu0fxWNQUtsPf42rJGjuYjBmEq1u5aFVrq9zmzGODxuTS4p4L21u YqdHfwiLuRJlA2tWEb2c52O1LZF4shlbYv9y19WaWdgwXYLI+oUYRDjVemmm9yMW viXSM406VDUKWgBhMteuYhhmxciEP1rkRzfsxKSqdYw32ugnHQBnONTldBEg0lGB OrFKfXJh+YLC9iOAYHsPmaAUBhXZ8MEAJxzbSliR/jLeXZmWWqFJmZzT62Jga2jc bijn06VwpsCg0AKj7JGOZ1YXv+EMmgaaiKJxBM0chdhe3+edxEdh86cyK9Rawjwk xLrAFCeZesSfv9P7I5w/GvFA8Yw6TmDyoEceEnaPNo37b6HbYH97at2GAFT1Kl8E aA74mVgL6YFsgiPgTfYoyh8DG4ev2jT0GFdzROCsMam99HKAmLKMVkE0mi5WaTJn q8uN4HalKCj7W0/Zq0R9zMdxWU1nt9qxZREjPetUNUFnKYR5zWUx5O2wtgcshtxi VZ++Xri4K8weXWsw43Ve =48hN -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-arch@freebsd.org Mon Oct 9 06:50:41 2017 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 5727EE27352 for ; Mon, 9 Oct 2017 06:50:41 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C233866C3B for ; Mon, 9 Oct 2017 06:50:40 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 7618DE27351; Mon, 9 Oct 2017 06:50:40 +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 74BEFE27350 for ; Mon, 9 Oct 2017 06:50:40 +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 EB80266C2B for ; Mon, 9 Oct 2017 06:50:39 +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 6C68A2738F; Mon, 9 Oct 2017 06:50:25 +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 v996o8NQ039631; Mon, 9 Oct 2017 06:50:09 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh cc: "freebsd-arch@freebsd.org" Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39629.1507531808.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Oct 2017 06:50:08 +0000 Message-ID: <39630.1507531808@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 06:50:41 -0000 -------- In message , Warner Losh writes: >I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are >really parts of the boot loader with an unstable API and shouldn't be >installed into the system. It's really a private library to the boot load= er. Long overdue! -- = 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 Mon Oct 9 07:00:25 2017 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 CFC83E275D0 for ; Mon, 9 Oct 2017 07:00:25 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 40D7B69411 for ; Mon, 9 Oct 2017 07:00:24 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mailman.ysv.freebsd.org (Postfix) id E2663E275CF; Mon, 9 Oct 2017 07:00:24 +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 DF9B8E275CE for ; Mon, 9 Oct 2017 07:00:24 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 02F9D693FB for ; Mon, 9 Oct 2017 07:00:23 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-lf0-x22b.google.com with SMTP id a16so8726831lfk.0 for ; Mon, 09 Oct 2017 00:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t9O3bQKMHWgI74boUs91hoyTj0befDp/0b+3UwIDeh0=; b=WVeUWsVdXY7BVTgTR4O04KDaBBVxvWsKvpx+lB1StN3nkrdTtXwYLycCBOf4eJbKHa qGDDsYvP+xscariCW9IvIstQaOLxnwWL3c2tDE/XLpNkE3fG9IbJxUUEz24u/VafXTzZ GGpd8rUJulf9wPSVqKZaYVafp5dZWCayszKZ57pIiaWseor85xYmSgVaymPSjy0BDhHv DrtCUOEoTcyvYXtMrzA/Zyw/PkIYFciXzTBTYKHTDdnxR1JP6YhAYYM6sS0hb1TFf7Cf MHP752lW0Brm2GezDBRu5/R4VadWyeW/YOdjhvR+6BMqMuzAf4A+rUoZL1YsyLDIAWcQ 0gRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t9O3bQKMHWgI74boUs91hoyTj0befDp/0b+3UwIDeh0=; b=BJZ3tEhQjU9rc2bo2ew8imxW3mHiKXO+dDJfT61qTT3LOotN4WbWQtTxUUr+4ioc/8 S9a6A5+GXUlx9hWJard0O26S1GRI5uBm1+ZdkbHeR5eXmRrDrN3Z0Ys5WtvbF6+iMg8t TE95fF/zaSpxkFqt66lwOFbJXMJ5ifyz3P0zC5ahzdQjTKkVAJLGEVhT/0Q6uFPVQpCq wwgTLdGqXQSvcIqIk22vho/B5mZPMoDf6iinFPXhHRagN2ZK+9FEXl3tOzuYITTBmA0i JcTLfs1Kx9MdBfcc8XhlMAQRDXNyaEJUrly1neRHuwI3DO9DLeXWdZL003hBc8vf+9bf yF3Q== X-Gm-Message-State: AMCzsaV4HSpVPmm3AIOfMCa/05o9JEZXw1xoakrpdMg/UiHBbT78SfVx rCweZ+BKON7tzPyETBxtBkGDvIscMYo8minUB8ibFIdm X-Google-Smtp-Source: AOwi7QCjckvx8OF4b9KUYTwuPzvDnoHZwp7ympVqrKYJUUqEI6NCMLVsP6ovqPuMQ7MEQG1mrQtsjnm7R1SoSLKijYI= X-Received: by 10.25.38.6 with SMTP id m6mr3605657lfm.226.1507532422238; Mon, 09 Oct 2017 00:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.15.220 with HTTP; Mon, 9 Oct 2017 00:00:21 -0700 (PDT) In-Reply-To: <39630.1507531808@critter.freebsd.dk> References: <39630.1507531808@critter.freebsd.dk> From: Doug Rabson Date: Mon, 9 Oct 2017 08:00:21 +0100 Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Poul-Henning Kamp Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 07:00:26 -0000 I've been wanting to do that for years - go for it. On 9 October 2017 at 07:50, Poul-Henning Kamp wrote: > -------- > In message gmail.com>, Warner Losh writes: > > >I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are > >really parts of the boot loader with an unstable API and shouldn't be > >installed into the system. It's really a private library to the boot > loader. > > Long overdue! > > -- > 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. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Mon Oct 9 08:26:04 2017 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 4C868E29244; Mon, 9 Oct 2017 08:26:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3B287FF73; Mon, 9 Oct 2017 08:26:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 4857A3C1D99; Mon, 9 Oct 2017 18:57:27 +1100 (AEDT) Date: Mon, 9 Oct 2017 18:57:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Jeremy cc: "K. Macy" , Mark Linimon , "A. Wilcox" , freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) In-Reply-To: <20171009064931.GC93566@server.rulingia.com> Message-ID: <20171009175448.U1674@besplex.bde.org> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171009064931.GC93566@server.rulingia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=LI0WeNe9 c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=GRsoY76EHTS8MM7AKMcA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 08:26:04 -0000 On Mon, 9 Oct 2017, Peter Jeremy wrote: > On 2017-Oct-07 19:06:29 +0000, "K. Macy" wrote: >> My recollection of sparc64 from sun4v work was that unsupported operations >> would trap in to the kernel which would in turn trap in to a user space >> handler for floating point emulation. > > Yes. I did some poking at that some time ago. The userland package is > basically a complete single/double/quad precision IEEE FP implementation > (see /usr/src/lib/libc/sparc64/fpu). I have a test suite for it but it > hasn't been committed and I'd need to check if it's developed any bitrot. No, the trap method is almost never used by default, and should never be used since it is so slow. sparc64 on the 1 sparc64 system that used to be in the FreeBSD cluster uses soft-float for long doubles by default (this is the gcc default) since "hardware" (actually usuallly or always emulated by trap handlers) for long doubles is so slow. Something like 6000 times slower for "hard" (trapping) long doubles on old sparc64 vs not so old x86 (with x86 clock speed about 6 times higher, and better pipelining). Soft-float for long doubles is only about 4000 times slower. Real hard-float for doubles and floats is only about 20 times slower (much the same as for integers). The only advantage of "hard" float on sparc64 is that it is easier to debug, provided the bug is not in the trap handlers when it is harder to debug. Soft-float has more chance of working on sparc64 since it is needed in some cases. The flag for the case where it is needed is -msoft-quad-float. On x86, clang is too broken to even refuse to support -msoft-float -- clang silently ignores this flag, so this flag non longer works in kern.mk where it is supposed to stop the compiler using an FPU in the kernel. gcc-4.2.1 only has this bug on amd64. The i387 happens not to be used anyway in code without float variables. SSE is more generally useful so the -mno-sse* flags to prevent using it are more needed. Bruce From owner-freebsd-arch@freebsd.org Mon Oct 9 10:54:38 2017 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 9A3DFE2CC7B for ; Mon, 9 Oct 2017 10:54:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3D07B81509 for ; Mon, 9 Oct 2017 10:54:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2D24EE2CC77; Mon, 9 Oct 2017 10:54:37 +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 2CB2AE2CC76 for ; Mon, 9 Oct 2017 10:54:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 892D8814FC for ; Mon, 9 Oct 2017 10:54:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id m123so13242508ita.3 for ; Mon, 09 Oct 2017 03:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iy3XK4MIq8RB+4UB6llWUjD3XDKmNTClnwhTSOBJY0c=; b=b9Kdi3EizgtvodJonsB1ZFpnRINjQn9jOzKcqEoafOMx6n+PqIPU8/Q0c1Yt8AeEwg dU88OB9meG4ozpNhC3XUpTrsrHpYGpjU3dBxilLQd+wYsPlZceoNx5eityCalN87mdZx hu9BOcimA+IDCuE9YgdCMJlZy6u121aHtIHYL5VtVicIEj21fl+XwVBrxmqLbr7FYl3r BwZ+b3Ehm4Zs5brS973kbcr2C/q7yJ24PZvx6lTMKLzfnPSFPT7iKperjaCZzRq9G2TB 6sTgThoRAPiVkr0HrrJgIuVO7JWNMrRTQnvqV2zVa9Nv7rywV10pRmF3+ybKcQnIyI20 1DJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iy3XK4MIq8RB+4UB6llWUjD3XDKmNTClnwhTSOBJY0c=; b=rEV75h9PhlAFRatVAH7d0SoZqhzsvAdFV3AwGFJGTi7h7Q3LwxMkrpV1Uy1QE3k8pz b7yP+fkp/p1X6wu6hje8AJgWFoe+DBrc5qQCPLZlgy+IRFgk5xmxLLMMyWCi0UYC/wrR TQKRuAFpdyvYLS7N4+g5XYmW6DRUXWzIVU3QxC5n+YV4nPFfKB8YIHR/8XlD2MTHUn5g gmvicl3V7HUBZS4/ym8tOZeXB8TQef1qNLbmkv7UJpOqiXY/HE7TkWoZ3IgwaJjzQx9B vBY9nCrSaD/L1zw6JhLueGIl80clrNrz3oGAloch+MB4tT40BDuiZoAsTSxdyGgeWU0+ vJdQ== X-Gm-Message-State: AMCzsaW39/iRf4m5w2oLSMsJtE5GQrFUC/+zhlBIIHy16GLN7ELRcwI5 5Kgn7F/+jJJ+TIrRW3MUGgMkj3968ASQVEHZRa4= X-Google-Smtp-Source: AOwi7QDorJPoPVWL/MPPcI+MzHDhtnurS7d59QGZHviphrxkaPXgQBQgQJH53pomPuf6Hm56ZtsNsJGqZquxSJra6c4= X-Received: by 10.36.73.99 with SMTP id z96mr13338293ita.36.1507546475274; Mon, 09 Oct 2017 03:54:35 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.4.80 with HTTP; Mon, 9 Oct 2017 03:54:14 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Mon, 9 Oct 2017 06:54:14 -0400 X-Google-Sender-Auth: u2pPnUx-A0cnxQ8RPMUsIjcCIuQ Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Warner Losh Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 10:54:38 -0000 On 9 October 2017 at 01:45, Warner Losh wrote: > > Any objections to my moving forward with this [moving libstand to sys/boot/libsa] Go ahead, IMO. Note that we already have sys/boot/libstand32 that we'll want to include in the cleanup. From owner-freebsd-arch@freebsd.org Mon Oct 9 15:36:33 2017 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 14F98E3356B for ; Mon, 9 Oct 2017 15:36:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 87F887E561 for ; Mon, 9 Oct 2017 15:36:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 57062E3356A; Mon, 9 Oct 2017 15:36:32 +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 56924E33569 for ; Mon, 9 Oct 2017 15:36:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 C57D27E558 for ; Mon, 9 Oct 2017 15:36:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id 72so9882766itl.5 for ; Mon, 09 Oct 2017 08:36:31 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=028tHGk2wY4JK/iTU3/wG0jynfo0rUCYMMKbZV3AiZY=; b=TbzvLETBIk/VbMVWD3g72w5wf5+sLyjGdBWS3GYUpNaR0u1nlVHaxleV5Fk53tSbCi XOgsJtAmb9ErqeCDYVSZXx+a5fEl1PCBKTTCx1UVEqXGXabNU7/CxmYl7lqJe8nzvFpD OW3tRAy042+LiHVak56YpKbbFYTNxaWOO19oFOBYmlJmtD3JUiowJzKcrGIIQzlVKj/D 5KN+Y6xepVU3Hf58WOkX7eDq+J82uYsFpaytcf+FjgbEUQHoF1ES7KmImGoaoOklXPap 9qnyxzbqcrkzOpei3mRPGV/4DyQZk0kVzyXyrlPC0qffsB4B0C349I/Yu71FW7hit5P0 +Y0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=028tHGk2wY4JK/iTU3/wG0jynfo0rUCYMMKbZV3AiZY=; b=WmylnZ+PAQ2sKa1ldn7XNE37bmGHrJ+eEQYizeNetODyAMHyZBMBRuEpJvxy1XrX3J AqDx6zmRZAlF5oE7DngkyExXGYxXowKvcvy5X11A9GtlnPaDIYQrQWN4NKnqENJrpYJV 36JMFvCILvLCxFJVwZINpiKPc7OTACgqx5pmb/OI7/Nq1d7vATZJi/5YJ1iEdaX3uI9w uilyQuq2t9AWvTiGWPqsHz3coXmU7fTJg2ZHKMa9zSRsTCzP+eR2SKUP8jmHZ8WdfHGr JobW0BVt/DExRRzY+rn7hYy7rfuup8dQVyNyrxiNVPo1RwBG/H5Zvv/1MQ0etUhBuZui LkcA== X-Gm-Message-State: AMCzsaUYS6hfc7E0bDl9tmg0PjmY6kXExWXE5ReJFT0MOVIv1qxuC8Qc Fz+VjgQFhyIT/XFNmA0Wb1vZoxzkaF10rn4MuV/LAg== X-Google-Smtp-Source: AOwi7QCDwvfQBSe8qwBNln76KbEb2sVjwx/9hyNu2as3rxIvy4CDpCqz+5WAoJSlhEUFWuN4ETr30aR/FfThrHA/oX0= X-Received: by 10.36.203.3 with SMTP id u3mr13173194itg.136.1507563391097; Mon, 09 Oct 2017 08:36:31 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 08:36:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: References: From: Warner Losh Date: Mon, 9 Oct 2017 09:36:30 -0600 X-Google-Sender-Auth: xmfE9xzR7zHvTiS2qLmQZg68omI Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Ed Maste Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 15:36:33 -0000 On Mon, Oct 9, 2017 at 4:54 AM, Ed Maste wrote: > On 9 October 2017 at 01:45, Warner Losh wrote: > > > > Any objections to my moving forward with this [moving libstand to > sys/boot/libsa] > > Go ahead, IMO. Note that we already have sys/boot/libstand32 that > we'll want to include in the cleanup. > And don't forget sys/boot/userboot/libstand too :) Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 15:57:32 2017 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 EFF33E34251 for ; Mon, 9 Oct 2017 15:57:31 +0000 (UTC) (envelope-from dim@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 C835183403 for ; Mon, 9 Oct 2017 15:57:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C27C5E34250; Mon, 9 Oct 2017 15:57:31 +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 C20ECE3424E for ; Mon, 9 Oct 2017 15:57:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CDB5833F9 for ; Mon, 9 Oct 2017 15:57:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2B1CB3BC2F; Mon, 9 Oct 2017 17:57:22 +0200 (CEST) From: Dimitry Andric Message-Id: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_CEF0678D-9534-4F60-B891-ED46724F408D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Date: Mon, 9 Oct 2017 17:57:10 +0200 In-Reply-To: Cc: "freebsd-arch@freebsd.org" To: Warner Losh References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 15:57:32 -0000 --Apple-Mail=_CEF0678D-9534-4F60-B891-ED46724F408D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Oct 2017, at 07:45, Warner Losh wrote: >=20 > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These = are > really parts of the boot loader with an unstable API and shouldn't be > installed into the system. It's really a private library to the boot = loader. Though I completely agree with this, I am still interested in the historical reasons for separating out this library for general userland consumption. Were there any other parts of world that happened to use libstand? -Dimitry --Apple-Mail=_CEF0678D-9534-4F60-B891-ED46724F408D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWducVgAKCRCwXqMKLiCW ox2pAJ9Iedi/kIROJzc1jKxcOY5VVBOz8wCg+VUaJv4QR/rec1fJciep8WUNSpQ= =Iysb -----END PGP SIGNATURE----- --Apple-Mail=_CEF0678D-9534-4F60-B891-ED46724F408D-- From owner-freebsd-arch@freebsd.org Mon Oct 9 16:04:58 2017 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 F1414E3484B for ; Mon, 9 Oct 2017 16:04:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C07311609 for ; Mon, 9 Oct 2017 16:04:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BC29DE3484A; Mon, 9 Oct 2017 16:04:58 +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 B8E2BE34849 for ; Mon, 9 Oct 2017 16:04:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 90C2B1602 for ; Mon, 9 Oct 2017 16:04:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9801a7ad-ad0b-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 9801a7ad-ad0b-11e7-a938-4f970e858fdb; Mon, 09 Oct 2017 16:04:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v99G4jrE001492; Mon, 9 Oct 2017 10:04:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507565085.77958.3.camel@freebsd.org> Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot From: Ian Lepore To: Dimitry Andric , Warner Losh Cc: "freebsd-arch@freebsd.org" Date: Mon, 09 Oct 2017 10:04:45 -0600 In-Reply-To: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> References: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:04:59 -0000 On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are > > really parts of the boot loader with an unstable API and shouldn't be > > installed into the system. It's really a private library to the boot loader. > Though I completely agree with this, I am still interested in the > historical reasons for separating out this library for general userland > consumption.  Were there any other parts of world that happened to use > libstand? > > -Dimitry > There are out-of-tree users of libstand.  Perhaps not many, but a couple times after doing something to libstand I've received emails from people that thanked me for the enhancement and mentioned some non- loader(8) use of the lib in passing.  (Unfortunately, I can't find any of those mails now, they were from 2-3 years ago.) -- Ian From owner-freebsd-arch@freebsd.org Mon Oct 9 16:06:26 2017 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 D807BE34921 for ; Mon, 9 Oct 2017 16:06:26 +0000 (UTC) (envelope-from wlosh@bsdimp.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 4C6C81B68 for ; Mon, 9 Oct 2017 16:06:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3C01FE3491E; Mon, 9 Oct 2017 16:06:26 +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 34E18E3491D for ; Mon, 9 Oct 2017 16:06:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 7E59A1B4D for ; Mon, 9 Oct 2017 16:06:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id m16so13131449iod.1 for ; Mon, 09 Oct 2017 09:06:25 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=EpLK2fv73b2sZsndY8e8fAL7M3i9E2q72HKcVCgSImI=; b=ja2+XvWDwrOzBtgsuTXLXmv9CR912dCYPIpThqstxC/H85cYGfazCzPObwEobuKn3B G/zURW/9yMgvRpzWMMbhikHW7rZrxY34XPazXRyKAWFfqkaYVeWPR7oOh+fW1zkUL+Bp hfauRwYzECjm0ElGjxX/gXN/VHAieJNkJOMxVIdEaG6pAe3pD6OF1pDXo+paIOQXXS9d 7XyZJW9JtVFZTpM+FoscGrl5bXVyudp1IaUlWv9U/QkUmFSztgoZon9RvzPo1z5P92+l gYbjKXXJde/Gj1/pCmEoWUFMTcFPLJ3h8iOVtOM18igVfUqIYqobMxaBjVoaztx0S8Nu 9uRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EpLK2fv73b2sZsndY8e8fAL7M3i9E2q72HKcVCgSImI=; b=WANQKJbzieJo9iA2ZCkwJqoGVYs6/irNvclOWlHh+reZ7gFPZp0zrZPEBN8AB/wbXf c9jk1BbKw2sPllJWcJmGNGmuLlrX1WZTE/8s0WdnNjv/o1UlAE/94KZk79GLAAI3NlxH dPESoO/OS5R8ka0w7+bKGZiHw2ADeVTnod9NfME3hyeTqxV585ssB/1LRQAYEWhVpPVA QftQGGUx5rxGYYQ/funUrST2I5fUJtWQt6Fo/G+KG0t2rbbz4WvkRFWZz5j8ul2VyWB3 GZMjgztIRkzllH2UsxostBcSr6E0Ul3hdBThzDXVOTwlMwDw2Ftxde6zUGryxlR9K9gb rffA== X-Gm-Message-State: AMCzsaWVQ5P47FyJGiK2q+tgdU3bWVhXA9MRyMV+vkY0M7xMrmFkBGlo mZfO2lcD/9pYurecOLJswlD1a0j+XkvkhTyoijfNLQ== X-Google-Smtp-Source: AOwi7QB1EU6/OBKojpn7mrz/msBGmO4WixgL4G5PHjr57JLmAnSY/KTxpjit0umO5Phf2DdRkh4WjaRKCWlhSZXDW4s= X-Received: by 10.107.68.6 with SMTP id r6mr14833738ioa.282.1507565184580; Mon, 09 Oct 2017 09:06:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 09:06:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> References: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> From: Warner Losh Date: Mon, 9 Oct 2017 10:06:24 -0600 X-Google-Sender-Auth: kie_YbQqXR-sThxINC5ePOGZGL8 Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Dimitry Andric Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:06:27 -0000 On Mon, Oct 9, 2017 at 9:57 AM, Dimitry Andric wrote: > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are > > really parts of the boot loader with an unstable API and shouldn't be > > installed into the system. It's really a private library to the boot > loader. > > Though I completely agree with this, I am still interested in the > historical reasons for separating out this library for general userland > consumption. Were there any other parts of world that happened to use > libstand? > Nope. As far as I can tell, it's never been used in FreeBSD. Historically, it was use for the stand-alone programs used to bootstrap the system (eg to copy the miniroot file from tape to disk swap area for the install and disk formatting and partitioning). Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 16:09:44 2017 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 944A3E34CAC for ; Mon, 9 Oct 2017 16:09:44 +0000 (UTC) (envelope-from wlosh@bsdimp.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 CD2D02D0F for ; Mon, 9 Oct 2017 16:09:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id AECC5E34C9F; Mon, 9 Oct 2017 16:09:43 +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 AE471E34C9E for ; Mon, 9 Oct 2017 16:09:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 CC7662CF9 for ; Mon, 9 Oct 2017 16:09:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id g18so13503005itg.5 for ; Mon, 09 Oct 2017 09:09:42 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=AfrMSkp0Ni84Ti8O1RgU2OcWQUE3n7tzcZU8aPeqaFI=; b=RxXFfd+L35j6yaSblzO6jmll5EIL52jxZ48+a7vyqbOGCius3RLlKNTAHTGLtINVKu Kqp8cpXKtM1+Xq5UNhhtLVEE0OrI9ULD88s/NKG6WutRDbMNxanSTZ7ro2CO/Ngv03pE SWENaddBaEuMLybTC88Qfgc1kusR0U36TfRCjR1+LP1iNCI1b/xuh99kjTKEe3mODQHe hVk5WQOeOFSBMTyOlQ8QbJa1zYMfBzBIfpb49qvVHZO/Je94RP0WYQWPDzb/C6O2ylIP DfR1cq8Sk1HJ5MoVlmBqwncODzKjUdJEqnzzLWqnCdoluBmwbxRNFtcXzD0iHN1hMS7t QQeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AfrMSkp0Ni84Ti8O1RgU2OcWQUE3n7tzcZU8aPeqaFI=; b=DLN4UfH0XqppCtadnljHJ3uweYke3HZ6U48DkokO94MQ3LmVNKEzyAvyCmc1mYluhF QfAsdranoGfbOmtNFXOfYuEWdEflruOAapKKsv/2FkJBaP2qDz9FyV4QGJEvwwct0e4/ CirNhk3fz527Gijbmkz+IxQcl5aF4zZkVHDNSLQj9f8VBmZ+UTmC3J0Q4gbb2E7eF/7q 010ZG6a3CFTnhY9v7btCBjBGJmy5tL0nJEmkvtoWcuq7CMKWa6msMZFRgwdhsc39K2tA qu4aVk9AsTklJDZJ/sVpzOABOp2raicXz3ghWpQF4XuPgEOY8KvdbekTbEYm4yUrAX75 zzig== X-Gm-Message-State: AMCzsaXUzMn1SkT/j4cgl0aqrH6gPxnlMw0Vcm6eE8prTaQppYPmR6CR wJgaOEtxVN/hEixiVDGikxof5hp+2fUYaltrLmSE2g== X-Google-Smtp-Source: AOwi7QDNbbQN80ziFIXI0zaed97uoL/zFEqDkW38Li8TdtEkygi50DKMLmveEGTJTa1XpXS2eT4m24wPi7ijPPjclqY= X-Received: by 10.36.203.3 with SMTP id u3mr13304316itg.136.1507565382101; Mon, 09 Oct 2017 09:09:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 09:09:41 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: <1507565085.77958.3.camel@freebsd.org> References: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> <1507565085.77958.3.camel@freebsd.org> From: Warner Losh Date: Mon, 9 Oct 2017 10:09:41 -0600 X-Google-Sender-Auth: S9KRzEKcEMqLJ2Se4KltjAD00As Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Ian Lepore Cc: Dimitry Andric , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:09:44 -0000 On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore wrote: > On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: > > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > > > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These > are > > > really parts of the boot loader with an unstable API and shouldn't be > > > installed into the system. It's really a private library to the boot > loader. > > Though I completely agree with this, I am still interested in the > > historical reasons for separating out this library for general userland > > consumption. Were there any other parts of world that happened to use > > libstand? > > > > -Dimitry > > > > There are out-of-tree users of libstand. Perhaps not many, but a > couple times after doing something to libstand I've received emails > from people that thanked me for the enhancement and mentioned some non- > loader(8) use of the lib in passing. (Unfortunately, I can't find any > of those mails now, they were from 2-3 years ago.) > They can email me and I'll help them convert over... :) Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 16:16:08 2017 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 D9A3BE3507B for ; Mon, 9 Oct 2017 16:16:08 +0000 (UTC) (envelope-from ian@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 27EA063668 for ; Mon, 9 Oct 2017 16:16:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0640CE35072; Mon, 9 Oct 2017 16:16:08 +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 05286E35070 for ; Mon, 9 Oct 2017 16:16:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 302E56365C for ; Mon, 9 Oct 2017 16:16:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 24eaa667-ad0d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 24eaa667-ad0d-11e7-a893-25625093991c; Mon, 09 Oct 2017 16:16:03 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v99GFxQg001530; Mon, 9 Oct 2017 10:15:59 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507565759.77958.7.camel@freebsd.org> Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot From: Ian Lepore To: Warner Losh Cc: "freebsd-arch@freebsd.org" , Dimitry Andric Date: Mon, 09 Oct 2017 10:15:59 -0600 In-Reply-To: References: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> <1507565085.77958.3.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:16:09 -0000 On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote: > On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore wrote: > > > > > On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: > > > > > > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > > > > > > > > > > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These > > are > > > > > > > > > > > really parts of the boot loader with an unstable API and shouldn't be > > > > installed into the system. It's really a private library to the boot > > loader. > > > > > > Though I completely agree with this, I am still interested in the > > > historical reasons for separating out this library for general userland > > > consumption.  Were there any other parts of world that happened to use > > > libstand? > > > > > > -Dimitry > > > > > There are out-of-tree users of libstand.  Perhaps not many, but a > > couple times after doing something to libstand I've received emails > > from people that thanked me for the enhancement and mentioned some non- > > loader(8) use of the lib in passing.  (Unfortunately, I can't find any > > of those mails now, they were from 2-3 years ago.) > > > They can email me and I'll help them convert over... :) > > Warner Actually, I got distracted, then came back and hit Send too soon.  I meant to ask "Will the library still be accessible to out of tree users?", so that adjusting to the change will amount to fixing some build breakage to adjust to a new location? -- Ian From owner-freebsd-arch@freebsd.org Mon Oct 9 16:21:56 2017 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 F1580E3544A for ; Mon, 9 Oct 2017 16:21:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2404765035 for ; Mon, 9 Oct 2017 16:21:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1835EE35449; Mon, 9 Oct 2017 16:21:56 +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 17C71E35448 for ; Mon, 9 Oct 2017 16:21:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 6FBCA6502F for ; Mon, 9 Oct 2017 16:21:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id g18so13544779itg.5 for ; Mon, 09 Oct 2017 09:21:55 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=mByYs4f2AfB4s/hafJVrIKvtPb4BBgQ4WSDxAlDhX0I=; b=yaRsjYsJuMet861UNyRrnh2d9h91H/5xO8d0Emuo6Dd2jxkfeP17yH8OLVXy2xUgWg ENQfzM6pfLwWnynzqZPTzZXO/hE2y3pDEiBDEe7WUQ2pqNVSFirfGoIEV7yFOTZr0wpI ggnV3qZH3iqOyIIQBDU4olMOI7PpBD8TdZK45qQf26/K8J4tkZSLcJmbQruqm/Ty4UPE eQJNX8i9sQJqpuXIG71vYt3c5ikSaKyWFXJfVOgpYX+SNwCGohWE0r9828ABuJOWu9P7 V2HHLeSKnQxmAzqluQcKKmDobuIGlqvGldMnd+GGP5IRhRrypC5sw0UqXzZjFFyykhus APwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mByYs4f2AfB4s/hafJVrIKvtPb4BBgQ4WSDxAlDhX0I=; b=NdBL2ekKRnbwo+HCcEwRVYUVfdvAIxa0id3Y0Ibq04VaRyMYmb+w2nQM+3PSHm/il5 hMybcmX9T5b7UWzsx68PKG9bIoWqfd8Clx+Hr5eDSwVUQw5kyb+DL/oUg7tzbj+tin8U 3cCsv4JZ66newZl8pv7VhKUQKAAdLieVnUV878mVjkNPzOY927LoBgBNOX74TmlFo5T/ zwValTaAtru2gKTlvjA9zRKguINXOdZ/09rZOhm2tRW3+x3S4B5dki4WVjUBiafyjPgh kp7YBM7g8yPuBJNy+SMlqj2pwQ8EwC0UI4DzAuAwSgiZ+SN0xp0Zk6r12XrHw2HKlGb3 KXZg== X-Gm-Message-State: AMCzsaUde8+/KC3uK2Tf5TuTotDxkNP1ihIqCOwdKRsdBIMI0YBVNtxl 4zdwTHWSf4pKTmycG5NC4vIfI1wCah4KPGX9jdRGjA== X-Google-Smtp-Source: AOwi7QA3wiUEntPDhQsnjdkSN6Xf43RtjeU8XjoWYvlV175P5tkfCQJobsjSWaq0pWHPpVY08rHgdGwqL7X/Dtdwjlo= X-Received: by 10.36.201.4 with SMTP id h4mr14868172itg.26.1507566114583; Mon, 09 Oct 2017 09:21:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 09:21:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: <1507565759.77958.7.camel@freebsd.org> References: <23C4A573-05A7-4D76-9179-19169ECAB570@FreeBSD.org> <1507565085.77958.3.camel@freebsd.org> <1507565759.77958.7.camel@freebsd.org> From: Warner Losh Date: Mon, 9 Oct 2017 10:21:53 -0600 X-Google-Sender-Auth: YiYqWAz9v3oqvQHFoa7Fk5yl7A4 Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Ian Lepore Cc: "freebsd-arch@freebsd.org" , Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:21:57 -0000 On Mon, Oct 9, 2017 at 10:15 AM, Ian Lepore wrote: > On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote: > > On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore wrote: > > > > > > > > On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: > > > > > > > > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. > These > > > are > > > > > > > > > > > > > > really parts of the boot loader with an unstable API and shouldn't > be > > > > > installed into the system. It's really a private library to the > boot > > > loader. > > > > > > > > Though I completely agree with this, I am still interested in the > > > > historical reasons for separating out this library for general > userland > > > > consumption. Were there any other parts of world that happened to > use > > > > libstand? > > > > > > > > -Dimitry > > > > > > > There are out-of-tree users of libstand. Perhaps not many, but a > > > couple times after doing something to libstand I've received emails > > > from people that thanked me for the enhancement and mentioned some non- > > > loader(8) use of the lib in passing. (Unfortunately, I can't find any > > > of those mails now, they were from 2-3 years ago.) > > > > > They can email me and I'll help them convert over... :) > > > > Warner > > Actually, I got distracted, then came back and hit Send too soon. I > meant to ask "Will the library still be accessible to out of tree > users?", so that adjusting to the change will amount to fixing some > build breakage to adjust to a new location? > The proposal is to take it 100% internal and officially not support its use outside the loader. It's open source, so if you really want to use it, you can with some effort. If there's one or two people, they can adjust. If there's lots, then I can revisit the proposal. It would help to know who they were and what, exactly, they used it for. Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 16:32:51 2017 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 45A03E3596C for ; Mon, 9 Oct 2017 16:32:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 7A81467771; Mon, 9 Oct 2017 16:32:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v99GWbcd078854; Mon, 9 Oct 2017 09:32:37 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v99GWaUK078853; Mon, 9 Oct 2017 09:32:36 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201710091632.v99GWaUK078853@pdx.rh.CN85.dnsmgr.net> Subject: Re: rtools were deemed almost unused 15 years ago... In-Reply-To: To: Jeremie Le Hen Date: Mon, 9 Oct 2017 09:32:36 -0700 (PDT) CC: "Julian H. Stacey" , freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:32:51 -0000 > On Wed, Oct 4, 2017 at 12:35 PM, Julian H. Stacey wrote: > >> Have you picked up the recent changes to the code in your port? > >> > >> ----- Jeremie Le Hen's Original Message ----- > >> > I've slacked a bit but here we are: > >> > https://reviews.freebsd.org/D12573 > >> >=20 > >> > On Sat, Jul 1, 2017 at 12:08 PM, Jeremie Le Hen wrote: > >> > > On Sat, Jun 24, 2017 at 10:29 PM, Jeremie Le Hen wrot= > >> e: > >> > >> So the first step was to create a port with FreeBSD rcmds, here we > >> > >> are! But I need some eyes to vet it: > >> > >> https://reviews.freebsd.org/D11345 > >> > > > >> > > The port has been submitted and RCMDS are disabled by default from the > >> > > base system. > >> > > > >> > > See you in a month for the removal! > > > > > > NO ! It's maddening, code vandals periodicaly wanting to delete working code > > & pontificating what others globaly should be denied, & forced to do & not do. > > > > One example why FreeBSD should not delete rlogin & telnet etc > > 3 days ago, a host with broken sshd (bad shared libs version > > number), was rescued by ssh to trusted parent host, then rlogin > > from that parent host to underlying jail. > > > > 3rd party code vandals are Not fit to decide what code should be > > denied globaly in other peoples' environments. By all means leave off by > > default in /etc/inetd.conf as now, but do Not Vandal Delete ! > > > > BSD is not Microsoft replete with masses of clueless users. BSD > > includes skilled users who may wish to make their own risk assessments, > > without interference. > > I know I shouldn't be replying to this message but I will do it > nonetheless, once and for all. > > You can install net/bsdrcmds and be happy again. I've even modified > inetd.conf(5) to use the path of the port's binary. You added yet another wrong assumption that ports must live in /usr/local to the base system, something that was irradicated 20 years ago and has slowly crept back in over the decades. > > This was announced and approved. Disabling it from inetd.conf(5) > wouldn't have solved the setuid issue. I suggest you re-read the > original email explaining the proposal: > https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html > > It surely displeases a small percentage of users but this reduces the > attack surface for 100% of them. Additionally, it reduces the FreeBSD > project maintenance cost > > -- Jeremie > > > > > > > Cheers, > > Julian > > -- > > Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich > > Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. > > http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU. > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > -- > Jeremie Le Hen > jlh@FreeBSD.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Mon Oct 9 17:47:18 2017 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 44C83E3786C for ; Mon, 9 Oct 2017 17:47:18 +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 2E309742A9 for ; Mon, 9 Oct 2017 17:47:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v99HlDNn009931 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Oct 2017 10:47:14 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: Warner Losh Cc: "freebsd-arch@freebsd.org" References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Nathan Whitehorn Message-ID: Date: Mon, 9 Oct 2017 10:47:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVaSzirnscWxFCVzcZoGXsoqTt/mG3wzUf7DGEC/F/Na6i4NJ0CHPXwl6vb10KdVTDbVwz96OW1CDrilHW5Ty++KkYytsumXIlM= X-Sonic-ID: C;vCRB4hmt5xGL2YKfRUfeDw== M;TLeH4hmt5xGL2YKfRUfeDw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 17:47:18 -0000 On 10/08/17 22:26, Warner Losh wrote: > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn > > wrote: > > > > On 10/06/17 00:20, Baptiste Daroussin wrote: > > On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > > On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > > I'd like to start a conversation about the viability > of making C++11 a hard > requirement for bootstrapping FreeBSD and setting a > specific deadline for > doing so. > > This discussion is motivated by an ask from the > jemalloc folks to use a > limited subset of C++11 inside of malloc in such a way > that is C safe (so > the C programs wouldn't bloat with a C++ runtime). > That's an ongoing > discussion in another forum, and isn't appropriate for > this thread because > this has become a frequent request (but if you have > opinions, please find > the thread in current@ about it). I don't know the > timeline of their plans > to do this. > > I'd like to take the rather vague plans we've had > "before 12" and create a > timeline for removal of gcc 4.2 coupled with a > requirement for support in > clang or a working external toolchain. This > requirement would be coupled > with the requirement that the external toolchain > support C++11 constructs. > > I'd like to propose we do this 12/31/17. Any > architectures that can't meet > this timeline will be disconnected from universe at > that time and deleted > 3/31/18. > > It's my belief that i386, amd64, arm, aarch64, powerpc > and powerpc64 are > ready for this change and mips* would be ready for > this change with an > external clang toolchain. I'm unsure of riscv and > sparc64, but suspect that > a newer version of gcc as an external toolchain could > work. > > In-tree clang 5.0 for MIPS mostly works (modulo some small > patches). However, > it requires external ld.bfd. I know that there ld.lld can > link a working > mips64 world with some patches (notably the multigot > patch). mips works fine > with external GCC. riscv is already using external GCC > that is C++11-capable. > > The problem with external GCC is that you can cross-build > a world + kernel > just fine and get a working system via > CROSS_TOOLCHAIN=foo-gcc. However, > that system has no viable '/usr/bin/cc' once GCC 4.2 is > removed. bapt@ > started on ports to cross-build binutils and gcc packages > via the base/* > ports, but those are not yet finished / fully tested. I > don't think anyone > has thought about how release builds will work either with > only an external > toolchain available. (I'm pretty sure sparc64 has booted > fine with > external GCC, it's just in the same boat as mips with > regard to /usr/bin/cc.) > > Actually I did test those and they were working (tested in > qemu) they were > working fine. I have given up working on them due to the lack > of interested by > the community (by interest I mean people really testing, > working on it, not just > saying "hey nice sounds cool"). > > As for the boot when I initially worked on external toolchain > sparc64 was my > guinea pig and so yes it worked an booted just fine. > > > So far as I know, we never solved any of the infrastructural > problems associated with this concept: > 1. Providing built releases with a /usr/bin/cc > 2. Coversioning base and in-ports toolchain, including ensuring > commit atomicity between toolchains and libc > 3. Adding a dependency on ports for src, including out-of-tree > code that has to be fetched from external servers > 4. Getting make universe to do the right thing > > We really need to solve those. If we go the external toolchain > route, which it is not clear to me is the best option, #2 and #1 > are quite complex problems. I think that, frankly, a deadline in > two months to solve this set of political problems we have had for > two years is probably crazy, but maybe making the status quo > unsustainable will finally force progress. > > > External toolchains have been in flight for 5 or more years now. It's > time they land. Though the requirements for them have never included > cross-threading between /usr/src and /usr/ports like you suggest > above, and those sorts of things won't be sorted by my deadlines > (which are closer to 3 months). Nor, imho, should they. Well, sure. But the fact remains that we cannot build usable systems with external toolchains right now. Those are real problems that need to be solved somehow. Let's focus on #1, the largest if not the only major problem. If I build, say, a ppc64 system with an external toolchain right now, it boots and runs fine. But the system is completely unusable since: - There are no binary packages built for PPC64, because of project policy preventing the use of native build systems - You cannot cross-compile packages for PPC64, because of limitations in QEMU - There is no compiler installed in the base system, so you cannot install any software from source code - You cannot build the compiler from source, because you don't have one to bootstrap from and can't get one pre-built because of the no-packages problem. We can't ship systems like this -- how is anyone expected to be able to use them? These are easy to fix -- for example, here are three possibilities -- but solutions been held up for *years* by project policy: 1. Allow Tier-2 packages to be built on native hardware without as much centralized control, letting pkg install of the toolchain work. This fixes ppc64, but maybe not embedded systems. 2. Have external-toolchain builds cross-build (or native-build) and pre-install a standard compiler package from ports during make buildworld, which keeps the user experience of current tier-2 and later tier-1 systems. 3. Include a newer compiler fully in the tree or in some nearby repository, which does the same. If we break any of these policy impasses by the deadline, I am 100% for dropping GCC 4.2. But we *have* to do something. Just axing code while preventing a meaningful replacement isn't a solution. > Also, are there any directions for how to build a toolchain from > the base ports? I haven't been able to figure it out -- the README > starts with "pkg install", but that doesn't get me very far on > platforms without binary packages, which are the ones this is > meant to target. > > > External toolchains are by definition external. Not part of the tree > nor integrated into the tree. How you get them depends on the external > toolchain and is unspecified. You get a lower level of integration > than you do with in-tree toolchains, not the same level with > reach-overs into some external repo. I think you missed the point. I was asking how to build the port to test it -- it doesn't build at present and I can't figure out how to make an external toolchain via the "base" ports (the other toolchains in ports work fine). -Nathan > Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 18:32:19 2017 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 20E5FE388AA for ; Mon, 9 Oct 2017 18:32:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 C1AEF75F93 for ; Mon, 9 Oct 2017 18:32:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id g18so13970160itg.5 for ; Mon, 09 Oct 2017 11:32:18 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=QsiUylNQ5K9t8NxvqiZd6taMFIFIqIRwTTV07+P7bCA=; b=Lcy48pmJZU/yYV2rQpM+MU1S7gWNGaVmOcK4q5qoucWs8O7OPDozOny3yCS4oWjXM+ H5J7tK+zZUeVpUGcjoD4rZUxRhDl8xVYgFlq1JqwLyKjYp7zbWbS4Xoui+xlA1+YqMSA 4/Fngf0rR1EygAsHFiPlpSVlOBKsMif13dLL8UtWPGVS1OiBmD87Yjtv2dMln2UbZjQ1 MWfNevjo7cnHD8+Mjael0He1q1nb28xe5qqJmIx1ovz2PI/TB5bUp5yNZc3Q0IoOPMWc 58oQlUmdi8m+s7ZadTFg9KWZH5Rw3KFsCJKJe2QZmHwCNKtXQHXoNDJPdGIbegYD5mVY yTug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QsiUylNQ5K9t8NxvqiZd6taMFIFIqIRwTTV07+P7bCA=; b=A1D6I4Usx0WAQs47Jr+BO2Oh5gLWXs+9CUW7Wb/uSgxHeHn7MwZ4oGh8FF2/yDA+Jz A95RD71PK2EDm9QqcBnvpOgTa2G9M3p+RLAR6msTEVaiBRxD/1yI9Wf7m9A17ogPXj/d eNJiMRA2K/yUITMr07ZFnEd7xewV1HpjEWnaqFAhfbyf0/rvGlz7lxTrPX0LCU/HTsHY QOf42rsqdgT8mNpwcIEUQ/NIevAnySCMmlQ+w1MwPVyb+MKFHcqiu8Ye2oNNPdajT0Zp 4jktVEvqW8Jala+3+x748kpVNjJ8zmXnK46OQmDUXwnXvNS4iLoUzVpoiN8WT0AeTKUG mcSg== X-Gm-Message-State: AMCzsaXDOo56I2XWTAgvFWD5sWSKERGXTkgPtWaveD+WyE0jjVrF+GNS MJCFDRlMaUZQ6rfIjOkMIEK9+pRUilrqFbB70RzheQ== X-Google-Smtp-Source: AOwi7QAL2m5shO7lVyaVYNhsoIeV/83R9CP5FNdeZ5D48ExlHIPaDvUjPttkoTH+zdvG94Srh7zlp3FzI1ZErQ9eos8= X-Received: by 10.36.69.163 with SMTP id c35mr14089526itd.63.1507573937927; Mon, 09 Oct 2017 11:32:17 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 11:32:17 -0700 (PDT) X-Originating-IP: [65.151.16.249] Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 11:32:17 -0700 (PDT) In-Reply-To: References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Warner Losh Date: Mon, 9 Oct 2017 12:32:17 -0600 X-Google-Sender-Auth: 4s6hmbTXLTc2jBgBMzsByX2B4VM Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Nathan Whitehorn Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 18:32:19 -0000 On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" wrote: On 10/08/17 22:26, Warner Losh wrote: On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn wrote: > > > On 10/06/17 00:20, Baptiste Daroussin wrote: > >> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >> >>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>> >>>> I'd like to start a conversation about the viability of making C++11 a >>>> hard >>>> requirement for bootstrapping FreeBSD and setting a specific deadline >>>> for >>>> doing so. >>>> >>>> This discussion is motivated by an ask from the jemalloc folks to use a >>>> limited subset of C++11 inside of malloc in such a way that is C safe >>>> (so >>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>>> discussion in another forum, and isn't appropriate for this thread >>>> because >>>> this has become a frequent request (but if you have opinions, please >>>> find >>>> the thread in current@ about it). I don't know the timeline of their >>>> plans >>>> to do this. >>>> >>>> I'd like to take the rather vague plans we've had "before 12" and >>>> create a >>>> timeline for removal of gcc 4.2 coupled with a requirement for support >>>> in >>>> clang or a working external toolchain. This requirement would be coupled >>>> with the requirement that the external toolchain support C++11 >>>> constructs. >>>> >>>> I'd like to propose we do this 12/31/17. Any architectures that can't >>>> meet >>>> this timeline will be disconnected from universe at that time and >>>> deleted >>>> 3/31/18. >>>> >>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are >>>> ready for this change and mips* would be ready for this change with an >>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect >>>> that >>>> a newer version of gcc as an external toolchain could work. >>>> >>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). >>> However, >>> it requires external ld.bfd. I know that there ld.lld can link a working >>> mips64 world with some patches (notably the multigot patch). mips works >>> fine >>> with external GCC. riscv is already using external GCC that is >>> C++11-capable. >>> >>> The problem with external GCC is that you can cross-build a world + >>> kernel >>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, >>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >>> started on ports to cross-build binutils and gcc packages via the base/* >>> ports, but those are not yet finished / fully tested. I don't think >>> anyone >>> has thought about how release builds will work either with only an >>> external >>> toolchain available. (I'm pretty sure sparc64 has booted fine with >>> external GCC, it's just in the same boat as mips with regard to >>> /usr/bin/cc.) >>> >> Actually I did test those and they were working (tested in qemu) they were >> working fine. I have given up working on them due to the lack of >> interested by >> the community (by interest I mean people really testing, working on it, >> not just >> saying "hey nice sounds cool"). >> >> As for the boot when I initially worked on external toolchain sparc64 was >> my >> guinea pig and so yes it worked an booted just fine. >> > > So far as I know, we never solved any of the infrastructural problems > associated with this concept: > 1. Providing built releases with a /usr/bin/cc > 2. Coversioning base and in-ports toolchain, including ensuring commit > atomicity between toolchains and libc > 3. Adding a dependency on ports for src, including out-of-tree code that > has to be fetched from external servers > 4. Getting make universe to do the right thing > > We really need to solve those. If we go the external toolchain route, > which it is not clear to me is the best option, #2 and #1 are quite complex > problems. I think that, frankly, a deadline in two months to solve this set > of political problems we have had for two years is probably crazy, but > maybe making the status quo unsustainable will finally force progress. > External toolchains have been in flight for 5 or more years now. It's time they land. Though the requirements for them have never included cross-threading between /usr/src and /usr/ports like you suggest above, and those sorts of things won't be sorted by my deadlines (which are closer to 3 months). Nor, imho, should they. Well, sure. But the fact remains that we cannot build usable systems with external toolchains right now. Those are real problems that need to be solved somehow. Sure we can. I've built a bootable i386 system with gcc 6. It is a solved problem. Let's focus on #1, the largest if not the only major problem. If I build, say, a ppc64 system with an external toolchain right now, it boots and runs fine. But the system is completely unusable since: - There are no binary packages built for PPC64, because of project policy preventing the use of native build systems System is still usable w/o packages. People can still fire up custom poudrier repos. We could also change project policy. This is is a specific wrinkle for powerpc64 it seems. - You cannot cross-compile packages for PPC64, because of limitations in QEMU Then we should fix those, like we did for arm and MIPS. - There is no compiler installed in the base system, so you cannot install any software from source code You can install it as a package. - You cannot build the compiler from source, because you don't have one to bootstrap from and can't get one pre-built because of the no-packages problem. If you fix the other problems, this is solved. We can't ship systems like this -- how is anyone expected to be able to use them? Most systems don't build software, so there are plenty of uses. These are easy to fix -- for example, here are three possibilities -- but solutions been held up for *years* by project policy: 1. Allow Tier-2 packages to be built on native hardware without as much centralized control, letting pkg install of the toolchain work. This fixes ppc64, but maybe not embedded systems. If we can't build in QEMU then sure. It doesn't matter where the binaries come from, so long as they work. 2. Have external-toolchain builds cross-build (or native-build) and pre-install a standard compiler package from ports during make buildworld, which keeps the user experience of current tier-2 and later tier-1 systems. No need for this to be during buildworld. I see no benefit from that. You can install it after installworld either native or to a destdir. 3. Include a newer compiler fully in the tree or in some nearby repository, which does the same. Yea, that's also possible. But then it isn't an external toolchain. If we break any of these policy impasses by the deadline, I am 100% for dropping GCC 4.2. But we *have* to do something. Just axing code while preventing a meaningful replacement isn't a solution. We have sometthing that works today with a few warts. We shouldn't let the warts get in the way. I'm happy to delay if there are specific items that have a definitive timeline, but wanting 100% full integration from external toolchain with full packages isn't a gating factor here. Besides, I thought powerpc64 just worked with clang... Warner Also, are there any directions for how to build a toolchain from the base > ports? I haven't been able to figure it out -- the README starts with "pkg > install", but that doesn't get me very far on platforms without binary > packages, which are the ones this is meant to target. External toolchains are by definition external. Not part of the tree nor integrated into the tree. How you get them depends on the external toolchain and is unspecified. You get a lower level of integration than you do with in-tree toolchains, not the same level with reach-overs into some external repo. I think you missed the point. I was asking how to build the port to test it -- it doesn't build at present and I can't figure out how to make an external toolchain via the "base" ports (the other toolchains in ports work fine). -Nathan Warner From owner-freebsd-arch@freebsd.org Mon Oct 9 19:14:37 2017 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 F08E4E39837 for ; Mon, 9 Oct 2017 19:14:37 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C55CF77B93 for ; Mon, 9 Oct 2017 19:14:37 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 1dVUetdMn8LPZ1dVVeFEct; Mon, 09 Oct 2017 13:14:30 -0600 X-Authority-Analysis: v=2.2 cv=e552ceh/ c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=Ikt0M2cxAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=1wcvNR40QQKOSlA0ZQsA:9 a=YK0CePum-hNoyyvr:21 a=AUeqQT34yG-lyjsj:21 a=CjuIK1q_8ugA:10 a=iYm7J9qDpiSF5xNCBZUT:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id D3FFFF4; Mon, 9 Oct 2017 12:14:27 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v99JEQTw082402; Mon, 9 Oct 2017 12:14:27 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201710091914.v99JEQTw082402@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Julian H. Stacey" cc: freebsd-arch@freebsd.org Subject: pam_rhosts (was: Re: rtools were deemed almost unused 15 years ago...) In-Reply-To: Message from "Julian H. Stacey" of "Wed, 04 Oct 2017 12:35:03 +0200." <201710041035.v94AZ4JM095529@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Oct 2017 12:14:26 -0700 X-CMAE-Envelope: MS4wfBq/78CEw281A7hhJesPzj1DoGfpLAgzSjEt9PD+ykd/yiK9bXieVpXWSpxm8DMzEgESrpZcdLiqknP54d8DVbqR6h5RzgWo/BcA9o2k/OIgbByx+2tM qho7mRs2pmb1kNzVz1BqfGlwgXL99FWqFmyPo4RAqmKCNWlSIDeJoSJhiNqUPCZrELMuLY3RiCI4m7Pco1C/P8G1tF+iHM2btJ0= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 19:14:38 -0000 In message <201710041035.v94AZ4JM095529@fire.js.berklix.net>, "Julian H. Stacey " writes: > > Have you picked up the recent changes to the code in your port? > > > > ----- Jeremie Le Hen's Original Message ----- > > > I've slacked a bit but here we are: > > > https://reviews.freebsd.org/D12573 > > >=20 > > > On Sat, Jul 1, 2017 at 12:08 PM, Jeremie Le Hen wrote: > > > > On Sat, Jun 24, 2017 at 10:29 PM, Jeremie Le Hen wrot > = > > e: > > > >> So the first step was to create a port with FreeBSD rcmds, here we > > > >> are! But I need some eyes to vet it: > > > >> https://reviews.freebsd.org/D11345 > > > > > > > > The port has been submitted and RCMDS are disabled by default from the > > > > base system. > > > > > > > > See you in a month for the removal! > > > NO ! It's maddening, code vandals periodicaly wanting to delete working code > & pontificating what others globaly should be denied, & forced to do & not do > . > > One example why FreeBSD should not delete rlogin & telnet etc > 3 days ago, a host with broken sshd (bad shared libs version > number), was rescued by ssh to trusted parent host, then rlogin > from that parent host to underlying jail. > > 3rd party code vandals are Not fit to decide what code should be > denied globaly in other peoples' environments. By all means leave off by > default in /etc/inetd.conf as now, but do Not Vandal Delete ! > > BSD is not Microsoft replete with masses of clueless users. BSD > includes skilled users who may wish to make their own risk assessments, > without interference. Ahh but there are masses clueless UNIX, Linux, and BSD users. I deal with these people on a daily basis at $JOB (to them it's %JOB). They're developers, mostly java developers but others too, who only understand Microsoft, and that just barely if even that. Worse is the approval they have for sudo privileges. It's scary. Protecting users from themselves is the right thing to do. Part of the issue with rcmds is they don't support encryption, which is why MIT created kerberized versions of the same utilities. Removing rcmds solves half the problem. The other is rhosts, implemented by pam_rhosts. Why in the world do we still allow IP address based authentication? (I suppose it's OK on a local home network with one or two family members as users.) Seriously, rhosts is the major reason why rcmds is insecure. It was pointed out that pam_rhosts is still used by sshd. I think that's asking for trouble. It's time to discard the rhosts baggage. It's insecure and why ssh keys were developed in the first place. rhosts should be deprecated and removed prior to 13. P.S. This is one issue. There are two others I'd raise here but let's focus on this one first. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Mon Oct 9 19:57:01 2017 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 3653DE3A83B for ; Mon, 9 Oct 2017 19:57:01 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 199F17D34F; Mon, 9 Oct 2017 19:57:00 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id D6571AF1; Mon, 9 Oct 2017 14:56:53 -0500 (CDT) Date: Mon, 9 Oct 2017 14:56:52 -0500 From: Mark Linimon To: Nathan Whitehorn Cc: Warner Losh , "freebsd-arch@freebsd.org" , swills@FreeBSD.org Subject: status of powerpc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171009195652.GA28957@lonesome.com> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 19:57:01 -0000 On Mon, Oct 09, 2017 at 10:47:13AM -0700, Nathan Whitehorn wrote: > - There are no binary packages built for PPC64, because of project policy > preventing the use of native build systems I don't think this is 100% correct. Although I am no longer on portmgr and thus don't work on the details, my understanding is that: - "official" FreeBSD packages can only be issued from machines that are under the exclusive control of FreeBSD.org - the powerpc64 machine that falls under that category is not yet reliable enough The first is a security concern. The odds of that policy changing are about the same as Elvis doing another concert. IIUC the second is because we run package builds under virtualization on freebsd.org's powerpc64 machine, and hit memory contstraints often enough to make it "not quite ready for production". You would have to ask swills@ whether the latter is still true. My own powerpc64 builds are constrained for other reasons[*]. When I get back from my current road trip I am willing to build and make available a subset of powerpc64 packages on the same basis I currently do for sparc64, if that will help the situation. > - You cannot cross-compile packages for PPC64, because of limitations > in QEMU s/limitations/a bug/ qemu/powerpc64 simply hangs when you start it up (as does qemu/sparc64). Otherwise qemu is usable for cross-builds and is, in fact, how armv6, mips, and mips64 package builds are currently done. I know less about your other points, but, there needs to be some kind of script or wrapper around the "do a base cross-build". I had had one set up for amd64 to sparc64 as a test but got distracted before I finished. I recall it being non-trivial. mcl [*] a couple of kernel bugs which I think I know how to fix; not being able to run diskful, and power consumption From owner-freebsd-arch@freebsd.org Mon Oct 9 23:20:06 2017 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 5B06FE3ECCE for ; Mon, 9 Oct 2017 23:20:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 43F2F84A44 for ; Mon, 9 Oct 2017 23:20:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3FAFBE3ECCD; Mon, 9 Oct 2017 23:20:06 +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 3F44BE3ECCB; Mon, 9 Oct 2017 23:20:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (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 1B6B484A41; Mon, 9 Oct 2017 23:20:05 +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 mail.baldwin.cx (Postfix) with ESMTPSA id 20F9810A8C0; Mon, 9 Oct 2017 19:20:03 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Warner Losh , Ian Lepore , "freebsd-arch@freebsd.org" , Dimitry Andric Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Date: Mon, 09 Oct 2017 16:19:51 -0700 Message-ID: <1838629.1fOj0Hxk8Q@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <1507565759.77958.7.camel@freebsd.org> 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.4.3 (mail.baldwin.cx); Mon, 09 Oct 2017 19:20:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 23:20:06 -0000 On Monday, October 09, 2017 10:21:53 AM Warner Losh wrote: > On Mon, Oct 9, 2017 at 10:15 AM, Ian Lepore wrote: > > > On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote: > > > On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore wrote: > > > > > > > > > > > On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: > > > > > > > > > > On 9 Oct 2017, at 07:45, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > > > > > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. > > These > > > > are > > > > > > > > > > > > > > > > > really parts of the boot loader with an unstable API and shouldn't > > be > > > > > > installed into the system. It's really a private library to the > > boot > > > > loader. > > > > > > > > > > Though I completely agree with this, I am still interested in the > > > > > historical reasons for separating out this library for general > > userland > > > > > consumption. Were there any other parts of world that happened to > > use > > > > > libstand? > > > > > > > > > > -Dimitry > > > > > > > > > There are out-of-tree users of libstand. Perhaps not many, but a > > > > couple times after doing something to libstand I've received emails > > > > from people that thanked me for the enhancement and mentioned some non- > > > > loader(8) use of the lib in passing. (Unfortunately, I can't find any > > > > of those mails now, they were from 2-3 years ago.) > > > > > > > They can email me and I'll help them convert over... :) > > > > > > Warner > > > > Actually, I got distracted, then came back and hit Send too soon. I > > meant to ask "Will the library still be accessible to out of tree > > users?", so that adjusting to the change will amount to fixing some > > build breakage to adjust to a new location? > > > > The proposal is to take it 100% internal and officially not support its use > outside the loader. > > It's open source, so if you really want to use it, you can with some > effort. If there's one or two people, they can adjust. If there's lots, > then I can revisit the proposal. It would help to know who they were and > what, exactly, they used it for. Note that one wrinkle is that libstand pulls in source bits from libc. Historically it's been possible to checkout just sys/ and build sys/boot if you had a matching world because libstand would be installed. This will now require a full world checkout. That's probably not the end of the world (and it is debatable if 'boot' even belongs in sys/ vs being a separate top-level dir in the source tree). In general we try to make sys/ (for the kernel) be self-contained and this would kind of break that, though I think I'd be happy moving boot out of sys/ altogether to restore that convention. -- John Baldwin From owner-freebsd-arch@freebsd.org Mon Oct 9 23:37:08 2017 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 EF5D4E3F1E8 for ; Mon, 9 Oct 2017 23:37:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 AEF9965D for ; Mon, 9 Oct 2017 23:37:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id 101so10167966ioj.3 for ; Mon, 09 Oct 2017 16:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=sAIHz+kCFgBMD7w7pHVSs2ckpDUPkleJymdW97+QNiU=; b=cp/R4Q8rNRkktudvnftouW6e1ZGu88Xf9eE74bcAJjVwLHrQ+ARhGxql5kKR7fhHDV MfbcAQHiyZkAiJjbaqFDN6UZhuFLNVZoRFAwOeY7L6AuLIigED3N3SmV4UUx/hZ58PEM JvXeSe7pNt8yZtptu6yEApRtCDQxipTY0XYQaRN/o837WUF9K36fJtARL/ZlwBEBbMyC edphlrKAkgt+IvMndAsF/gUt8raDGuKOubnscYmI5eMxNnUdl6Jw0Limwhwx6iyIX4oi 0w7l75Rm8FUxzQmqprbHj6WAzzPa4ejAotBofGGjrl+9Wl3EzobVfZe9R9/JTgBkgYUf Tx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=sAIHz+kCFgBMD7w7pHVSs2ckpDUPkleJymdW97+QNiU=; b=X10ahfBM8HyOZavsvdkiFKup/Lk+3kpSvwjdgGMtPU82us8vNsNt+Rw0oGgbCyJkza UBmJCBgZrxvfA3sN5/LtIz6dRtO3S+vQyXYFskTYmktBIPzNvc3cW7y/3JWywx/lXneJ D4u99VHZuSjopPaa6ZdRz2oF3bwba1ynTkttqXzZIsBUMA9loNOH32iBnTsa0KpFs5MN jJCrNINEExh09jbACrZBPketofkGz0FZW22oGvcxfOTvgR2O+trqInNva5bQf0ALLGNu vviUT52KKyJrvxmeaFUlTCkVbG2tTRLSX0VZ4jgqxFnxc9Q83dlZbPSaqZ+b7bJ5D6An zjaQ== X-Gm-Message-State: AMCzsaULwpXfvddbSxhV2aUX5pdKy14LZq8/LfDEvt2yDn9qAjbBvGQ/ vnSMq8GlKR8hiUh/6pc1xw4ADQ== X-Google-Smtp-Source: AOwi7QA4AwjoWGeI7OzyjQt98dT04PoO4uZgjNhfRDflow7jzNpHXjhP/H9UO1LUc9/VjCp1N2LyDA== X-Received: by 10.107.174.94 with SMTP id x91mr11349939ioe.224.1507592227893; Mon, 09 Oct 2017 16:37:07 -0700 (PDT) Received: from ?IPv6:2603:300b:6:5100:8936:338a:89de:d5ea? ([2603:300b:6:5100:8936:338a:89de:d5ea]) by smtp.gmail.com with ESMTPSA id k86sm1645879ioi.23.2017.10.09.16.37.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Oct 2017 16:37:07 -0700 (PDT) Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <1838629.1fOj0Hxk8Q@ralph.baldwin.cx> Date: Mon, 9 Oct 2017 17:37:05 -0600 Cc: freebsd-arch@freebsd.org, Warner Losh , Ian Lepore , "freebsd-arch@freebsd.org" , Dimitry Andric Message-Id: <01205326-3312-47A1-B2B8-D8C7976F1DFD@bsdimp.com> References: <1507565759.77958.7.camel@freebsd.org> <1838629.1fOj0Hxk8Q@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 23:37:09 -0000 --Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2017, at 5:19 PM, John Baldwin wrote: >=20 > On Monday, October 09, 2017 10:21:53 AM Warner Losh wrote: >> On Mon, Oct 9, 2017 at 10:15 AM, Ian Lepore wrote: >>=20 >>> On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote: >>>> On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore = wrote: >>>>=20 >>>>>=20 >>>>> On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: >>>>>>=20 >>>>>> On 9 Oct 2017, at 07:45, Warner Losh wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. >>> These >>>>> are >>>>>>=20 >>>>>>>=20 >>>>>>> really parts of the boot loader with an unstable API and = shouldn't >>> be >>>>>>> installed into the system. It's really a private library to the >>> boot >>>>> loader. >>>>>>=20 >>>>>> Though I completely agree with this, I am still interested in the >>>>>> historical reasons for separating out this library for general >>> userland >>>>>> consumption. Were there any other parts of world that happened = to >>> use >>>>>> libstand? >>>>>>=20 >>>>>> -Dimitry >>>>>>=20 >>>>> There are out-of-tree users of libstand. Perhaps not many, but a >>>>> couple times after doing something to libstand I've received = emails >>>>> from people that thanked me for the enhancement and mentioned some = non- >>>>> loader(8) use of the lib in passing. (Unfortunately, I can't find = any >>>>> of those mails now, they were from 2-3 years ago.) >>>>>=20 >>>> They can email me and I'll help them convert over... :) >>>>=20 >>>> Warner >>>=20 >>> Actually, I got distracted, then came back and hit Send too soon. I >>> meant to ask "Will the library still be accessible to out of tree >>> users?", so that adjusting to the change will amount to fixing some >>> build breakage to adjust to a new location? >>>=20 >>=20 >> The proposal is to take it 100% internal and officially not support = its use >> outside the loader. >>=20 >> It's open source, so if you really want to use it, you can with some >> effort. If there's one or two people, they can adjust. If there's = lots, >> then I can revisit the proposal. It would help to know who they were = and >> what, exactly, they used it for. >=20 > Note that one wrinkle is that libstand pulls in source bits from libc. > Historically it's been possible to checkout just sys/ and build = sys/boot if > you had a matching world because libstand would be installed. This = will > now require a full world checkout. That's probably not the end of the = world > (and it is debatable if 'boot' even belongs in sys/ vs being a = separate > top-level dir in the source tree). In general we try to make sys/ = (for > the kernel) be self-contained and this would kind of break that, = though I > think I'd be happy moving boot out of sys/ altogether to restore that > convention. Except that=E2=80=99s not been true for a long time=E2=80=A6. libstand32 pulls from lib/libstand, or did until recently. userboot/libstand likewise. sys/boot needs both to build. It=E2=80=99s historically been under sys = since around V32 if my sleuthing is right, though there=E2=80=99s been = expcetions (cf src/mdec in BSDs as late as 4.4BSD). v7 had them in = /usr/mdec as well as src/cmd/standalone, so hoisting them a level would = represent a return to the past. Though we=E2=80=99ve hopelessly mixed up = the clean separation of low-level =E2=80=98boot1=E2=80=99 like loaders = that knew just enough to find boot2 on the disk programs with our all = singing, all dancing /boot/loader (which is more or less analogous to = src/cmd/standalone, though at the time things weren=E2=80=99t packages = together for size reasons). Not sure that it=E2=80=99s worth sorting = that last stuff out at this late date though=E2=80=A6 That=E2=80=99s a long way of saying =E2=80=9CI=E2=80=99d support moving = it to src/$(result-of-bikeshed sys/boot)=E2=80=9D but that=E2=80=99s not = what I=E2=80=99m doing today. Warner P.S. Since there was no pushback, and evidence of a ton of pent up = demand, I=E2=80=99ve gone ahead and pulled the trigger on the move. --Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZ3AghAAoJEGwc0Sh9sBEAr08P/RQJ4wxGvWZ+ZrgyxTvq70vt qA36l3MDc2ySPCtQiDsOIYXW0bgrUDcY1FZxpCzWq+pLrb4aCPXVJzIGKgyXPd63 w5mmf89QsNG+5rCCvwd2FIDeluLa9qVMQUSW1U3dIGUa+60GeuZHe/5g55fFZ34t TSc+vgYkoeRNjIzupt71PQUWfMZNcRKRWuLv3AR4VXrdh5nWrPmAtLFmdqrZmUaY z6Uvoc6Kmmn7zOAMxTCe9muKs14uSoHCuI4W7HRWLtLr8HydsUQoPC2r6VQ4kRr+ yY7W5sl0Jop8Vtf/6bvchQY65/xzoPX8/fJjoLee6jTeuNIPSEqd8jnC6vpyWmyh KCDkgV82BBOJ4iSYUM+OqfIOqJZoY6vuhPDK0OxTS84hpn/ACCTWEu64IyyUOJTA h9asNiBneIS/LjMfBRy+I0Yp3BYdG9hbLS35aDkSGmyNzrk98BpDWqqK/IGVABzS hO5zfhwN5JKWFNlAitwt7eay+hpF9RvbMoe+g9CfmpZSWz0qVXFHEelMq8hLhcw6 VHE8kVebAONPlD/8/bAmt8pJ/hIhs/xpFk4QRQjIzGjAuA/7L2qDxCEV12BEmCm3 mTw/VDy/5m76IIhn8DKoqG0fU/NdRKKBavr7rbHyN/gPVp1L2yJbLFXbDMF5f0KX DW0wc0IwteIbsNonaErH =C5cB -----END PGP SIGNATURE----- --Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A-- From owner-freebsd-arch@freebsd.org Tue Oct 10 05:07:18 2017 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 DE9C1E48F97 for ; Tue, 10 Oct 2017 05:07:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 C89786C080 for ; Tue, 10 Oct 2017 05:07:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (s-169-232-86-189.resnet.ucla.edu [169.232.86.189]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9A4v554012754 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 9 Oct 2017 21:57:05 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Nathan Whitehorn Message-ID: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> Date: Mon, 9 Oct 2017 21:57:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVaF++2dDDBcANvg1NI6tr7s23EtGRSe5wHqCHAZDhT6vS4QSWpnaTAXREG3SnBT3XsaPrcke8Df0yj9atXufXGZsG0ynzs1lLQ= X-Sonic-ID: C;IHQtdnet5xGv8YlQ3iMJ6w== M;vsF4dnet5xGv8YlQ3iMJ6w== 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.23 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 Oct 2017 05:07:19 -0000 On 10/09/17 11:32, Warner Losh wrote: > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" wrote: > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn > wrote: > >> >> On 10/06/17 00:20, Baptiste Daroussin wrote: >> >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >>> >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>>> >>>>> I'd like to start a conversation about the viability of making C++11 a >>>>> hard >>>>> requirement for bootstrapping FreeBSD and setting a specific deadline >>>>> for >>>>> doing so. >>>>> >>>>> This discussion is motivated by an ask from the jemalloc folks to use a >>>>> limited subset of C++11 inside of malloc in such a way that is C safe >>>>> (so >>>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>>>> discussion in another forum, and isn't appropriate for this thread >>>>> because >>>>> this has become a frequent request (but if you have opinions, please >>>>> find >>>>> the thread in current@ about it). I don't know the timeline of their >>>>> plans >>>>> to do this. >>>>> >>>>> I'd like to take the rather vague plans we've had "before 12" and >>>>> create a >>>>> timeline for removal of gcc 4.2 coupled with a requirement for support >>>>> in >>>>> clang or a working external toolchain. This requirement would be coupled >>>>> with the requirement that the external toolchain support C++11 >>>>> constructs. >>>>> >>>>> I'd like to propose we do this 12/31/17. Any architectures that can't >>>>> meet >>>>> this timeline will be disconnected from universe at that time and >>>>> deleted >>>>> 3/31/18. >>>>> >>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are >>>>> ready for this change and mips* would be ready for this change with an >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect >>>>> that >>>>> a newer version of gcc as an external toolchain could work. >>>>> >>>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). >>>> However, >>>> it requires external ld.bfd. I know that there ld.lld can link a working >>>> mips64 world with some patches (notably the multigot patch). mips works >>>> fine >>>> with external GCC. riscv is already using external GCC that is >>>> C++11-capable. >>>> >>>> The problem with external GCC is that you can cross-build a world + >>>> kernel >>>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, >>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >>>> started on ports to cross-build binutils and gcc packages via the base/* >>>> ports, but those are not yet finished / fully tested. I don't think >>>> anyone >>>> has thought about how release builds will work either with only an >>>> external >>>> toolchain available. (I'm pretty sure sparc64 has booted fine with >>>> external GCC, it's just in the same boat as mips with regard to >>>> /usr/bin/cc.) >>>> >>> Actually I did test those and they were working (tested in qemu) they were >>> working fine. I have given up working on them due to the lack of >>> interested by >>> the community (by interest I mean people really testing, working on it, >>> not just >>> saying "hey nice sounds cool"). >>> >>> As for the boot when I initially worked on external toolchain sparc64 was >>> my >>> guinea pig and so yes it worked an booted just fine. >>> >> So far as I know, we never solved any of the infrastructural problems >> associated with this concept: >> 1. Providing built releases with a /usr/bin/cc >> 2. Coversioning base and in-ports toolchain, including ensuring commit >> atomicity between toolchains and libc >> 3. Adding a dependency on ports for src, including out-of-tree code that >> has to be fetched from external servers >> 4. Getting make universe to do the right thing >> >> We really need to solve those. If we go the external toolchain route, >> which it is not clear to me is the best option, #2 and #1 are quite complex >> problems. I think that, frankly, a deadline in two months to solve this set >> of political problems we have had for two years is probably crazy, but >> maybe making the status quo unsustainable will finally force progress. >> > External toolchains have been in flight for 5 or more years now. It's time > they land. Though the requirements for them have never included > cross-threading between /usr/src and /usr/ports like you suggest above, and > those sorts of things won't be sorted by my deadlines (which are closer to > 3 months). Nor, imho, should they. > > > Well, sure. But the fact remains that we cannot build usable systems with > external toolchains right now. Those are real problems that need to be > solved somehow. > > > Sure we can. I've built a bootable i386 system with gcc 6. It is a solved > problem. "Bootable" is not the same as "usable" here. External toolchain powerpc64 *boots* fine -- and has for years -- but there isn't much you can actual *do* with the system except admire dmesg without the ability to install ports. > Let's focus on #1, the largest if not the only major problem. If I build, > say, a ppc64 system with an external toolchain right now, it boots and runs > fine. But the system is completely unusable since: > - There are no binary packages built for PPC64, because of project policy > preventing the use of native build systems > > > System is still usable w/o packages. People can still fire up custom > poudrier repos. We could also change project policy. This is is a specific > wrinkle for powerpc64 it seems. How would I do that? We can't run these natively, because the system ships without a compiler. And we can't cross-compile, because the ports tree does not support that. > > - You cannot cross-compile packages for PPC64, because of limitations in > QEMU > > > Then we should fix those, like we did for arm and MIPS. That's a tremendous amount of work on a non-FreeBSD codebase. Are we now going to require QEMU patches from platform maintainers? > - There is no compiler installed in the base system, so you cannot install > any software from source code > > > You can install it as a package. Where do you get the package? > > - You cannot build the compiler from source, because you don't have one to > bootstrap from and can't get one pre-built because of the no-packages > problem. > > > If you fix the other problems, this is solved. Yes, absolutely. But how do we solve the others? > We can't ship systems like this -- how is anyone expected to be able to use > them? > > > Most systems don't build software, so there are plenty of uses. I think all systems *install* software. If we don't have packages, then it has to be buildable from source and we need a compiler. We just can't close *both* paths. > > These are easy to fix -- for example, here are three possibilities -- but > solutions been held up for *years* by project policy: > 1. Allow Tier-2 packages to be built on native hardware without as much > centralized control, letting pkg install of the toolchain work. This fixes > ppc64, but maybe not embedded systems. > > > If we can't build in QEMU then sure. It doesn't matter where the binaries > come from, so long as they work. Yes, agreed. This has not been project policy thus far, however. > 2. Have external-toolchain builds cross-build (or native-build) and > pre-install a standard compiler package from ports during make buildworld, > which keeps the user experience of current tier-2 and later tier-1 systems. > > > No need for this to be during buildworld. I see no benefit from that. You > can install it after installworld either native or to a destdir. Fair enough. Read this as "included as part of the release media and, ideally, extracted and installed by default". I do not care -- at all -- how it comes to be part of the release media/hosted by freebsd.org, so long as it is and is updated at least as often as releases, ideally as part of the release process. > 3. Include a newer compiler fully in the tree or in some nearby repository, > which does the same. > > > Yea, that's also possible. But then it isn't an external toolchain. Absolutely -- this is included for completeness in the more general conversation of (finally) removing GCC 4.2. > If we break any of these policy impasses by the deadline, I am 100% for > dropping GCC 4.2. But we *have* to do something. Just axing code while > preventing a meaningful replacement isn't a solution. > > > > We have sometthing that works today with a few warts. We shouldn't let the > warts get in the way. The situation right now is pretty wart-y: there is no way to install software, of any kind, on a number of platforms with external toolchains, powerpc64 among them. > I'm happy to delay if there are specific items that have a definitive > timeline, but wanting 100% full integration from external toolchain with > full packages isn't a gating factor here. Absolutely! I don't want to make the perfect the enemy of the good, especially when the good is finally freeing ourselves from GCC 4.2. But we have been blocked for years by the fact that we have not been able, as a result of basically purely policy issues, to find a way to bootstrap a GCC 4.2-less system so that ports can be installed. And, as much as I like running fortune, I think not being able to install 3rd-party software is a blocker. > Besides, I thought powerpc64 just worked with clang... Unfortunately, no. There are a wide variety of subtle issues. You can boot a kernel built with -O0, but higher optimization levels or userland code (especially C++) break. -Nathan > > Warner > > Also, are there any directions for how to build a toolchain from the base >> ports? I haven't been able to figure it out -- the README starts with "pkg >> install", but that doesn't get me very far on platforms without binary >> packages, which are the ones this is meant to target. > > External toolchains are by definition external. Not part of the tree nor > integrated into the tree. How you get them depends on the external > toolchain and is unspecified. You get a lower level of integration than you > do with in-tree toolchains, not the same level with reach-overs into some > external repo. > > > I think you missed the point. I was asking how to build the port to test it > -- it doesn't build at present and I can't figure out how to make an > external toolchain via the "base" ports (the other toolchains in ports work > fine). > -Nathan > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Tue Oct 10 05:56:09 2017 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 B098AE2528B for ; Tue, 10 Oct 2017 05:56:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 70FE56D9B1 for ; Tue, 10 Oct 2017 05:56:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id g18so1047733itg.5 for ; Mon, 09 Oct 2017 22:56:09 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=20FqLpe040+OT2yo/1ga7uhJoeatvpQwsrJxkf1i3CM=; b=QeYUuFBn8R1WCCD8DBMDPOVDX9puz64x0E1R0y+yF45QnjvvAVuMHIGOdzojr3w7jf /eSVosZAamyB5vQwzyuMmf89ZUafIRwvuMROqwBQxhi1E0wegnDC/u5KFXRNfeVUXEDS b7+XaUH59v822y4YIUPHQW+e3d7jotwLTEWpHhbdpqRKA0jQIWBP1+VrDejLBmyX0VT+ leYwlkN08IAr/PwOrWzOfO1fZuvR0mZd61RrJO9Iy+HLQWmB24EfCDfKvvhDyn2/ZPDY IJkkF5qY3n2VCdKGbQYcG/EpzMzW2vufPMBKSoOArmFLMFGOXOuUU2HgNFRBLLnM/W9B WDTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=20FqLpe040+OT2yo/1ga7uhJoeatvpQwsrJxkf1i3CM=; b=jRbLn5TaDWS5DMP8s+i6Jyi4HH+7H7a3gvHqwfYRc1iv0w21hCLMay8DTnnO+4ipLw 999SCXQexXXScbIfhzgsmmIEykA1NcJpRxAogfisyhnjqUVxSNlVhy+eS9c52ZPhDZCc Rb3AU6130sPmyW4TOQ+psMx/1QBj5EAb1Y0OTs9s3IBdnlvfDq3UKJRJ5RJNsnaH14W1 d+VgWfjTRN/hsj/ayqCdhVI8sgnhf4S4KPTNIqM1ozLoaEC7ueXN6I4PQUWLMe9XR9mu RVcBS4WB1XsAnXWcoL43QMFJRk0eswKB9j2zYH0+MS97WIKVQ5svzLLcbVwyVSeN+QWH UHSQ== X-Gm-Message-State: AMCzsaW8MWRedRGRBP2IiuY0gjmmqoVSg7fUA/E4px9jZooTxADGyZRJ 77nb866v3mDREl9/Te6hmtled43YAxxW6R7toL6kOw== X-Google-Smtp-Source: AOwi7QDPFMhmjhGmQICDVjrW1Loj7r97wyrFOc1JGdwqjrkH2nB0xOvDIuEnptm85zAnWl2Bnz1/VY4Zdui9C4HwNyU= X-Received: by 10.36.203.3 with SMTP id u3mr15484266itg.136.1507614968650; Mon, 09 Oct 2017 22:56:08 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Mon, 9 Oct 2017 22:56:07 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:4920:aead:e4cc:fa29] In-Reply-To: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> From: Warner Losh Date: Mon, 9 Oct 2017 23:56:07 -0600 X-Google-Sender-Auth: cgBw-2BhbicOfeIG5NCqYFeSnHk Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Nathan Whitehorn Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 05:56:09 -0000 On Mon, Oct 9, 2017 at 10:57 PM, Nathan Whitehorn wrote: > > > On 10/09/17 11:32, Warner Losh wrote: > >> On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" >> wrote: >> >> >> >> On 10/08/17 22:26, Warner Losh wrote: >> >> >> >> On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn > > >> wrote: >> >> >>> On 10/06/17 00:20, Baptiste Daroussin wrote: >>> >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >>>> >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>>>> >>>>> I'd like to start a conversation about the viability of making C++11 a >>>>>> hard >>>>>> requirement for bootstrapping FreeBSD and setting a specific deadline >>>>>> for >>>>>> doing so. >>>>>> >>>>>> This discussion is motivated by an ask from the jemalloc folks to use >>>>>> a >>>>>> limited subset of C++11 inside of malloc in such a way that is C safe >>>>>> (so >>>>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>>>>> discussion in another forum, and isn't appropriate for this thread >>>>>> because >>>>>> this has become a frequent request (but if you have opinions, please >>>>>> find >>>>>> the thread in current@ about it). I don't know the timeline of their >>>>>> plans >>>>>> to do this. >>>>>> >>>>>> I'd like to take the rather vague plans we've had "before 12" and >>>>>> create a >>>>>> timeline for removal of gcc 4.2 coupled with a requirement for support >>>>>> in >>>>>> clang or a working external toolchain. This requirement would be >>>>>> coupled >>>>>> with the requirement that the external toolchain support C++11 >>>>>> constructs. >>>>>> >>>>>> I'd like to propose we do this 12/31/17. Any architectures that can't >>>>>> meet >>>>>> this timeline will be disconnected from universe at that time and >>>>>> deleted >>>>>> 3/31/18. >>>>>> >>>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 >>>>>> are >>>>>> ready for this change and mips* would be ready for this change with an >>>>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect >>>>>> that >>>>>> a newer version of gcc as an external toolchain could work. >>>>>> >>>>>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). >>>>> However, >>>>> it requires external ld.bfd. I know that there ld.lld can link a >>>>> working >>>>> mips64 world with some patches (notably the multigot patch). mips >>>>> works >>>>> fine >>>>> with external GCC. riscv is already using external GCC that is >>>>> C++11-capable. >>>>> >>>>> The problem with external GCC is that you can cross-build a world + >>>>> kernel >>>>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. >>>>> However, >>>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >>>>> started on ports to cross-build binutils and gcc packages via the >>>>> base/* >>>>> ports, but those are not yet finished / fully tested. I don't think >>>>> anyone >>>>> has thought about how release builds will work either with only an >>>>> external >>>>> toolchain available. (I'm pretty sure sparc64 has booted fine with >>>>> external GCC, it's just in the same boat as mips with regard to >>>>> /usr/bin/cc.) >>>>> >>>>> Actually I did test those and they were working (tested in qemu) they >>>> were >>>> working fine. I have given up working on them due to the lack of >>>> interested by >>>> the community (by interest I mean people really testing, working on it, >>>> not just >>>> saying "hey nice sounds cool"). >>>> >>>> As for the boot when I initially worked on external toolchain sparc64 >>>> was >>>> my >>>> guinea pig and so yes it worked an booted just fine. >>>> >>>> So far as I know, we never solved any of the infrastructural problems >>> associated with this concept: >>> 1. Providing built releases with a /usr/bin/cc >>> 2. Coversioning base and in-ports toolchain, including ensuring commit >>> atomicity between toolchains and libc >>> 3. Adding a dependency on ports for src, including out-of-tree code that >>> has to be fetched from external servers >>> 4. Getting make universe to do the right thing >>> >>> We really need to solve those. If we go the external toolchain route, >>> which it is not clear to me is the best option, #2 and #1 are quite >>> complex >>> problems. I think that, frankly, a deadline in two months to solve this >>> set >>> of political problems we have had for two years is probably crazy, but >>> maybe making the status quo unsustainable will finally force progress. >>> >>> External toolchains have been in flight for 5 or more years now. It's >> time >> they land. Though the requirements for them have never included >> cross-threading between /usr/src and /usr/ports like you suggest above, >> and >> those sorts of things won't be sorted by my deadlines (which are closer to >> 3 months). Nor, imho, should they. >> >> >> Well, sure. But the fact remains that we cannot build usable systems with >> external toolchains right now. Those are real problems that need to be >> solved somehow. >> >> >> Sure we can. I've built a bootable i386 system with gcc 6. It is a solved >> problem. >> > > "Bootable" is not the same as "usable" here. External toolchain powerpc64 > *boots* fine -- and has for years -- but there isn't much you can actual > *do* with the system except admire dmesg without the ability to install > ports. Right, and at least some of the issues with powerpc64 are non-technical. If you have binary packages, none of the things that you point out matter. There's an external compiler that can be installed for cross building a system, or you have a running system that you were able to build, so necessarily have a compiler for further bootstrapping. But doesn't clang work well enough for this on powerpc? If not, then wouldn't we be in the same position with or without external toolchains? Let's focus on #1, the largest if not the only major problem. If I build, >> say, a ppc64 system with an external toolchain right now, it boots and >> runs >> fine. But the system is completely unusable since: >> - There are no binary packages built for PPC64, because of project policy >> preventing the use of native build systems >> >> >> System is still usable w/o packages. People can still fire up custom >> poudrier repos. We could also change project policy. This is is a specific >> wrinkle for powerpc64 it seems. >> > > How would I do that? We can't run these natively, because the system ships > without a compiler. And we can't cross-compile, because the ports tree does > not support that. Fair point about ports not supporting cross compile. I thought it supported, though setting CC. If you can set CC, you can natively build the packages. If not, then we should fix that. Most ports, however, just require 'cc' to be in the path and don't much care if it is /usr/bin/cc or /usr/local/bin/cc. - You cannot cross-compile packages for PPC64, because of limitations in >> QEMU >> >> >> Then we should fix those, like we did for arm and MIPS. >> > > That's a tremendous amount of work on a non-FreeBSD codebase. Are we now > going to require QEMU patches from platform maintainers? Require? No. But other platform maintainers have fixed qemu when it was broken for arm and mips. Sometimes Sean Bruno fixed it, other times he got help from the port maintainer. But he really wanted packages. - There is no compiler installed in the base system, so you cannot install >> any software from source code >> >> >> You can install it as a package. >> > > Where do you get the package Well, if you have a native system, you needed one to build the system. Cross building is more tricky, I'll grant. A carefully curated set of natively built compilers would suffice. > - You cannot build the compiler from source, because you don't have one to >> bootstrap from and can't get one pre-built because of the no-packages >> problem. >> >> >> If you fix the other problems, this is solved. >> > > Yes, absolutely. But how do we solve the others? > > We can't ship systems like this -- how is anyone expected to be able to use >> them? >> >> >> Most systems don't build software, so there are plenty of uses. >> > > I think all systems *install* software. If we don't have packages, then it > has to be buildable from source and we need a compiler. We just can't close > *both* paths. And the paths to get packages are solvable problems. > These are easy to fix -- for example, here are three possibilities -- but >> solutions been held up for *years* by project policy: >> 1. Allow Tier-2 packages to be built on native hardware without as much >> centralized control, letting pkg install of the toolchain work. This fixes >> ppc64, but maybe not embedded systems. >> >> >> If we can't build in QEMU then sure. It doesn't matter where the binaries >> come from, so long as they work. >> > > Yes, agreed. This has not been project policy thus far, however. Policy changes all the time. As pointed out in other email, though, it's more complicated and at least partially political. 2. Have external-toolchain builds cross-build (or native-build) and >> pre-install a standard compiler package from ports during make buildworld, >> which keeps the user experience of current tier-2 and later tier-1 >> systems. >> >> >> No need for this to be during buildworld. I see no benefit from that. You >> can install it after installworld either native or to a destdir. >> > > Fair enough. Read this as "included as part of the release media and, > ideally, extracted and installed by default". I do not care -- at all -- > how it comes to be part of the release media/hosted by freebsd.org, so > long as it is and is updated at least as often as releases, ideally as part > of the release process. > > 3. Include a newer compiler fully in the tree or in some nearby repository, >> which does the same. >> >> >> Yea, that's also possible. But then it isn't an external toolchain. >> > > Absolutely -- this is included for completeness in the more general > conversation of (finally) removing GCC 4.2. > > If we break any of these policy impasses by the deadline, I am 100% for >> dropping GCC 4.2. But we *have* to do something. Just axing code while >> preventing a meaningful replacement isn't a solution. >> >> >> >> We have sometthing that works today with a few warts. We shouldn't let the >> warts get in the way. >> > > The situation right now is pretty wart-y: there is no way to install > software, of any kind, on a number of platforms with external toolchains, > powerpc64 among them. > > I'm happy to delay if there are specific items that have a definitive >> timeline, but wanting 100% full integration from external toolchain with >> full packages isn't a gating factor here. >> > > Absolutely! I don't want to make the perfect the enemy of the good, > especially when the good is finally freeing ourselves from GCC 4.2. But we > have been blocked for years by the fact that we have not been able, as a > result of basically purely policy issues, to find a way to bootstrap a GCC > 4.2-less system so that ports can be installed. And, as much as I like > running fortune, I think not being able to install 3rd-party software is a > blocker. Policy can be changed. Besides, I thought powerpc64 just worked with clang... >> > > Unfortunately, no. There are a wide variety of subtle issues. You can boot > a kernel built with -O0, but higher optimization levels or userland code > (especially C++) break. > >> C++ isn't needed to boostrap gcc. > Warner >> >> Also, are there any directions for how to build a toolchain from the base >> >>> ports? I haven't been able to figure it out -- the README starts with >>> "pkg >>> install", but that doesn't get me very far on platforms without binary >>> packages, which are the ones this is meant to target. >>> >> >> External toolchains are by definition external. Not part of the tree nor >> integrated into the tree. How you get them depends on the external >> toolchain and is unspecified. You get a lower level of integration than >> you >> do with in-tree toolchains, not the same level with reach-overs into some >> external repo. >> >> >> I think you missed the point. I was asking how to build the port to test >> it >> -- it doesn't build at present and I can't figure out how to make an >> external toolchain via the "base" ports (the other toolchains in ports >> work >> fine). >> -Nathan >> >> Warner >> > I guess I'm looking for an actionable set of blockers with a timetable for resolution. These all sound a lot like inconvenient problems stemming from some bad choices of project controlled equipment. External toolchains could be supplied by third parties as packages. That would solve much of the bootstrapping problem. Some time spent fixing the bugs in qemu that keep it from being a viable option would also open up a flood of packages (we have good infrastructure for creating mips and arm packages today I'm told would be relatively easy to expand to new architectures). However, absent a clear plan, as well as resourced dedicated to realize it, I'm not sure that we should block things further based strictly on a list of things that are broken. If there's a plan to fix, I'm willing to defer to give that plan a chance to happen. In the absence of a specific plan with timelines, I'm reluctant to indefinitely delay the negotiated plan for 12 which has taken years to pull together. Otherwise, is 3 more months enough? Is 6? are 12? Do we wait for FreeBSD 13? Warner From owner-freebsd-arch@freebsd.org Tue Oct 10 06:13:18 2017 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 CD4A6E2588E for ; Tue, 10 Oct 2017 06:13:18 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wilcox-tech.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1E916E3CA for ; Tue, 10 Oct 2017 06:13:18 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 18726 invoked from network); 10 Oct 2017 06:13:09 -0000 Received: from 107-131-85-28.lightspeed.tulsok.sbcglobal.net (HELO ?192.168.1.57?) (awilcox@wilcox-tech.com@107.131.85.28) by mail.wilcox-tech.com with ESMTPA; 10 Oct 2017 06:13:09 -0000 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> From: "A. Wilcox" Message-ID: <59DC64F1.6060706@Wilcox-Tech.com> Date: Tue, 10 Oct 2017 01:13:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o7KA1Oq4FDvHUDIr3mCQFC8s1fI1Qofdt" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 06:13:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o7KA1Oq4FDvHUDIr3mCQFC8s1fI1Qofdt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/10/17 00:56, Warner Losh wrote: > (we have > good infrastructure for creating mips and arm packages today I'm told w= ould > be relatively easy to expand to new architectures). Does this include the elusive sparc64 (if qemu were fixed, and the LLVM issues resolved)? Just curious. --arw --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --o7KA1Oq4FDvHUDIr3mCQFC8s1fI1Qofdt 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 iQIcBAEBCAAGBQJZ3GTxAAoJEMspy1GSK50U43kQALYHIUnqKJG4NbmJvvJ0SarU zegM/LW68wfu/yNyegxCxAy1hnlrkDOiHBNcL6sblMW0qwgTHU/vBGo7ifamyyie K0LUlblY/u/CRVmgG267mTFe1g4zoicOCqSKlb074NpYQx8n5FBCc5vWOqcEj5r+ 5v8VdWmF+RS5Xd9OYe0f9p1e7u0Y7GkUD7ksyMr7aTLd9PZFl1CrRv5kM+jL+k9e gXrnSLwOHoQdpajQUvlwxUF6+8Iek/EF+psheNh1LEmVWCuFL2ByNYbWeTGqLdlL QtRieJbwigD1fTEaORw2D4k0sPzPz1sditUeUZ0NYtv5sB+6IYa6m2En3EOROnbi P5Zsr8DwM4kPK0kMSTFgFQ7DLX9FmPGx7UqwSOqCnacOCXmpwoWiEPDoYHPa9kmF Y5yRXsfY4KGnHhCDB7OyKB/gdt8vRfuCdpxdN+9/5M/FQSDg5+1rLOzaXB+qQwbQ B3VvkxwBcAhiJMiLDVvZhbHgTWV5g6kW/Q8Ls2q6MA1HxEOjLWlmv82rK2Ap0pXu 3UgG4NzhDgDXD/xzoBKyY/Am0jLzZ8v/Tx3p9ay3izKM5/x8LU14jvar+EkTO8B5 PU9eZ1DNlCwADRtLRwb63Q6KJYME+CxwAkp5xBwamm9MQsmfe8r9nxR0NQa7gK8u Cm7P11xm25ufZiH0HZEs =uK2x -----END PGP SIGNATURE----- --o7KA1Oq4FDvHUDIr3mCQFC8s1fI1Qofdt-- From owner-freebsd-arch@freebsd.org Tue Oct 10 08:06:47 2017 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 6FD2FE281F4 for ; Tue, 10 Oct 2017 08:06:47 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 26015716B1 for ; Tue, 10 Oct 2017 08:06:47 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id q4so48774450qtq.8 for ; Tue, 10 Oct 2017 01:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G6eetyqC21F5hBJLOUc53aBEEr3OZk5O6FwMcyqe3Yw=; b=YY7xaJ2MFYwL3iag9nKXhCor0pszlxU0kbF0gpYMgE3T6t6KsFhtxd5mKSEi3IOC0Y IokodIPfa1bU+Wmg73q0CP/1a2mDmiK7T82rjfYSteajTuiGHdHdrm7SgmcPQ+jP8UtC /2jqei4Hk2ZnoT2s7f6Y6/8W0DcFFNS0XRg44/14qFY+26xpoDKSBnVp1EnFvIC/A1kS icUrV2OLVu+Yn0sTrsWQjaQDnvQHnV2GNDzEWzgAvKYlLj8M85+sBy1TGloJbwauf7sn AnfkEu45A+bL2T/0VcaA6ZE6UJqhVJ1AEieVE77lC8030f7SbBplaJ0C4vKmuGgI8hFd T6Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G6eetyqC21F5hBJLOUc53aBEEr3OZk5O6FwMcyqe3Yw=; b=Kvr+TxqdpiYKQAzR1FdQ6gvPfmGZaCx7vY3xqDCyqmHzWJSG5KCFftK+C/qWgzMlDx 8gPdpCRrJneTRvdWRLvo/GYKcKvthyQQYplwIehiqEFzgDf+ucHzDOlb1hAmwRZ9pZ0v km3SrRy53Cuq6nTr8QM3B4eOWKVAOsIdOZuEUzErAxo0KiaHWBrhkcWN1k5BJkh4iiH+ WyJ6L3igntJwVc20QEnahNWdCsUj8YtGUL1q98ZnsFdjY+MU44WAgbAOlzWkABySCcsq EopYEUhfpmg1Ho5+8gDH8X0435tXN26ZGQvCQ69ChC3cfGPy5h0MajMZ/Dy5XbYuBLkM KJfQ== X-Gm-Message-State: AMCzsaUhuUHx+M1FKEuj8Ii7oAtV5RTx+mYWX1aUVV0VxtIyxvx24WHQ KKDBX8p7HVQvp3InAE7yYBBy0L+Z1Y4vZo/fZIKONw== X-Google-Smtp-Source: AOwi7QAGOAGoMP+SmSABtHTSXp/UMUKWDkQw0MhSgAN/QbTVPxOdBZirWLWKad79Xiw4O2g4Pz2gX5+i0hoWwDJnWn8= X-Received: by 10.237.58.138 with SMTP id o10mr16799155qte.190.1507622806244; Tue, 10 Oct 2017 01:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.100 with HTTP; Tue, 10 Oct 2017 01:06:45 -0700 (PDT) Received: by 10.12.163.100 with HTTP; Tue, 10 Oct 2017 01:06:45 -0700 (PDT) In-Reply-To: <201710091632.v99GWaUK078853@pdx.rh.CN85.dnsmgr.net> References: <201710091632.v99GWaUK078853@pdx.rh.CN85.dnsmgr.net> From: Jeremie Le Hen Date: Tue, 10 Oct 2017 10:06:45 +0200 Message-ID: Subject: Re: rtools were deemed almost unused 15 years ago... To: "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org, "Julian H. Stacey" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 08:06:47 -0000 On Oct 9, 2017 18:33, "Rodney W. Grimes" wrote: > On Wed, Oct 4, 2017 at 12:35 PM, Julian H. Stacey wrote: > >> Have you picked up the recent changes to the code in your port? > >> > >> ----- Jeremie Le Hen's Original Message ----- > >> > I've slacked a bit but here we are: > >> > https://reviews.freebsd.org/D12573 > >> >=20 > >> > On Sat, Jul 1, 2017 at 12:08 PM, Jeremie Le Hen wrote: > >> > > On Sat, Jun 24, 2017 at 10:29 PM, Jeremie Le Hen wrot= > >> e: > >> > >> So the first step was to create a port with FreeBSD rcmds, here we > >> > >> are! But I need some eyes to vet it: > >> > >> https://reviews.freebsd.org/D11345 > >> > > > >> > > The port has been submitted and RCMDS are disabled by default from the > >> > > base system. > >> > > > >> > > See you in a month for the removal! > > > > > > NO ! It's maddening, code vandals periodicaly wanting to delete working code > > & pontificating what others globaly should be denied, & forced to do & not do. > > > > One example why FreeBSD should not delete rlogin & telnet etc > > 3 days ago, a host with broken sshd (bad shared libs version > > number), was rescued by ssh to trusted parent host, then rlogin > > from that parent host to underlying jail. > > > > 3rd party code vandals are Not fit to decide what code should be > > denied globaly in other peoples' environments. By all means leave off by > > default in /etc/inetd.conf as now, but do Not Vandal Delete ! > > > > BSD is not Microsoft replete with masses of clueless users. BSD > > includes skilled users who may wish to make their own risk assessments, > > without interference. > > I know I shouldn't be replying to this message but I will do it > nonetheless, once and for all. > > You can install net/bsdrcmds and be happy again. I've even modified > inetd.conf(5) to use the path of the port's binary. You added yet another wrong assumption that ports must live in /usr/local to the base system, something that was irradicated 20 years ago and has slowly crept back in over the decades. Leaving it to /usr/libexec would have forced all users to change it. Presetting it to /usr/local where I suppose 95% of users install their ports is just an optimization for the most common case. If you have a better default in mind, please go ahead, I don't have strong feelings about it. > > This was announced and approved. Disabling it from inetd.conf(5) > wouldn't have solved the setuid issue. I suggest you re-read the > original email explaining the proposal: > https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html > > It surely displeases a small percentage of users but this reduces the > attack surface for 100% of them. Additionally, it reduces the FreeBSD > project maintenance cost > > -- Jeremie > > > > > > > Cheers, > > Julian > > -- > > Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich > > Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. > > http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU. > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > -- > Jeremie Le Hen > jlh@FreeBSD.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org _______________________________________________ freebsd-arch@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Tue Oct 10 13:20:27 2017 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 32761E31494 for ; Tue, 10 Oct 2017 13:20:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 E924981CED for ; Tue, 10 Oct 2017 13:20:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id g18so2438979itg.5 for ; Tue, 10 Oct 2017 06:20:26 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=GDdQdjps+OylR2ssje4/fxAYXyUBtkzDw3UXFby7ODI=; b=yXNOOrNAWfcYk6ZBHbm49/5uQTGKN6tEjs1RUos1WooKPTq+2ucHoGjyofLHfqFmh1 5nTajYGCXF4bdeIT3qygJLrvlq5PYMcM00yUO2j4c2xb0As+K7HPm59b3SA1K3h8Lmsi fagfLhiLIxZ5QTkNZ/G6aisB/DiIWK+PP3AFAyjviGYyCAsWkl5qo4Y5UKvf3GmrV7om 9gNJDOsHVvZz0ZsvaDlIIr3tOzxZtYtXA3Md8yNtnslWbLunOTMjpuzwWSyn3PaNtgnv Lkpgwu2mdMrO3HD4bnW036hb7AiMQedsd+Yz+3Y3y791E5eMZSSvhzJYXJjVV6FeAuXY IOkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GDdQdjps+OylR2ssje4/fxAYXyUBtkzDw3UXFby7ODI=; b=WNA+obnVTjU+1YAMuLKOaqsqNh5te00yQBtH64a64nwpq7Y7MVJ1Yf4EHRohOOnDpr 6lxc/f8Cd6QCQzqathINpXDE9RSy3ezJo2fJrscZ0rp1jPhiZLw6Fhux9y+NWQPOIFcs /DASG9Mf8J1lLi1gx07fSnbSKvL7JuW4ZsMbKIkqctGztb8XNRHkCWDaIG07Y5DRhfJC kvTx0zmFK6TyUMijKrTO+izM7vgU8Z2Cx8WJ/VQ0IU96b3JlatLBHmXmeJpRBkyQEFM8 3WCXxnN4N6AdITlW3lPlp+ObEDwf/ouucoZiUMAhdJXkRPOo26tSIB2VMbtY9OHvjOnJ hsjg== X-Gm-Message-State: AMCzsaVp8SZgivmycDsc6/QspUPQPS/g1//ownaRQXDanAcrpG7lodcS 3p+VMmo8jJK6TTa0h8DHOTc7bmViA6fMKGCkcfSEKA== X-Google-Smtp-Source: AOwi7QAbU/OKKPK+y/xhMignbHUQ4syK5Yt0BvUkyltAmnVOUP7TOJlDg1ku5qSHNrVPCY+Ize90zNJo2cApPFX6zU4= X-Received: by 10.36.190.138 with SMTP id i132mr19874171itf.15.1507641626183; Tue, 10 Oct 2017 06:20:26 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Tue, 10 Oct 2017 06:20:25 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: <59DC64F1.6060706@Wilcox-Tech.com> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <59DC64F1.6060706@Wilcox-Tech.com> From: Warner Losh Date: Tue, 10 Oct 2017 07:20:25 -0600 X-Google-Sender-Auth: Wp3kXnP-U6lZ3Z1IkKrADgVwyv8 Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: "A. Wilcox" Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 13:20:27 -0000 On Tue, Oct 10, 2017 at 12:13 AM, A. Wilcox wrote: > On 10/10/17 00:56, Warner Losh wrote: > > (we have > > good infrastructure for creating mips and arm packages today I'm told > would > > be relatively easy to expand to new architectures). > > > Does this include the elusive sparc64 (if qemu were fixed, and the LLVM > issues resolved)? > If someone fixes these things, I suppose. I'm not optimistic though. Warner From owner-freebsd-arch@freebsd.org Tue Oct 10 13:50:51 2017 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 6B806E325A0 for ; Tue, 10 Oct 2017 13:50:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.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 2C80B82FDE; Tue, 10 Oct 2017 13:50:51 +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 mail.baldwin.cx (Postfix) with ESMTPSA id EE12010A8BC; Tue, 10 Oct 2017 09:50:49 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Nathan Whitehorn Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Tue, 10 Oct 2017 06:49:44 -0700 Message-ID: <1723616.qgAo6xlX2y@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> 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.4.3 (mail.baldwin.cx); Tue, 10 Oct 2017 09:50:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 13:50:51 -0000 On Monday, October 09, 2017 09:57:04 PM Nathan Whitehorn wrote: > > On 10/09/17 11:32, Warner Losh wrote: > > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" wrote: > > > > > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn > > wrote: > > > >> > >> On 10/06/17 00:20, Baptiste Daroussin wrote: > >> > >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > >>> > >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > >>>> > >>>>> I'd like to start a conversation about the viability of making C++11 a > >>>>> hard > >>>>> requirement for bootstrapping FreeBSD and setting a specific deadline > >>>>> for > >>>>> doing so. > >>>>> > >>>>> This discussion is motivated by an ask from the jemalloc folks to use a > >>>>> limited subset of C++11 inside of malloc in such a way that is C safe > >>>>> (so > >>>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing > >>>>> discussion in another forum, and isn't appropriate for this thread > >>>>> because > >>>>> this has become a frequent request (but if you have opinions, please > >>>>> find > >>>>> the thread in current@ about it). I don't know the timeline of their > >>>>> plans > >>>>> to do this. > >>>>> > >>>>> I'd like to take the rather vague plans we've had "before 12" and > >>>>> create a > >>>>> timeline for removal of gcc 4.2 coupled with a requirement for support > >>>>> in > >>>>> clang or a working external toolchain. This requirement would be coupled > >>>>> with the requirement that the external toolchain support C++11 > >>>>> constructs. > >>>>> > >>>>> I'd like to propose we do this 12/31/17. Any architectures that can't > >>>>> meet > >>>>> this timeline will be disconnected from universe at that time and > >>>>> deleted > >>>>> 3/31/18. > >>>>> > >>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are > >>>>> ready for this change and mips* would be ready for this change with an > >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect > >>>>> that > >>>>> a newer version of gcc as an external toolchain could work. > >>>>> > >>>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). > >>>> However, > >>>> it requires external ld.bfd. I know that there ld.lld can link a working > >>>> mips64 world with some patches (notably the multigot patch). mips works > >>>> fine > >>>> with external GCC. riscv is already using external GCC that is > >>>> C++11-capable. > >>>> > >>>> The problem with external GCC is that you can cross-build a world + > >>>> kernel > >>>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, > >>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ > >>>> started on ports to cross-build binutils and gcc packages via the base/* > >>>> ports, but those are not yet finished / fully tested. I don't think > >>>> anyone > >>>> has thought about how release builds will work either with only an > >>>> external > >>>> toolchain available. (I'm pretty sure sparc64 has booted fine with > >>>> external GCC, it's just in the same boat as mips with regard to > >>>> /usr/bin/cc.) > >>>> > >>> Actually I did test those and they were working (tested in qemu) they were > >>> working fine. I have given up working on them due to the lack of > >>> interested by > >>> the community (by interest I mean people really testing, working on it, > >>> not just > >>> saying "hey nice sounds cool"). > >>> > >>> As for the boot when I initially worked on external toolchain sparc64 was > >>> my > >>> guinea pig and so yes it worked an booted just fine. > >>> > >> So far as I know, we never solved any of the infrastructural problems > >> associated with this concept: > >> 1. Providing built releases with a /usr/bin/cc > >> 2. Coversioning base and in-ports toolchain, including ensuring commit > >> atomicity between toolchains and libc > >> 3. Adding a dependency on ports for src, including out-of-tree code that > >> has to be fetched from external servers > >> 4. Getting make universe to do the right thing > >> > >> We really need to solve those. If we go the external toolchain route, > >> which it is not clear to me is the best option, #2 and #1 are quite complex > >> problems. I think that, frankly, a deadline in two months to solve this set > >> of political problems we have had for two years is probably crazy, but > >> maybe making the status quo unsustainable will finally force progress. > >> > > External toolchains have been in flight for 5 or more years now. It's time > > they land. Though the requirements for them have never included > > cross-threading between /usr/src and /usr/ports like you suggest above, and > > those sorts of things won't be sorted by my deadlines (which are closer to > > 3 months). Nor, imho, should they. > > > > > > Well, sure. But the fact remains that we cannot build usable systems with > > external toolchains right now. Those are real problems that need to be > > solved somehow. > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. It is a solved > > problem. > > "Bootable" is not the same as "usable" here. External toolchain > powerpc64 *boots* fine -- and has for years -- but there isn't much you > can actual *do* with the system except admire dmesg without the ability > to install ports. > > > Let's focus on #1, the largest if not the only major problem. If I build, > > say, a ppc64 system with an external toolchain right now, it boots and runs > > fine. But the system is completely unusable since: > > - There are no binary packages built for PPC64, because of project policy > > preventing the use of native build systems > > > > > > System is still usable w/o packages. People can still fire up custom > > poudrier repos. We could also change project policy. This is is a specific > > wrinkle for powerpc64 it seems. > > How would I do that? We can't run these natively, because the system > ships without a compiler. And we can't cross-compile, because the ports > tree does not support that. The base/ ports _do_ cross-compile. See /usr/ports/base/README. You have to build a world image using the external toolchain that can then be used as a --sysroot with the external toolchain to build binutils and gcc packages. These packages should then be able to be installed. To be clear, you would build a world on an amd64 host with the foo-xtoolchain-gcc toolchain, install it to some 'rootfs' directory, then build the base/ packages on the same amd64 host but the generated packages can be installed on the target via pkg install. In particular, we could automate building of the base/ packages in the cluster and publish repositories that contain just binutils and gcc. -- John Baldwin From owner-freebsd-arch@freebsd.org Tue Oct 10 14:36:28 2017 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 EBDC4E33A91 for ; Tue, 10 Oct 2017 14:36:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 D4A1784A07 for ; Tue, 10 Oct 2017 14:36:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (s-169-232-86-189.resnet.ucla.edu [169.232.86.189]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9AEaPCs026349 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Oct 2017 07:36:26 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> From: Nathan Whitehorn Message-ID: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> Date: Tue, 10 Oct 2017 07:36:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVbxJpYtHJ5tvQSsjFQxC+icDk7PGaCdvYIB35SVRo1GSRn2FpIVfQpFZeae9PDvwy/5SPxMXu0sAOArnLtpeaB9benrQ4CeJUg= X-Sonic-ID: C;Ekz2ZMit5xGAtolQ3iMJ6w== M;UPg9Zcit5xGAtolQ3iMJ6w== 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.23 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 Oct 2017 14:36:29 -0000 On 10/09/17 22:56, Warner Losh wrote: [...] >> "Bootable" is not the same as "usable" here. External toolchain powerpc64 >> *boots* fine -- and has for years -- but there isn't much you can actual >> *do* with the system except admire dmesg without the ability to install >> ports. > > Right, and at least some of the issues with powerpc64 are non-technical. If > you have binary packages, none of the things that you point out matter. > There's an external compiler that can be installed for cross building a > system, or you have a running system that you were able to build, so > necessarily have a compiler for further bootstrapping. I think they are *all* non-technical. We just need to have some official, blessed place to get that package from. Cross-building src/ is quite a lot easier than cross-building packages, and people do generally install some of our platforms (PPC, SPARC, etc.) from install media, so it would need to be there. > But doesn't clang work well enough for this on powerpc? If not, then > wouldn't we be in the same position with or without external toolchains? No. GCC works great, however, 4.2 and higher. > Let's focus on #1, the largest if not the only major problem. If I build, >>> say, a ppc64 system with an external toolchain right now, it boots and >>> runs >>> fine. But the system is completely unusable since: >>> - There are no binary packages built for PPC64, because of project policy >>> preventing the use of native build systems >>> >>> >>> System is still usable w/o packages. People can still fire up custom >>> poudrier repos. We could also change project policy. This is is a specific >>> wrinkle for powerpc64 it seems. >>> >> How would I do that? We can't run these natively, because the system ships >> without a compiler. And we can't cross-compile, because the ports tree does >> not support that. > > Fair point about ports not supporting cross compile. I thought it > supported, though setting CC. If you can set CC, you can natively build the > packages. If not, then we should fix that. Most ports, however, just > require 'cc' to be in the path and don't much care if it is /usr/bin/cc or > /usr/local/bin/cc. Not generally. A few very specific packages work this way, but not all. You also need to bootstrap pkg somehow, which is itself a port, and binutils, and a few other things. It's almost certainly not a significant technical problem. > - You cannot cross-compile packages for PPC64, because of limitations in >>> QEMU >>> >>> >>> Then we should fix those, like we did for arm and MIPS. >>> >> That's a tremendous amount of work on a non-FreeBSD codebase. Are we now >> going to require QEMU patches from platform maintainers? > > Require? No. But other platform maintainers have fixed qemu when it was > broken for arm and mips. Sometimes Sean Bruno fixed it, other times he got > help from the port maintainer. But he really wanted packages. Yes, and that turned out to be incredibly complicated for PPC. I think there had been more heavy lifting ahead of time on Linux for ARM and MIPS, which made it easier. > - There is no compiler installed in the base system, so you cannot install >>> any software from source code >>> >>> >>> You can install it as a package. >>> >> Where do you get the package > > Well, if you have a native system, you needed one to build the system. Or maybe you downloaded the install media? All I want is for the install media to have a compiler on them or a way to get one. > Cross building is more tricky, I'll grant. A carefully curated set of > natively built compilers would suffice. > > >> - You cannot build the compiler from source, because you don't have one to >>> bootstrap from and can't get one pre-built because of the no-packages >>> problem. >>> >>> >>> If you fix the other problems, this is solved. >>> >> Yes, absolutely. But how do we solve the others? >> >> We can't ship systems like this -- how is anyone expected to be able to use >>> them? >>> >>> >>> Most systems don't build software, so there are plenty of uses. >>> >> I think all systems *install* software. If we don't have packages, then it >> has to be buildable from source and we need a compiler. We just can't close >> *both* paths. > > And the paths to get packages are solvable problems. They *should* be. There has been a policy brick wall on this for the last five years, which is why we *still* don't have any of this. > >> These are easy to fix -- for example, here are three possibilities -- but >>> solutions been held up for *years* by project policy: >>> 1. Allow Tier-2 packages to be built on native hardware without as much >>> centralized control, letting pkg install of the toolchain work. This fixes >>> ppc64, but maybe not embedded systems. >>> >>> >>> If we can't build in QEMU then sure. It doesn't matter where the binaries >>> come from, so long as they work. >>> >> Yes, agreed. This has not been project policy thus far, however. > > Policy changes all the time. As pointed out in other email, though, it's > more complicated and at least partially political. Yes. But this one, now, needs to be solved. If we can get a commitment from core@ to allow at least one of the options I outlined above by the deadline, I will be ecstatic. I do not think we can move forward otherwise. [...] >>> timeline, but wanting 100% full integration from external toolchain with >>> full packages isn't a gating factor here. >>> >> Absolutely! I don't want to make the perfect the enemy of the good, >> especially when the good is finally freeing ourselves from GCC 4.2. But we >> have been blocked for years by the fact that we have not been able, as a >> result of basically purely policy issues, to find a way to bootstrap a GCC >> 4.2-less system so that ports can be installed. And, as much as I like >> running fortune, I think not being able to install 3rd-party software is a >> blocker. > > Policy can be changed. > > Besides, I thought powerpc64 just worked with clang... It does not. It has been 90% of the way there for 6 years, but still is not there. >> Unfortunately, no. There are a wide variety of subtle issues. You can boot >> a kernel built with -O0, but higher optimization levels or userland code >> (especially C++) break. >> > C++ isn't needed to boostrap gcc. No, but it is needed to build clang, which it can't currently do. You also can't build a working kernel or libc. I haven't tried to build GCC with it lately, but the last time I tried, that also didn't work. > > >> Warner >>> Also, are there any directions for how to build a toolchain from the base >>> >>>> ports? I haven't been able to figure it out -- the README starts with >>>> "pkg >>>> install", but that doesn't get me very far on platforms without binary >>>> packages, which are the ones this is meant to target. >>>> >>> External toolchains are by definition external. Not part of the tree nor >>> integrated into the tree. How you get them depends on the external >>> toolchain and is unspecified. You get a lower level of integration than >>> you >>> do with in-tree toolchains, not the same level with reach-overs into some >>> external repo. >>> >>> >>> I think you missed the point. I was asking how to build the port to test >>> it >>> -- it doesn't build at present and I can't figure out how to make an >>> external toolchain via the "base" ports (the other toolchains in ports >>> work >>> fine). >>> -Nathan >>> >>> Warner >>> > I guess I'm looking for an actionable set of blockers with a timetable for > resolution. These all sound a lot like inconvenient problems stemming from > some bad choices of project controlled equipment. External toolchains could > be supplied by third parties as packages. That would solve much of the > bootstrapping problem. Some time spent fixing the bugs in qemu that keep it > from being a viable option would also open up a flood of packages (we have > good infrastructure for creating mips and arm packages today I'm told would > be relatively easy to expand to new architectures). > > However, absent a clear plan, as well as resourced dedicated to realize it, > I'm not sure that we should block things further based strictly on a list > of things that are broken. If there's a plan to fix, I'm willing to defer > to give that plan a chance to happen. In the absence of a specific plan > with timelines, I'm reluctant to indefinitely delay the negotiated plan for > 12 which has taken years to pull together. Otherwise, is 3 more months > enough? Is 6? are 12? Do we wait for FreeBSD 13? > I think we can fix the problem, which is severe, in a week if we can get a commitment from core@ to allow at least one of the following things: 1. Package sets (potentially only very minimal ones) uploaded for tier-2 systems from machines not controlled and hosted by portmaster, but otherwise project-affiliated (like our PPC build systems). 2. The "base" ports built as part of the release/snapshot process and either included on the media (better) or, at the least, available on the official package repositories. 3. Allow inclusion of the compiler either in src or in another project-hosted repository connected to src (I realize this isn't external toolchain, but it does still allow us to remove GCC 4.2 without making the system unusable) I am quite happy to do the technical work personally to enable one or all of these, but at present cannot do so because project policy prevents it and has done for a very, very long time. -Nathan From owner-freebsd-arch@freebsd.org Tue Oct 10 18:16:40 2017 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 E01B8E3929E for ; Tue, 10 Oct 2017 18:16:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 B907166AF3; Tue, 10 Oct 2017 18:16:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 0CC585A9F27; Tue, 10 Oct 2017 18:16:39 +0000 (UTC) Date: Tue, 10 Oct 2017 18:16:39 +0000 From: Brooks Davis To: John Baldwin Cc: freebsd-arch@freebsd.org, Nathan Whitehorn Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171010181638.GD68389@spindle.one-eyed-alien.net> References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: <1723616.qgAo6xlX2y@ralph.baldwin.cx> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 18:16:41 -0000 --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 10, 2017 at 06:49:44AM -0700, John Baldwin wrote: > On Monday, October 09, 2017 09:57:04 PM Nathan Whitehorn wrote: > >=20 > > On 10/09/17 11:32, Warner Losh wrote: > > > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" = wrote: > > > > > > > > > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > > > > > > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn > > > wrote: > > > > > >> > > >> On 10/06/17 00:20, Baptiste Daroussin wrote: > > >> > > >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > > >>> > > >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > > >>>> > > >>>>> I'd like to start a conversation about the viability of making C+= +11 a > > >>>>> hard > > >>>>> requirement for bootstrapping FreeBSD and setting a specific dead= line > > >>>>> for > > >>>>> doing so. > > >>>>> > > >>>>> This discussion is motivated by an ask from the jemalloc folks to= use a > > >>>>> limited subset of C++11 inside of malloc in such a way that is C = safe > > >>>>> (so > > >>>>> the C programs wouldn't bloat with a C++ runtime). That's an ongo= ing > > >>>>> discussion in another forum, and isn't appropriate for this thread > > >>>>> because > > >>>>> this has become a frequent request (but if you have opinions, ple= ase > > >>>>> find > > >>>>> the thread in current@ about it). I don't know the timeline of th= eir > > >>>>> plans > > >>>>> to do this. > > >>>>> > > >>>>> I'd like to take the rather vague plans we've had "before 12" and > > >>>>> create a > > >>>>> timeline for removal of gcc 4.2 coupled with a requirement for su= pport > > >>>>> in > > >>>>> clang or a working external toolchain. This requirement would be = coupled > > >>>>> with the requirement that the external toolchain support C++11 > > >>>>> constructs. > > >>>>> > > >>>>> I'd like to propose we do this 12/31/17. Any architectures that c= an't > > >>>>> meet > > >>>>> this timeline will be disconnected from universe at that time and > > >>>>> deleted > > >>>>> 3/31/18. > > >>>>> > > >>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerp= c64 are > > >>>>> ready for this change and mips* would be ready for this change wi= th an > > >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but su= spect > > >>>>> that > > >>>>> a newer version of gcc as an external toolchain could work. > > >>>>> > > >>>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches= ). > > >>>> However, > > >>>> it requires external ld.bfd. I know that there ld.lld can link a = working > > >>>> mips64 world with some patches (notably the multigot patch). mips= works > > >>>> fine > > >>>> with external GCC. riscv is already using external GCC that is > > >>>> C++11-capable. > > >>>> > > >>>> The problem with external GCC is that you can cross-build a world + > > >>>> kernel > > >>>> just fine and get a working system via CROSS_TOOLCHAIN=3Dfoo-gcc. = However, > > >>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. = bapt@ > > >>>> started on ports to cross-build binutils and gcc packages via the = base/* > > >>>> ports, but those are not yet finished / fully tested. I don't thi= nk > > >>>> anyone > > >>>> has thought about how release builds will work either with only an > > >>>> external > > >>>> toolchain available. (I'm pretty sure sparc64 has booted fine with > > >>>> external GCC, it's just in the same boat as mips with regard to > > >>>> /usr/bin/cc.) > > >>>> > > >>> Actually I did test those and they were working (tested in qemu) th= ey were > > >>> working fine. I have given up working on them due to the lack of > > >>> interested by > > >>> the community (by interest I mean people really testing, working on= it, > > >>> not just > > >>> saying "hey nice sounds cool"). > > >>> > > >>> As for the boot when I initially worked on external toolchain sparc= 64 was > > >>> my > > >>> guinea pig and so yes it worked an booted just fine. > > >>> > > >> So far as I know, we never solved any of the infrastructural problems > > >> associated with this concept: > > >> 1. Providing built releases with a /usr/bin/cc > > >> 2. Coversioning base and in-ports toolchain, including ensuring comm= it > > >> atomicity between toolchains and libc > > >> 3. Adding a dependency on ports for src, including out-of-tree code = that > > >> has to be fetched from external servers > > >> 4. Getting make universe to do the right thing > > >> > > >> We really need to solve those. If we go the external toolchain route, > > >> which it is not clear to me is the best option, #2 and #1 are quite = complex > > >> problems. I think that, frankly, a deadline in two months to solve t= his set > > >> of political problems we have had for two years is probably crazy, b= ut > > >> maybe making the status quo unsustainable will finally force progres= s. > > >> > > > External toolchains have been in flight for 5 or more years now. It's= time > > > they land. Though the requirements for them have never included > > > cross-threading between /usr/src and /usr/ports like you suggest abov= e, and > > > those sorts of things won't be sorted by my deadlines (which are clos= er to > > > 3 months). Nor, imho, should they. > > > > > > > > > Well, sure. But the fact remains that we cannot build usable systems = with > > > external toolchains right now. Those are real problems that need to be > > > solved somehow. > > > > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. It is a so= lved > > > problem. > >=20 > > "Bootable" is not the same as "usable" here. External toolchain=20 > > powerpc64 *boots* fine -- and has for years -- but there isn't much you= =20 > > can actual *do* with the system except admire dmesg without the ability= =20 > > to install ports. > >=20 > > > Let's focus on #1, the largest if not the only major problem. If I bu= ild, > > > say, a ppc64 system with an external toolchain right now, it boots an= d runs > > > fine. But the system is completely unusable since: > > > - There are no binary packages built for PPC64, because of project po= licy > > > preventing the use of native build systems > > > > > > > > > System is still usable w/o packages. People can still fire up custom > > > poudrier repos. We could also change project policy. This is is a spe= cific > > > wrinkle for powerpc64 it seems. > >=20 > > How would I do that? We can't run these natively, because the system=20 > > ships without a compiler. And we can't cross-compile, because the ports= =20 > > tree does not support that. >=20 > The base/ ports _do_ cross-compile. See /usr/ports/base/README. You hav= e to > build a world image using the external toolchain that can then be used as= a > --sysroot with the external toolchain to build binutils and gcc packages. > These packages should then be able to be installed. To be clear, you wou= ld > build a world on an amd64 host with the foo-xtoolchain-gcc toolchain, ins= tall > it to some 'rootfs' directory, then build the base/ packages on the same > amd64 host but the generated packages can be installed on the target via > pkg install. In particular, we could automate building of the base/ pack= ages > in the cluster and publish repositories that contain just binutils and gc= c. I think building and publishing mini-repositories of pkg and "the things required to cross build a release" is a must. We should include the repo along side the releasese in the FTP[0] hierarchy. It's fairly straightforward and we should do it. -- Brooks [0] Can we please stop using this ancient protocol before we are the last signficant project using it and it is blocked by every enterprise firewall. --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZ3Q6GAAoJEKzQXbSebgfAB2IIAINfDEEsWdLGRfk0x4HzJBK9 mkxAfAwrqaeJLdbAAaOKIMtH/rbHJfLW0aIw70PUj42OqhVogxOhEmbB+XpLGv8E Hn5Malyr1zHlgBnSl74sel9MfVMGUduQ1LVLFkF8nrXPgChtHUSZtySe6tBWmzhA 3BY761z69xp04MPllJvtfeitYie/Q6QybTFmuoiLoanQWrCIrC8TQ9kIlk7SdQAX cqrTD6ym5Tmr+/5nsNunjwr/1q2e02KZaeMJhGDeH2mbLHtdHjWT0T6MmPjDCxgT xYFFE/G06LBsW4zWN/tx+dvcAuTZwXlN96Hu6zDfyA/SfZZp5UhNIs6RWgdi2cc= =vq9B -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy-- From owner-freebsd-arch@freebsd.org Tue Oct 10 19:27:25 2017 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 7A80FE3AE73 for ; Tue, 10 Oct 2017 19:27:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 47234698BA for ; Tue, 10 Oct 2017 19:27:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id y15so3914739ita.4 for ; Tue, 10 Oct 2017 12:27:25 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=jk61o00SVnLlpf9DtBbNYA434uG8CD+d0/m3VghOumg=; b=gx1pEtJMN8Cskuj9qhgoLEKcIrwfBkuQkLFw/leUTkw18uhe9qb0FOVZMDe6nDEY6o iuRc1xguIx4KPKQSCWam8pOylYbLaZlp4lDHPmElZpMXkIS193XtIeb0MvxYtI+zSHT2 ks3yblQrRTY9ckmsFGl3vL2KJ5CPUZL/ORz06wBc08Y60iwJoMGhK7Wl/NNM0cNwdAGG Mg3XU2f+2N8NaTb4SyTeGysOVnTeWfAwCLB7i6tAWE0ku1TTvnpgmmfNfyU0dSxnXhUB r+HCOlike/n8LT3TpuwrB3ihv7+WGfIj2dEWjx6OuWZ4QVb3FdXy5heyRBwN7fdsh/G/ DL2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jk61o00SVnLlpf9DtBbNYA434uG8CD+d0/m3VghOumg=; b=gFTbM+0V+jZJrHfKwj83Ws7cBztyT3ICqCPDqqyMp5GgXBxyMKh6psc61dAMRidZA/ GriyDFT8SGN3tAlcAzkABMVvfgmNYkgO9FxV39B5sNWxXYGx+tNU2YPklrsbW5/hfPJt Bgxmtpelxbk9Jnrx9YHiY4EuTJ+oT/A0vZRzeq6QuXIVJd/eEMJXBuJyCCUbxfZDpcYm tHN30axbxChSjuO5Sm5Dh7u8/Gy7Yynqw9Uxq69Vj594jEzFPEfk32TY7ucMOCL4JA+N ihKovi85LzQkyDQ3vcdHKNshgNhtS6TDldzDtshLNK4n0KVL+x61VxpcCcb/lujAplyf bH7Q== X-Gm-Message-State: AMCzsaVMDIJBeXonQnM+pjIfMSbNtYBidx0YYNqt8Jf4oHt9R5qDrqYN 5qfIABzDLS6wYi07sp/gHsQzqVxJ7hG5JK3BHZKMAA== X-Google-Smtp-Source: AOwi7QASnadHVN9JdEb8GFTzFHZmOLuQJyBKGRPlbsOANLkM2uP20AgbbUBdnzHg4a1XCupNQ8Y5j2/uuNsd21fUQc0= X-Received: by 10.36.190.138 with SMTP id i132mr21557779itf.15.1507663644444; Tue, 10 Oct 2017 12:27:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Tue, 10 Oct 2017 12:27:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:4920:aead:e4cc:fa29] In-Reply-To: <20171010181638.GD68389@spindle.one-eyed-alien.net> References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> <20171010181638.GD68389@spindle.one-eyed-alien.net> From: Warner Losh Date: Tue, 10 Oct 2017 13:27:23 -0600 X-Google-Sender-Auth: Cpj8-U-e4-nm_BAqaE1SHfagTeg Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Brooks Davis Cc: John Baldwin , Nathan Whitehorn , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 19:27:25 -0000 On Tue, Oct 10, 2017 at 12:16 PM, Brooks Davis wrote: > On Tue, Oct 10, 2017 at 06:49:44AM -0700, John Baldwin wrote: > > On Monday, October 09, 2017 09:57:04 PM Nathan Whitehorn wrote: > > > > > > On 10/09/17 11:32, Warner Losh wrote: > > > > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" > wrote: > > > > > > > > > > > > > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > > > > > > > > > > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn < > nwhitehorn@freebsd.org> > > > > wrote: > > > > > > > >> > > > >> On 10/06/17 00:20, Baptiste Daroussin wrote: > > > >> > > > >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > > > >>> > > > >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > > > >>>> > > > >>>>> I'd like to start a conversation about the viability of making > C++11 a > > > >>>>> hard > > > >>>>> requirement for bootstrapping FreeBSD and setting a specific > deadline > > > >>>>> for > > > >>>>> doing so. > > > >>>>> > > > >>>>> This discussion is motivated by an ask from the jemalloc folks > to use a > > > >>>>> limited subset of C++11 inside of malloc in such a way that is C > safe > > > >>>>> (so > > > >>>>> the C programs wouldn't bloat with a C++ runtime). That's an > ongoing > > > >>>>> discussion in another forum, and isn't appropriate for this > thread > > > >>>>> because > > > >>>>> this has become a frequent request (but if you have opinions, > please > > > >>>>> find > > > >>>>> the thread in current@ about it). I don't know the timeline of > their > > > >>>>> plans > > > >>>>> to do this. > > > >>>>> > > > >>>>> I'd like to take the rather vague plans we've had "before 12" and > > > >>>>> create a > > > >>>>> timeline for removal of gcc 4.2 coupled with a requirement for > support > > > >>>>> in > > > >>>>> clang or a working external toolchain. This requirement would be > coupled > > > >>>>> with the requirement that the external toolchain support C++11 > > > >>>>> constructs. > > > >>>>> > > > >>>>> I'd like to propose we do this 12/31/17. Any architectures that > can't > > > >>>>> meet > > > >>>>> this timeline will be disconnected from universe at that time and > > > >>>>> deleted > > > >>>>> 3/31/18. > > > >>>>> > > > >>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and > powerpc64 are > > > >>>>> ready for this change and mips* would be ready for this change > with an > > > >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but > suspect > > > >>>>> that > > > >>>>> a newer version of gcc as an external toolchain could work. > > > >>>>> > > > >>>> In-tree clang 5.0 for MIPS mostly works (modulo some small > patches). > > > >>>> However, > > > >>>> it requires external ld.bfd. I know that there ld.lld can link a > working > > > >>>> mips64 world with some patches (notably the multigot patch). > mips works > > > >>>> fine > > > >>>> with external GCC. riscv is already using external GCC that is > > > >>>> C++11-capable. > > > >>>> > > > >>>> The problem with external GCC is that you can cross-build a world > + > > > >>>> kernel > > > >>>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. > However, > > > >>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. > bapt@ > > > >>>> started on ports to cross-build binutils and gcc packages via the > base/* > > > >>>> ports, but those are not yet finished / fully tested. I don't > think > > > >>>> anyone > > > >>>> has thought about how release builds will work either with only an > > > >>>> external > > > >>>> toolchain available. (I'm pretty sure sparc64 has booted fine > with > > > >>>> external GCC, it's just in the same boat as mips with regard to > > > >>>> /usr/bin/cc.) > > > >>>> > > > >>> Actually I did test those and they were working (tested in qemu) > they were > > > >>> working fine. I have given up working on them due to the lack of > > > >>> interested by > > > >>> the community (by interest I mean people really testing, working > on it, > > > >>> not just > > > >>> saying "hey nice sounds cool"). > > > >>> > > > >>> As for the boot when I initially worked on external toolchain > sparc64 was > > > >>> my > > > >>> guinea pig and so yes it worked an booted just fine. > > > >>> > > > >> So far as I know, we never solved any of the infrastructural > problems > > > >> associated with this concept: > > > >> 1. Providing built releases with a /usr/bin/cc > > > >> 2. Coversioning base and in-ports toolchain, including ensuring > commit > > > >> atomicity between toolchains and libc > > > >> 3. Adding a dependency on ports for src, including out-of-tree code > that > > > >> has to be fetched from external servers > > > >> 4. Getting make universe to do the right thing > > > >> > > > >> We really need to solve those. If we go the external toolchain > route, > > > >> which it is not clear to me is the best option, #2 and #1 are quite > complex > > > >> problems. I think that, frankly, a deadline in two months to solve > this set > > > >> of political problems we have had for two years is probably crazy, > but > > > >> maybe making the status quo unsustainable will finally force > progress. > > > >> > > > > External toolchains have been in flight for 5 or more years now. > It's time > > > > they land. Though the requirements for them have never included > > > > cross-threading between /usr/src and /usr/ports like you suggest > above, and > > > > those sorts of things won't be sorted by my deadlines (which are > closer to > > > > 3 months). Nor, imho, should they. > > > > > > > > > > > > Well, sure. But the fact remains that we cannot build usable systems > with > > > > external toolchains right now. Those are real problems that need to > be > > > > solved somehow. > > > > > > > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. It is a > solved > > > > problem. > > > > > > "Bootable" is not the same as "usable" here. External toolchain > > > powerpc64 *boots* fine -- and has for years -- but there isn't much you > > > can actual *do* with the system except admire dmesg without the ability > > > to install ports. > > > > > > > Let's focus on #1, the largest if not the only major problem. If I > build, > > > > say, a ppc64 system with an external toolchain right now, it boots > and runs > > > > fine. But the system is completely unusable since: > > > > - There are no binary packages built for PPC64, because of project > policy > > > > preventing the use of native build systems > > > > > > > > > > > > System is still usable w/o packages. People can still fire up custom > > > > poudrier repos. We could also change project policy. This is is a > specific > > > > wrinkle for powerpc64 it seems. > > > > > > How would I do that? We can't run these natively, because the system > > > ships without a compiler. And we can't cross-compile, because the ports > > > tree does not support that. > > > > The base/ ports _do_ cross-compile. See /usr/ports/base/README. You > have to > > build a world image using the external toolchain that can then be used > as a > > --sysroot with the external toolchain to build binutils and gcc packages. > > These packages should then be able to be installed. To be clear, you > would > > build a world on an amd64 host with the foo-xtoolchain-gcc toolchain, > install > > it to some 'rootfs' directory, then build the base/ packages on the same > > amd64 host but the generated packages can be installed on the target via > > pkg install. In particular, we could automate building of the base/ > packages > > in the cluster and publish repositories that contain just binutils and > gcc. > > I think building and publishing mini-repositories of pkg and "the things > required to cross build a release" is a must. We should include the > repo along side the releasese in the FTP[0] hierarchy. It's fairly > straightforward and we should do it. > > -- Brooks > > [0] Can we please stop using this ancient protocol before we are the > last signficant project using it and it is blocked by every enterprise > firewall. > Given that PowerPC is a tier 2 architecture, I'm not sure that I'd call it a MUST. It's nice to have, and really useful if we have it. But Tier 2 is best effort to support, so it isn't a "must" in the sense it is a hard blocker for the removal of gcc. However, if there's plans in flight to do this, I'll let the complete (or timeout) before moving forward with any deorbiting. So long as there's a concrete timeline of reasonable things, I'm happy to defer to allow that to proceed. What I don't want to do is defer to some vague plans by some unnamed individuals that might get around to it, but we're blocked on that... Warner From owner-freebsd-arch@freebsd.org Tue Oct 10 21:14:38 2017 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 E255EE3D331; Tue, 10 Oct 2017 21:14:38 +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 7B98C6D1DD; Tue, 10 Oct 2017 21:14:37 +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 v9ALESn3086415 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Oct 2017 23:14:28 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id v9ALESWT086414; Tue, 10 Oct 2017 23:14:28 +0200 (CEST) (envelope-from marius) Date: Tue, 10 Oct 2017 23:14:28 +0200 From: Marius Strobl To: Mark Linimon Cc: Gerald Pfeifer , "A. Wilcox" , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171010211428.GA51868@alchemy.franken.de> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171007174124.GA20810@lonesome.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 21:14:39 -0000 On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: > > All gccs > 4.9 fail to build. Looking at the logs AFAICT the failure > is a floating-point exception as soon as the first built binary is run > during the internal testing. The most plausible cause for that is executables and/or dynamic libraries not installing the user trap handlers as specified by the libc 64 psABI, i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their own CRT nowadays? Do they no longer link libc last? Please provide their linker invocation. Also, please provide the backtrace of a minimal program exhibiting that problem. Marius From owner-freebsd-arch@freebsd.org Tue Oct 10 22:30:32 2017 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 AC17EE3F00F for ; Tue, 10 Oct 2017 22:30:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 932B46F953; Tue, 10 Oct 2017 22:30:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from helicon.physics.ucla.edu (helicon.physics.ucla.edu [169.232.156.253]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9AMUStv011765 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Oct 2017 15:30:29 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: Warner Losh , Brooks Davis Cc: John Baldwin , "freebsd-arch@freebsd.org" References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> <20171010181638.GD68389@spindle.one-eyed-alien.net> From: Nathan Whitehorn Message-ID: <347c5440-ec85-8912-6621-d9c057f58493@freebsd.org> Date: Tue, 10 Oct 2017 15:30:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYfVat1Ygleatpo2WoDIepyw0PasePoNqneCEurO/6g5jH0VtUlxYQNRopW+9nRrwixVSdpcvycrTKvFynBUzKKVWPXm7ZutFE= X-Sonic-ID: C;iEEengqu5xGvOYlQ3iMJ6w== M;0qKzngqu5xGvOYlQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 22:30:32 -0000 On 10/10/17 12:27, Warner Losh wrote: > > [...] > > > > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. > It is a solved > > > > problem. > > > > > > "Bootable" is not the same as "usable" here. External toolchain > > > powerpc64 *boots* fine -- and has for years -- but there isn't > much you > > > can actually *do* with the system except admire dmesg without > the ability > > > to install ports. > > > > > > > Let's focus on #1, the largest if not the only major > problem. If I build, > > > > say, a ppc64 system with an external toolchain right now, it > boots and runs > > > > fine. But the system is completely unusable since: > > > > - There are no binary packages built for PPC64, because of > project policy > > > > preventing the use of native build systems > > > > > > > > > > > > System is still usable w/o packages. People can still fire > up custom > > > > poudrier repos. We could also change project policy. This is > is a specific > > > > wrinkle for powerpc64 it seems. > > > > > > How would I do that? We can't run these natively, because the > system > > > ships without a compiler. And we can't cross-compile, because > the ports > > > tree does not support that. > > > > The base/ ports _do_ cross-compile.  See > /usr/ports/base/README.  You have to > > build a world image using the external toolchain that can then > be used as a > > --sysroot with the external toolchain to build binutils and gcc > packages. > > These packages should then be able to be installed.  To be > clear, you would > > build a world on an amd64 host with the foo-xtoolchain-gcc > toolchain, install > > it to some 'rootfs' directory, then build the base/ packages on > the same > > amd64 host but the generated packages can be installed on the > target via > > pkg install.  In particular, we could automate building of the > base/ packages > > in the cluster and publish repositories that contain just > binutils and gcc. > > I think building and publishing mini-repositories of pkg and "the > things > required to cross build a release" is a must.  We should include the > repo along side the releasese in the FTP[0] hierarchy. It's fairly > straightforward and we should do it. > > -- Brooks > > [0] Can we please stop using this ancient protocol before we are the > last signficant project using it and it is blocked by every enterprise > firewall. > > > Given that PowerPC is a tier 2 architecture, I'm not sure that I'd > call it a MUST. It's nice to have, and really useful if we have it. > But Tier 2 is best effort to support, so it isn't a "must" in the > sense it is a hard blocker for the removal of gcc. > > However, if there's plans in flight to do this, I'll let the complete > (or timeout) before moving forward with any deorbiting. So long as > there's a concrete timeline of reasonable things, I'm happy to defer > to allow that to proceed. What I don't want to do is defer to some > vague plans by some unnamed individuals that might get around to it, > but we're blocked on that... > > Warner This problem applies to all architectures except ARM and x86 and removal of the compiler from the base system without doing something like this will make any installed system unusable. It should be a blocker. We have multiple volunteers to do the work, which, as Brooks notes, is super easy, but need a change in project policy, which has prevented the work in question from being done for many years. If you include that policy change as part of your proposal, I am very happy to support it. -Nathan From owner-freebsd-arch@freebsd.org Tue Oct 10 23:53:01 2017 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 785F9E40A69 for ; Tue, 10 Oct 2017 23:53:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (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 537B671A67; Tue, 10 Oct 2017 23:53:00 +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 mail.baldwin.cx (Postfix) with ESMTPSA id 1AADA10A8BC; Tue, 10 Oct 2017 19:52:53 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Nathan Whitehorn Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Tue, 10 Oct 2017 16:26:10 -0700 Message-ID: <1966623.eKrA7uLGIR@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> References: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> 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.4.3 (mail.baldwin.cx); Tue, 10 Oct 2017 19:52:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 23:53:01 -0000 On Tuesday, October 10, 2017 07:36:25 AM Nathan Whitehorn wrote: > I think we can fix the problem, which is severe, in a week if we can get > a commitment from core@ to allow at least one of the following things: > > 1. Package sets (potentially only very minimal ones) uploaded for tier-2 > systems from machines not controlled and hosted by portmaster, but > otherwise project-affiliated (like our PPC build systems). > 2. The "base" ports built as part of the release/snapshot process and > either included on the media (better) or, at the least, available on the > official package repositories. > 3. Allow inclusion of the compiler either in src or in another > project-hosted repository connected to src (I realize this isn't > external toolchain, but it does still allow us to remove GCC 4.2 without > making the system unusable) I would prefer 2) as I think that is most consistent with what other folks have been pushing towards. I would be fine if we just hosted them in repositories so that 'pkg install' worked out of the box. At least if we start building them and publishing the repositories I think it is much easier to do more testing of them. Eventually we may also want them on the install media along with the base system dists, but just having them regularly built and published would be a good first step. I would propose that we build the sysroot required using the foo-xtoolchain-gcc toolchains. We don't yet produce any install images for MIPS. If we did I would advocate that we start providing release snapshots built using mips-xtoolchain-gcc (make CROSS_TOOLCHAIN=blah) and use the base dist from those releases as the sysroot to also build the base/ packages and provide those in a repository. I think that same approach could be perhaps more readily adopted for powerpc. That is, cross-building releases using powerpc-xtoolchain-gcc and then using the resulting base dist as a sysroot to build the base/ packages and publishing both of those as our snapshots for current. I suspect our release generation bits don't yet understand CROSS_TOOLCHAIN and probably will need some changes to handle that. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Oct 11 02:36:52 2017 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 7FB0FE43DF0 for ; Wed, 11 Oct 2017 02:36:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 4C05C75963 for ; Wed, 11 Oct 2017 02:36:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id 72so1115456itl.5 for ; Tue, 10 Oct 2017 19:36:52 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=39kUIgakKj4YZd9uV37Td2KjvnpZRZyvZkRHKQ7nfQM=; b=OWc4puZiIZT/QRb6OmgK7LLCqLd4poptRRSQACV9j4XWyWcKUteLvK7678QRK9H9vt 6wMBl+tnsdLMxlwHDWMyEwkJFkCjIykXJE+S8gxHg4Lvtu96OQjnq7mLq+NxNqJOepLQ fLgDKUa9vqroGZ6+GD6A74cUH9Z8eNENcri6NR1a9+xJpALHgu2D1bPanp0c4J2Cq8+3 OzUqEbufMdwsFlb3AbvwN8DkkhTWQ1os75n1k+wq55lXM07jReFr19zoNaEGLv2UvZig 7PNdjoj66/RAeARezxgbRoPTDMTCl0p+fckpmAzMJuwIxOpb4VMqfbaHJvYtT0JAuNh1 vzkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=39kUIgakKj4YZd9uV37Td2KjvnpZRZyvZkRHKQ7nfQM=; b=kvu9+oTcwDsvAFqhJD1Wm2d2q6ZjYftF8BBkHjKjbmpiOHslra6X1VYeAXuW0O2fnW OvAgi9O+dciKVABLL/ilAa0eIX3KdDvRrqOgMKyu17vnbMzdngRnyhD/Lb9DeGRvU/K1 lyGxOxwTqrWdptimWBSPE6t55WoAVvgOB4ZnflCfNGBZgeca6ftYGf3psdtR4x+dzuwe FWNMo9hzFhMkpLa1ZPx90VJr0HdCbm0DnFabzV2EHuLeoS6uwKTnNfSefUh4bxDhB1Iu MwkoPdtzhn69TZH0OEVSSTyEgNNqMgvPGYWxMN6Eb/a+3SDkTEoruAcu7Cxqck0hHd9P SDsg== X-Gm-Message-State: AMCzsaUCJh89qsHEmrInmFylQn0q4y7MuwRj8OfnQ204KJHNbeUf2eYM hXhiM2FgjNHU5CcCgFM5+VlGUxl24/TjzAAzGbPysw== X-Google-Smtp-Source: AOwi7QDhpjpwzvKxuQ/O7u5nWwi4nbmaEmjff7RES1ZeAMEWwjzBKjAEllerLU50ejFE702qNcQLdOA0eREVDZ4melc= X-Received: by 10.36.69.163 with SMTP id c35mr19814927itd.63.1507689411334; Tue, 10 Oct 2017 19:36:51 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Tue, 10 Oct 2017 19:36:50 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: <1966623.eKrA7uLGIR@ralph.baldwin.cx> References: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> <1966623.eKrA7uLGIR@ralph.baldwin.cx> From: Warner Losh Date: Tue, 10 Oct 2017 20:36:50 -0600 X-Google-Sender-Auth: 84EjQalJsJV7Jv_a7adfHmku-ZQ Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: John Baldwin Cc: "freebsd-arch@freebsd.org" , Nathan Whitehorn Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 02:36:52 -0000 On Tue, Oct 10, 2017 at 5:26 PM, John Baldwin wrote: > On Tuesday, October 10, 2017 07:36:25 AM Nathan Whitehorn wrote: > > I think we can fix the problem, which is severe, in a week if we can get > > a commitment from core@ to allow at least one of the following things: > > > > 1. Package sets (potentially only very minimal ones) uploaded for tier-2 > > systems from machines not controlled and hosted by portmaster, but > > otherwise project-affiliated (like our PPC build systems). > You should take that up with core@. Individuals can provide these packages, of course, but part of the project's providing packages is ensuring that the packages have a clear provenance. That's tricky to do on machines the project provides. > > 2. The "base" ports built as part of the release/snapshot process and > > either included on the media (better) or, at the least, available on the > > official package repositories. > That's possible, but there's no release integration for external toolchains. And for tier 2 platforms, there's no requirement to do so. And nobody's stepped up to do this work. > > 3. Allow inclusion of the compiler either in src or in another > > project-hosted repository connected to src (I realize this isn't > > external toolchain, but it does still allow us to remove GCC 4.2 without > > making the system unusable) > This has its own issues. I'm not sure how this would play out. It seems like a lot of work, and nobody's name is by it. There's also: 4. Fix QEMU's issues with powerpc user mode emulation and get slotted into the same cluster we have building arm and soon mips packages. It seems to me to be less work than #3 or even #2, and doesn't have the clear provenance issues #1 has. We have good infrastructure here, though some of it depends currently on setting up native binaries that produce target output to improve the speed. That's not a requirement, though, and 100% emulation is possible, but slow. Still, it beats the alternative we have today: which is no way to produce anything the project can release. > I would prefer 2) as I think that is most consistent with what other folks > have been pushing towards. I would be fine if we just hosted them in > repositories so that 'pkg install' worked out of the box. At least if we > start building them and publishing the repositories I think it is much > easier to do more testing of them. Eventually we may also want them on > the install media along with the base system dists, but just having them > regularly built and published would be a good first step. I would propose > that we build the sysroot required using the foo-xtoolchain-gcc toolchains. > If this can be cross built, then that's a good first step. We'd need some way to produce those packages that the ports that do cross build work on. The lack of native machines under project control, or of qemu (either userland or full system) limit our options here. > We don't yet produce any install images for MIPS. If we did I would > advocate that we start providing release snapshots built using > mips-xtoolchain-gcc (make CROSS_TOOLCHAIN=blah) and use the base dist from > those releases as the sysroot to also build the base/ packages and provide > those in a repository. > > I think that same approach could be perhaps more readily adopted for > powerpc. That is, cross-building releases using powerpc-xtoolchain-gcc and > then using the resulting base dist as a sysroot to build the base/ packages > and publishing both of those as our snapshots for current. That's another path forward, but as you point out would require some more integration work. We can build the raw images today, but the snapshot integration to generate installable images aren't there. > I suspect our release generation bits don't yet understand CROSS_TOOLCHAIN > and probably will need some changes to handle that. > That would be nice, but integration into the release process never was part of the discussion on external toolchains. It was envisioned for a tier-2 or 3 architecture where release engineering or security officer integration isn't guaranteed. Both powerpc and mips are tier 2 platforms, which make it more of a challenge to use them. But I'm puzzled about something. We don't provide packages today, why should that become a new requirement to remove gcc from the tree? If we look at why, we see that we don't have PowerPC hardware in the project that can build packages. We don't have an emulation alternative like we do for arm and mips to fall back on. If the cross building works for a small number of packages, we could create a pkg release repo for that. So long as we have a complete chain of custody, there should be no barrier to doing this, even if we don't release release images. This wouldn't be hard to do, but someone needs to do the work and integrate into the tree and src/release. But all these things are stuff we could do. I'm happy to delay to give people time to do them. However, I'd like to know who is doing the stuff and on what timeframe. If someone can come up with that, then I can push back the proposed timeline. I don't oppose any of this. I think it's all great. I just oppose delaying for vague plans. Warner From owner-freebsd-arch@freebsd.org Wed Oct 11 03:02:35 2017 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 0CF0FE447FC for ; Wed, 11 Oct 2017 03:02:35 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 E9B5076EF2; Wed, 11 Oct 2017 03:02:34 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (s-169-232-86-189.resnet.ucla.edu [169.232.86.189]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9B32UVq017523 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Oct 2017 20:02:31 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: Warner Losh , John Baldwin Cc: "freebsd-arch@freebsd.org" References: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> <1966623.eKrA7uLGIR@ralph.baldwin.cx> From: Nathan Whitehorn Message-ID: <4fe9be52-fbc6-4b74-c869-7225f7e2df5f@freebsd.org> Date: Tue, 10 Oct 2017 20:02:30 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVb8daRD5fdkfLZh/cy13iaH9fALKo8VEEtXGCphpj8T/BnIx3FEXyDdcJcedYvWX/Kce6ps3TD2qFYG5NavAQq/pvYXu5CBBb0= X-Sonic-ID: C;HNP0njCu5xGrF4lQ3iMJ6w== M;pNUynzCu5xGrF4lQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 03:02:35 -0000 On 10/10/17 19:36, Warner Losh wrote: > > > On Tue, Oct 10, 2017 at 5:26 PM, John Baldwin > wrote: > > On Tuesday, October 10, 2017 07:36:25 AM Nathan Whitehorn wrote: > > I think we can fix the problem, which is severe, in a week if we > can get > > a commitment from core@ to allow at least one of the following > things: > > > > 1. Package sets (potentially only very minimal ones) uploaded > for tier-2 > > systems from machines not controlled and hosted by portmaster, but > > otherwise project-affiliated (like our PPC build systems). > > > You should take that up with core@. Individuals can provide these > packages, of course, but part of the project's providing packages is > ensuring that the packages have a clear provenance. That's tricky to > do on machines the project provides. > > > 2. The "base" ports built as part of the release/snapshot > process and > > either included on the media (better) or, at the least, > available on the > > official package repositories. > > > That's possible, but there's no release integration for external > toolchains. And for tier 2 platforms, there's no requirement to do so. > And nobody's stepped up to do this work. > > > 3. Allow inclusion of the compiler either in src or in another > > project-hosted repository connected to src (I realize this isn't > > external toolchain, but it does still allow us to remove GCC 4.2 > without > > making the system unusable) > > > This has its own issues. I'm not sure how this would play out. It > seems like a lot of work, and nobody's name is by it. > > There's also: > > 4. Fix QEMU's issues with powerpc user mode emulation and get slotted > into the same cluster we have building arm and soon mips packages. It > seems to me to be less work than #3 or even #2, and doesn't have the > clear provenance issues #1 has. We have good infrastructure here, > though some of it depends currently on setting up native binaries that > produce target output to improve the speed. That's not a requirement, > though, and 100% emulation is possible, but slow. Still, it beats the > alternative we have today: which is no way to produce anything the > project can release. This has been in progress for years and is very hard. #2 or #3 are super easy, except from an administrative standpoint, where, like #1, they have proved impossible. I am stepping up to do the work right now, and have for a long time, but the work is entirely administrative and has been blocked. > I would prefer 2) as I think that is most consistent with what > other folks > have been pushing towards. I would be fine if we just hosted them in > repositories so that 'pkg install' worked out of the box. At least > if we > start building them and publishing the repositories I think it is much > easier to do more testing of them. Eventually we may also want > them on > the install media along with the base system dists, but just > having them > regularly built and published would be a good first step. I would > propose > that we build the sysroot required using the foo-xtoolchain-gcc > toolchains. > > > If this can be cross built, then that's a good first step. We'd need > some way to produce those packages that the ports that do cross build > work on. The lack of native machines under project control, or of qemu > (either userland or full system) limit our options here. > > We don't yet produce any install images for MIPS. If we did I would > advocate that we start providing release snapshots built using > mips-xtoolchain-gcc (make CROSS_TOOLCHAIN=blah) and use the base > dist from > those releases as the sysroot to also build the base/ packages and > provide > those in a repository. > > I think that same approach could be perhaps more readily adopted for > powerpc. That is, cross-building releases using > powerpc-xtoolchain-gcc and > then using the resulting base dist as a sysroot to build the base/ > packages > and publishing both of those as our snapshots for current. > > > That's another path forward, but as you point out would require some > more integration work. We can build the raw images today, but the > snapshot integration to generate installable images aren't there. > > I suspect our release generation bits don't yet understand > CROSS_TOOLCHAIN > and probably will need some changes to handle that. > > > That would be nice, but integration into the release process never was > part of the discussion on external toolchains. It was envisioned for a > tier-2 or 3 architecture where release engineering or security officer > integration isn't guaranteed. Both powerpc and mips are tier 2 > platforms, which make it more of a challenge to use them. And yet, we *do* provide releases for them consistently. > > But I'm puzzled about something. We don't provide packages today, why > should that become a new requirement to remove gcc from the tree? Because we currently have users build from ports with the compiler included in the system. If we take that compiler away, we provide only the option to install a compiler from packages. If we also don't provide a compiler package, the system is a brick and we might as well remove the platform from the tree. > If we look at why, we see that we don't have PowerPC hardware in the > project that can build packages. We do have PowerPC hardware on which we can build packages, but we do not actually do that for a variety of largely administrative reasons that are out of scope for this thread. > We don't have an emulation alternative like we do for arm and mips to > fall back on. If the cross building works for a small number of > packages, we could create a pkg release repo for that. So long as we > have a complete chain of custody, there should be no barrier to doing > this, even if we don't release release images. This wouldn't be hard > to do, but someone needs to do the work and integrate into the tree > and src/release. If this is the plan, great. I'm happy to do whatever technical work is required for this to meet your end-of-year deadline so long as the project is actually willing to support this. > But all these things are stuff we could do. I'm happy to delay to give > people time to do them. However, I'd like to know who is doing the > stuff and on what timeframe. If someone can come up with that, then I > can push back the proposed timeline. I don't oppose any of this. I > think it's all great. I just oppose delaying for vague plans. It's not vague: If we have a commitment to cross-build the toolchain packages and upload them with releases, then we're all done here. If we don't have that, then removing GCC 4 makes all tier-2 platforms except ARM totally unusable. The two need to be coupled in the proposal. -Nathan > > Warner From owner-freebsd-arch@freebsd.org Wed Oct 11 22:32:20 2017 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 D5E14E38BDE for ; Wed, 11 Oct 2017 22:32:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE8557F332; Wed, 11 Oct 2017 22:32:19 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 2A83FC85; Wed, 11 Oct 2017 17:32:13 -0500 (CDT) Date: Wed, 11 Oct 2017 17:32:12 -0500 From: Mark Linimon To: Nathan Whitehorn Cc: freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171011223211.GA7664@lonesome.com> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 22:32:20 -0000 On Tue, Oct 10, 2017 at 07:36:25AM -0700, Nathan Whitehorn wrote: > 1. Package sets (potentially only very minimal ones) uploaded for tier-2 > systems from machines not controlled and hosted by portmaster nit: s/portmaster/portmgr/ Kind of a sore point with me, sorry. mcl From owner-freebsd-arch@freebsd.org Wed Oct 11 22:44:51 2017 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 09EEFE391F5 for ; Wed, 11 Oct 2017 22:44:51 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF628803BC; Wed, 11 Oct 2017 22:44:50 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 29E69C85; Wed, 11 Oct 2017 17:44:49 -0500 (CDT) Date: Wed, 11 Oct 2017 17:44:48 -0500 From: Mark Linimon To: Warner Losh Cc: Nathan Whitehorn , "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171011224447.GB7664@lonesome.com> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 22:44:51 -0000 On Mon, Oct 09, 2017 at 11:56:07PM -0600, Warner Losh wrote: > However, absent a clear plan, as well as resourced dedicated to realize it, > I'm not sure that we should block things further based strictly on a list > of things that are broken. If there's a plan to fix, I'm willing to defer > to give that plan a chance to happen. In the absence of a specific plan > with timelines, I'm reluctant to indefinitely delay the negotiated plan > for 12 which has taken years to pull together. Otherwise, is 3 more months > enough? Is 6? are 12? Do we wait for FreeBSD 13? Even though I work on both affected archs, I think gcc4.2.1 in base has to be _gone_ for 12. It's time. Here's my compromise suggestion. We give nathan (and myself and whoever else wants to help) until the BSDCan Devsummit to fix this. But at that point it's the Danish Axe(*) no matter what state it's in. Period. That gives us an absolute deadline. For reference, gjb has guesstimated that the 12.0 release cycle will begin around February 2019. (good grief I nearly typed 2109. stahp.) In any case, axing things during the Devsummit is a Grand Tradition at this point. Why not continue it? :-) mcl * or Wemm axe, or Losh axe, or whatever From owner-freebsd-arch@freebsd.org Thu Oct 12 16:57:02 2017 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 69853E2EE0E for ; Thu, 12 Oct 2017 16:57:02 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5499D83F72 for ; Thu, 12 Oct 2017 16:57:02 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by mailman.ysv.freebsd.org (Postfix) id 51217E2EE0D; Thu, 12 Oct 2017 16:57:02 +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 50CF5E2EE0C for ; Thu, 12 Oct 2017 16:57:02 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 2CF8E83F71 for ; Thu, 12 Oct 2017 16:57:02 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 851585A9F12; Thu, 12 Oct 2017 16:56:55 +0000 (UTC) Date: Thu, 12 Oct 2017 16:56:55 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Message-ID: <20171012165655.GH68389@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 16:57:02 -0000 --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Oct 08, 2017 at 11:45:37PM -0600, Warner Losh wrote: > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are > really parts of the boot loader with an unstable API and shouldn't be > installed into the system. It's really a private library to the boot loader. Kicking it out of src/lib will be a good thing. It doesn't make sense to build and install as part of the world and, for good reason, doesn't follow normal rules. It was a pain to deal with for CHERI and I think we've disabled it entierly. -- Brooks --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZ357WAAoJEKzQXbSebgfAJHoH/AvthD4oM8Zz4OwOBZACd4pp bJG/xAABZaB84gW8brZ+fARgqGry6JsREy9Tf629Rd+WvKE6uy4I25bcjCTZkVC9 V31sLriYWFmrzV+jsmv8siOSCcplYHLgfur6NkSrWw5aCoM+7qAXRxzkVzcwNcyS nPnyE4TSsHdglam0YtnQmxACSE/Mg+rHGgK9OR6Sq44ClJkvIHmPENFPGnBoEpgy zcPSgfYHWicjQfFEnXMOcsqeABgTGv1pQ79hju8Zkp68cRcdsrCnSmmNsq86/PLV zfK2R61ZO+RIUPVQHt2hpcCPbGlg5LiPPndl8emuIscbMCHSIoY7CDg1SoeyPzg= =/JXZ -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi-- From owner-freebsd-arch@freebsd.org Thu Oct 12 17:37:43 2017 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 A5299E2FC90 for ; Thu, 12 Oct 2017 17:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.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 7E750AC8 for ; Thu, 12 Oct 2017 17:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7AB44E2FC8F; Thu, 12 Oct 2017 17:37:43 +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 7870EE2FC8E for ; Thu, 12 Oct 2017 17:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 33BBFABD for ; Thu, 12 Oct 2017 17:37:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id 101so6297902ioj.3 for ; Thu, 12 Oct 2017 10:37:43 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=vxVKQ/pwf2RbjnuLw/5hgRMzNsjp2THKYUDqJonQe5c=; b=podVVI8dhf9EKgL+VUDh/qUmeqsBuwHrn8iT3q/O7Ddd1FbzbPSwNw0m/pWDjt5GwG tS/3QY1kJ/0Hq/+zEaKAbQ1BJkymoFp39OSPnbPsWfUz6MYVZE6YwlyD133thKKqbeOU LoIVc1b4qZVMjRGPPx7gJbYOhQifFbxNTFxMRrpQmmy5t54b/PxmSWUwpDN1gTH0hK1X zHOgO5awUZkMlm50YZvFkU+INzIg0udA2zGloLVFUIMWoAHlKqxywHBUglSMzSgKQldM jNQpL6nAcgghyfOGcff4e1uoSA2ZGk8Z/xXsVpLVmE6kDBx+RyFNJ5klcoP/PV3O0k7L xtsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vxVKQ/pwf2RbjnuLw/5hgRMzNsjp2THKYUDqJonQe5c=; b=XDGBJ52fgIMhaMLDKYhC+rQH7jOsJWhGrXwhTqbMQqv4BrtvhzMWXyiAq0SV1mIB2z GaDFGsho86TgRiVUbp6DdbRGope/OO0JhipbnH1mYl7fVhzCvNsymKbPtL3hwMGV45aD npSmGszTIfxF9CCHfbXsi45LkBQ5mVO+pVxBHCqVVHrEaLf4mGDQ/o7KkTemf1bSbXv5 qrgfMJHD7cQ3o0M4HsK8WhNCUPATTiQcPycxXl83LRbajI82rpxY6AGTj7iY/SxpWOf3 GN5TwaooIhfyi5C0HYl4c8hIIQ43ZPWRxrS04e+F/g5nO+jN5hART6vcOhArTG+qBAlf 3Ghg== X-Gm-Message-State: AMCzsaW/9vuxP6U0rlAqVwRd3VxsH662+12DNzHN/+KGlxjN+tJf6BKd FYl6GKBJucp7j0Sa4rvC+h/R0vUfoKGizVdAfyjISw== X-Google-Smtp-Source: AOwi7QAeE1MFS60VpzZl0pXpvTR6gGy9dyagq9MItTaLrDx5/giM9jhByQ0g4cuRFflpjJezQN3bR9Rghf0cBe/sUlQ= X-Received: by 10.107.135.202 with SMTP id r71mr4307103ioi.26.1507829862285; Thu, 12 Oct 2017 10:37:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 12 Oct 2017 10:37:41 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::9312] In-Reply-To: <20171012165655.GH68389@spindle.one-eyed-alien.net> References: <20171012165655.GH68389@spindle.one-eyed-alien.net> From: Warner Losh Date: Thu, 12 Oct 2017 11:37:41 -0600 X-Google-Sender-Auth: tfXLf4CMznXdyx1R4J3Yw3DL4XQ Message-ID: Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 17:37:43 -0000 On Thu, Oct 12, 2017 at 10:56 AM, Brooks Davis wrote: > On Sun, Oct 08, 2017 at 11:45:37PM -0600, Warner Losh wrote: > > I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. These are > > really parts of the boot loader with an unstable API and shouldn't be > > installed into the system. It's really a private library to the boot > loader. > > Kicking it out of src/lib will be a good thing. It doesn't make sense > to build and install as part of the world and, for good reason, doesn't > follow normal rules. It was a pain to deal with for CHERI and I think > we've disabled it entierly. Yes. I've moved it into sys/boot. So now it's possible to hack on it w/o crazy gymnastics. The BERI boot loaders do interesting things in the tree, so I'm not surprised. I'm contemplating moving src/sys/boot up to just src/boot (this mirrors in some ways what old-school Unix did with src/cmd/standalone and src/mdec). It would build, but not install, as part of buildworld. All libraries would be internal / private to the build. Warner From owner-freebsd-arch@freebsd.org Sat Oct 14 01:50:55 2017 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 874F0E34827; Sat, 14 Oct 2017 01:50:55 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 477F781B71; Sat, 14 Oct 2017 01:50:55 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua0-x242.google.com with SMTP id s41so6448755uab.10; Fri, 13 Oct 2017 18:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3rlXma3ZwBMFSoOR5TTiOnZPidAOhB9tJ+FPyeAyXFQ=; b=fr0C/hNRNWEQW1RU6h7LD0R6uT3llP8Wy9Tpu0Oh9PdursOxT4uo1xeKtXNm/co1xx 7A0Mvu0NQBAFTNqIOW35nQNVsVj9G88fPddlT/gnXIECvBsjo2adKDGuR3oXaYVkHbjz 6sSAOLY/mCTcso8iM+4ONWgqtmUxWJSxy1HzKZjDC/DD6d7ergEYWtSfldPx8hrdULR+ DP0C4AyaXKl4KnBwMV9/wHijsg0U1vz9iluEi67kT2Pu64EJTonIp9lC06eAeARJ2ld1 H/eOdUA6syNdV0p7Y/J/l1xxXL4OO3JlxKfJBlZMtsGkBo73oSRB5PmD+x6sgt/D5wsx 7eZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3rlXma3ZwBMFSoOR5TTiOnZPidAOhB9tJ+FPyeAyXFQ=; b=edGtfLpK4991C2KLABOe+WwwUBAFaY+B2ZXtfuFlE0ubD9hF8h5K6Jy6t/sfEX2fph AJL4+uKnZOLeqpI6fNwweBgOKwfJCJma99EMPpvzqilXs1pSexysqU19qSSqU5KxD786 XIYhNZZjhSL/T/Hfmbt0wHqZ4hJYsz1Fa/TpoeDWGoi15JQwkgRZiNfSaXjwRcmJ2wK/ pZpYelVDrhqkrC7PGWfs4CVUDTGtx829DBQA62cmvdWK0nXCm5C2ao+Mw3bRtsvXHayR rVBbfYDshgYOF6T6yHRfw/F8x2Mry2fs/H1CwYuRd2OE2gb0jtkOM00Cl3aGP1YvmnkF k0Ag== X-Gm-Message-State: AMCzsaXUoc1D8YNL2my5Vv3h98e9jdLTNCFUW+VxxmNdWGE1d4nXI9Ox LJk0x4xuHk26VLe3OtsrcVGCYW6Lotnh7Wm+LEZgQA== X-Google-Smtp-Source: AOwi7QBi2etPYGXUWLktm2EaxQ5mJD4Hkqcg24ZeeF0xdLJtWzL3Jf2RgbW+lNRSOLYU9J3DGTJe4S6Vzf4SC4oxN4E= X-Received: by 10.176.75.195 with SMTP id b3mr2628042uag.51.1507945853438; Fri, 13 Oct 2017 18:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.50.129 with HTTP; Fri, 13 Oct 2017 18:50:13 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Fri, 13 Oct 2017 21:50:13 -0400 Message-ID: Subject: Re: Power9 Inexpensive Development Testbed To: freebsd-hardware@freebsd.org Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, freebsd-performance@freebsd.org, info@freebsdfoundation.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 01:50:55 -0000 On Mon, Oct 9, 2017 at 5:59 PM, grarpamp wrote: > With Power8 aging and Power9 shipping... Consider picking up a > couple of these to support the development of getting FreeBSD going > on the bare iron without hypervisor. FreeBSD being a member already, > good support for this effort should be available from the OpenPOWER > Foundation / IBM. They seem to want to make Power9 and beyond happen > in a big way. Linux also has support for Power9. > > A barebones selfbuilt machine for the dev cluster would cost about > $3200-$3500, and/or donation could be solicited from OpenPOWER > Foundation. > > https://raptorcs.com/TALOSII/ > https://raptorcs.com/content/base/faq.html > https://github.com/open-power > https://github.com/openbmc > https://wikipedia.org/wiki/POWER9 > https://openpowerfoundation.org/ > > Just an FYI for those unfamiliar, including potential users. > > This thread could be updated to list other Power9 > hardware sources as they become known by > the FreeBSD community. Adding some more "official" links about this CPU and platform for anyone interested. Some of them may refer to Power8, which can be viewed as carrying over plus better to Power9. The Open Power Foundation / IBM full release, marketing, and public availability of Power9 seems to be set for 2018q1. So expect more vendors and so forth at that time. *** Note that this platform apparently does not have any closed source firmware / microcode or BIOS blobs. That means no Intel AMT / ME, no AMD PSP, etc. Programming documentation should be available. And seems to perform competetively on a number of fronts / tasking. *** https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.raptorengineering.com/TALOS/op_qemu_gl.php https://www.raptorengineering.com/content/base/canary.htm https://secure.raptorcs.com/blog/08212017001.php https://social.raptorengineering.io/main/public https://www.reddit.com/user/madscientist159 https://twitter.com/RaptorEng https://twitter.com/RaptorCompSys https://www.reddit.com/user/stwcx https://wikipedia.org/wiki/OpenPOWER_Foundation https://www.ibm.com/power/operating-systems/linux https://www.ibm.com/Search/?q=power9 https://twitter.com/ibmpowerlinux http://tyan.com/campaign/OpenPOWER/ http://www.fsf.org/resources/hw/endorsement/respects-your-freedom https://www.fsf.org/blogs/licensing/only-a-short-time-left-to-pre-order-the-talos-ii-pre-orders-end-september-15th You can search some third party sites for performance, news, and reviews. Search on "openpower" or "power9". https://twitter.com/search?q=power9 https://www.nextplatform.com/?s=power9 https://www.servethehome.com/?s=openpower https://www.anandtech.com/SearchResults?q=openpower http://www.storagereview.com/search/node/openpower https://hn.algolia.com/?query=power9&sort=byDate&prefix&page=0&dateRange=all&type=story Some articles that have appeared... https://www.nextplatform.com/2016/04/06/inside-future-google-rackspace-power9-system/ https://www.nextplatform.com/2017/09/19/power9-rollout-begins-summit-sierra/ https://blog.rackspace.com/the-latest-zaius-barreleye-g2-open-compute-openpower-server https://www.enterprisetech.com/2014/07/15/open-sourced-bios-helps-power8-compete-x86/ http://www.theplatform.net/2015/03/23/inside-the-rackspace-openpower-megaserver/ https://news.ycombinator.com/item?id=12351319 https://news.ycombinator.com/item?id=14956257 https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.8-More-POWER9 https://www.phoronix.com/scan.php?page=news_item&px=Power-Changes-Linux-4.12 https://www.phoronix.com/scan.php?page=news_item&px=Raptor-Talos-2-Teaser https://www.phoronix.com/scan.php?page=news_item&px=Talos-2-POWER9-Pre-Order https://www.phoronix.com/scan.php?page=news_item&px=Talos-2-FSF-RYF-Possible FreeBSD status... https://wiki.freebsd.org/POWER8 https://www.freebsdnews.com/2015/03/04/freebsd-power8-its-alive-2/ https://svnweb.freebsd.org/base?view=revision&revision=279189 https://www.freebsd.org/news/status/report-2015-01-2015-03.html#FreeBSD-on-POWER8 https://reviews.freebsd.org/search/query/oIdoWWKTe71p/ Sorry don't know which list is best, perhaps hardware@? Anyway, happy hacking :) From owner-freebsd-arch@freebsd.org Sat Oct 14 03:49:45 2017 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 6679AE3A35C; Sat, 14 Oct 2017 03:49:45 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 448E616B6; Sat, 14 Oct 2017 03:49:44 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 4791ABFC; Fri, 13 Oct 2017 22:49:38 -0500 (CDT) Date: Fri, 13 Oct 2017 22:49:37 -0500 From: Mark Linimon To: grarpamp Cc: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, info@freebsdfoundation.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Power9 Inexpensive Development Testbed Message-ID: <20171014034936.GA18066@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 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 Oct 2017 03:49:45 -0000 A few of us FreeBSD/powerpc64 fans are watching the developments closely. mcl