From owner-freebsd-arch@freebsd.org Mon Oct 2 13:38: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 8119BE3FC93 for ; Mon, 2 Oct 2017 13:38:19 +0000 (UTC) (envelope-from katelyn.smith@microiworld.com) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0130.outbound.protection.outlook.com [104.47.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE944689AB for ; Mon, 2 Oct 2017 13:38:17 +0000 (UTC) (envelope-from katelyn.smith@microiworld.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2803219.onmicrosoft.com; s=selector1-microiworld-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZW/9i5XalYa4lolizwfL+h+0mwjcsHB6rwn+/nN85eU=; b=zs0gqdQcDsm/lbLerz5pu8taWq6QC43/evKL3nV+xc6yHAZl0kubeVTLJ4ihP30v5egDwHiYLjVmSlITIFobJdoCw1Xyydmup2tLq2c60SHqYYzb/d80X3GIyeMp4rZhBmW4haJBoNhg42la/aM7xNSHqby0N/+8ByPi4526abM= Received: from BM1PR01MB0881.INDPRD01.PROD.OUTLOOK.COM (10.174.211.9) by BM1PR01MB0881.INDPRD01.PROD.OUTLOOK.COM (10.174.211.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 13:38:14 +0000 Received: from BM1PR01MB0881.INDPRD01.PROD.OUTLOOK.COM ([10.174.211.9]) by BM1PR01MB0881.INDPRD01.PROD.OUTLOOK.COM ([10.174.211.9]) with mapi id 15.20.0077.018; Mon, 2 Oct 2017 13:38:14 +0000 From: Katelyn Smith To: "freebsd-arch@freebsd.org" Subject: Cisco MPLS Thread-Topic: Cisco MPLS Thread-Index: AdM7g4uZRk6zK9T3QDWoBJofUKlBNA== Date: Mon, 2 Oct 2017 13:37:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=katelyn.smith@microiworld.com; x-originating-ip: [49.207.51.177] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BM1PR01MB0881; 6:M3NVJTm4mHt9jnIFLwHYjsHOqeaymBhvDT+Qo1UC9n9wg11f8D9Quznf3fSdtup/sj576S6VPs54jIQyrtAGDj9ZOsALxaLPpIXqak5kg8mKLjyGk2hUG5TekXyOXsr+J1vnCssbvJ/126eu9ARtEzVzYPEjRk6Ak80WiNQeWxfzcZGr1ysRdnc+nvqr0RMLyoDaOpAhdSgtnVWsQqE/Pz31Qv3aKIecgZnkD84Kbbo/I4EojhlxS8AQ37H71VLh6xiyXW+zOY/pKb/i69ikDjaIVqFyWY+5oMN2gdCMMK0JfxilSJWJmlLRtYhOwgzraTvnPPg8iLoQ7pEvkaWUyg==; 5:ZyLxzOeh/ZAkiYrB7bKqknmwjJyZ956NtnYISnxGLdzws1/D8VjHvo06UuJMmiB6IyA6xWobG42nhKygQ6Q5ZsYNFOh/gRex8FPSG1daNdk5p+/C6FCZFEqTAeDmqEnRPgWAIYYD9AW/t76M8ifqTA==; 24:wKQLyy3R/QoWjZYe/ukz9WFk1Z+W4SCkyxFWKM/pJObl3QB+3u4p6HKgNmsOflbX2yUxwGAGGSrCaxi1hugDaoxLN/ee2S37GpryHsdA9UA=; 7:tFegCNn3SSAkngNQSAcQg+pK8zOXfa0QQ0R98xAHr914CNqcyQNyC97414+/BxQQ/PLyIDoTE2tlLyKahB6loPrI9818qD0CLAL1b0aTWRDpVscpg4+Y19lOawkLt63mUuTjHyZIXh+i7YoybuCH2WesqJd2McDy9DhDVn/bahwVIU3knKtPJr/GYlYxzOEjMPtpfVM4o3UF9SnU95ECyI7sdqEi+UDwmwnA55SGL5Q= x-ms-office365-filtering-correlation-id: 7d212123-f132-4eb4-69be-08d5099ad518 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017082002075)(2017052603199)(201703131423075)(201702281549075)(201702085551020); SRVR:BM1PR01MB0881; x-ms-traffictypediagnostic: BM1PR01MB0881: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(2016111802025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BM1PR01MB0881; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BM1PR01MB0881; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(199003)(221733001)(316002)(189998001)(33656002)(66066001)(102836003)(3846002)(6116002)(790700001)(97736004)(105586002)(53936002)(106356001)(2501003)(3280700002)(2906002)(2900100001)(7520500002)(626008)(9686003)(2351001)(54896002)(101416001)(6306002)(55016002)(68736007)(3660700001)(86362001)(25786009)(8936002)(14454004)(6916009)(5640700003)(6436002)(6666003)(6506006)(77096006)(5630700001)(5660300001)(7116003)(50986999)(8676002)(54356999)(7736002)(81166006)(81156014)(74316002)(478600001)(7696004)(3480700004); DIR:OUT; SFP:1102; SCL:1; SRVR:BM1PR01MB0881; H:BM1PR01MB0881.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microiworld.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microiworld.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 13:37:23.4119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f482093-8fab-46ad-b760-39c5294d3054 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BM1PR01MB0881 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 02 Oct 2017 13:38:19 -0000 Hello there, I would like to know if you are interested in acquiring a list of companies= using Cisco MPLS. Information fields: Names, Title, Email, Phone, Company Name, Company URL, = Company physical address, SIC Code, Industry and Company Size (Revenue and = Employee). Let me know if you are interested and I will get back to you with the count= s, sample and pricing. Regards, Katelyn Smith Marketing Executive To opt out, please reply with Leave Out in the Subject Line. From owner-freebsd-arch@freebsd.org Tue Oct 3 20:06: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 DE563E231E5 for ; Tue, 3 Oct 2017 20:06:41 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 988D62764 for ; Tue, 3 Oct 2017 20:06:41 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id f15so15277726qtf.7 for ; Tue, 03 Oct 2017 13:06:41 -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; bh=fru17YEZoiwXb9qBa5zLDJUZ8yPPwJzXalyM6KJ0U0M=; b=aRxZt/ylMy3IDq1DYe7CWxTiYn2B0qyuuzHor4nyflANhAK+QG+aygkXABEVFDT10X uVss7NxW3BT08H+NrvNG2o+D8k2Ilhvs71oagxyZ/6viBZ40b6IDF5O2HULaYIHJCHYv 7TF3f6KZFiTRDJaK2Hi4hWzVKbuCLRBVSCWPnW+wz5Di+vt8DvH56hgUHM6LH+oRv0Ir bc6Bvwh1Xs3iKaMk8z+HM/r8HubIU5xtLjcncFxbsIOWQ73/pfKQ/riYF2vmEnalJ53L vS4v1Ua+P7rOGWHT5hxUQr8tDR/S87QWLkmoKpAevycVr4/UKqjaFmLSnsuwgV/5JqpA Fv0A== 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; bh=fru17YEZoiwXb9qBa5zLDJUZ8yPPwJzXalyM6KJ0U0M=; b=negosr5AaPwRA24+ipVpSNECiVtw1INO4qM3NOWzeawrfkm3+VM73A+87U6Pbmbyz1 LEgascqI+rN4a5p6MU7cYWpJYDwQHP7/kMxuD9Mo7i8BYJ9zKF8fyzJLKubg7ONMu9dA ggD8pxMN680DvzOYb31c8G2cJySeZJsrpYeNBRwAieIuOPOpk9QUM8UBAkjRN93WqOtS rYD706U/uHgiT5v4gfTS3kT3Kk5CKK8GD7SoU02QP0Y617sd1SmHTyRuc0+dC/a/vjl3 D5qzLdeiJ1QUXIdcRwP1mOpB4498wrtEGDGNEbLhtVtQa/rppTMpP5X+YBb1DrxrjaC2 ltFw== X-Gm-Message-State: AMCzsaUlSUADzoClEMJmqs4xrJdo7bYg+cL3Jgd+z0cJQNEG7kZbeqH7 il2kB+ePV/Oak8ZVTPYzWndCKeSuBy6CMBIp8edbbi6A X-Google-Smtp-Source: AOwi7QDZted1fCVHw3j3XfPxl+jjaft4jexYFobnKg2FOdsjqRiM4YoB1QXu4E1i0wIvvFSrSG2ngEBqwRTYve1gjIs= X-Received: by 10.237.41.70 with SMTP id s64mr2340604qtd.71.1507061200288; Tue, 03 Oct 2017 13:06:40 -0700 (PDT) MIME-Version: 1.0 Sender: jlehen@gmail.com Received: by 10.12.163.36 with HTTP; Tue, 3 Oct 2017 13:06:39 -0700 (PDT) In-Reply-To: References: From: Jeremie Le Hen Date: Tue, 3 Oct 2017 22:06:39 +0200 X-Google-Sender-Auth: Ac5aB9U980fPjVXa8722Pn-SBM4 Message-ID: Subject: Re: rtools were deemed almost unused 15 years ago... To: 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: Tue, 03 Oct 2017 20:06:42 -0000 I've slacked a bit but here we are: https://reviews.freebsd.org/D12573 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 wrote: >> 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! > > -- Jeremie > >> >> Thanks. >> -- Jeremie >> >> On Tue, Jun 20, 2017 at 12:25 PM, Jeremie Le Hen wrote: >>> Hey folks, >>> >>> I remember when I was still barely out of my teenagehood, people were >>> mostly using ssh/scp while rtools (rsh, rlogin, ... for the >>> youngsters) were left in place as a courtesy for legacy production >>> systems still relying it on them. >>> >>> Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely >>> reminds us that suid binaries are an attack surface. I don't even need >>> to mention that it's a healthy engineering practice to remove unused >>> code, both from a maintenance and security perspective. >>> >>> Therefore, I hereby propose to remove rtools from the base system. I >>> acknowledge this will likely cause troubles for a handful of people >>> who are still relying on it for good or bad reasons. But the flipside >>> is that the attack surface of millions of FreeBSD installed out there >>> will be reduced. >>> >>> The proposed roadmap is: >>> - disable from the build on head and let it soak for one month >>> - remove rtools from the base. >>> >>> What do you guys think? Any preferred color for the bikeshed? :) >>> >>> >>> >>> [1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt >>> -- >>> Jeremie Le Hen >>> jlh@FreeBSD.org >> >> >> >> -- >> Jeremie Le Hen >> jlh@FreeBSD.org > > > > -- > Jeremie Le Hen > jlh@FreeBSD.org -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-arch@freebsd.org Tue Oct 3 23:04:39 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 88962E27C77 for ; Tue, 3 Oct 2017 23:04:39 +0000 (UTC) (envelope-from jwd@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B91687A8; Tue, 3 Oct 2017 23:04:39 +0000 (UTC) (envelope-from jwd@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 821) id 904B2FEC5; Tue, 3 Oct 2017 23:04:38 +0000 (UTC) Date: Tue, 3 Oct 2017 23:04:38 +0000 From: John To: Jeremie Le Hen Cc: freebsd-arch@freebsd.org Subject: Re: rtools were deemed almost unused 15 years ago... Message-ID: <20171003230438.GA53445@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" 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: Tue, 03 Oct 2017 23:04:39 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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! > > > > -- Jeremie > > > >> > >> Thanks. > >> -- Jeremie > >> > >> On Tue, Jun 20, 2017 at 12:25 PM, Jeremie Le Hen wro= te: > >>> Hey folks, > >>> > >>> I remember when I was still barely out of my teenagehood, people were > >>> mostly using ssh/scp while rtools (rsh, rlogin, ... for the > >>> youngsters) were left in place as a courtesy for legacy production > >>> systems still relying it on them. > >>> > >>> Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely > >>> reminds us that suid binaries are an attack surface. I don't even need > >>> to mention that it's a healthy engineering practice to remove unused > >>> code, both from a maintenance and security perspective. > >>> > >>> Therefore, I hereby propose to remove rtools from the base system. I > >>> acknowledge this will likely cause troubles for a handful of people > >>> who are still relying on it for good or bad reasons. But the flipside > >>> is that the attack surface of millions of FreeBSD installed out there > >>> will be reduced. > >>> > >>> The proposed roadmap is: > >>> - disable from the build on head and let it soak for one month > >>> - remove rtools from the base. > >>> > >>> What do you guys think? Any preferred color for the bikeshed? :) > >>> > >>> > >>> > >>> [1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt > >>> -- > >>> Jeremie Le Hen > >>> jlh@FreeBSD.org > >> > >> > >> > >> -- > >> Jeremie Le Hen > >> jlh@FreeBSD.org > > > > > > > > -- > > Jeremie Le Hen > > jlh@FreeBSD.org >=20 >=20 >=20 > --=20 > 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" --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJZ1BeFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNDBGOTgxNzM0NzQ3OEFBNDYyODNGQzVC NjI0OTlBMTQyNEY3RjgxAAoJELYkmaFCT3+BFXoH/0mQ4gFxxpDyzCDogQtbdlLm XehjQ8YtXHYbmSCx00pRJBonC5gkNJUkbN8b4sm8e5tcDg6BrCEMaBthOzCjxdVG NTF1GZRvP/6nhFysf472rGrtaAVTeh7yxVcxjriAt/E3mBt/wOLPI7j1T6+yiKhN FudIpVUVgwlpSL2GIgYZmIZTMm8Xxf7dbq2IqdYW8v8IQFRAuFAuNpGxGCvhUlZQ RMpGxgpJ9AbTjmMr/SAZSQwVaxuYPbcjRnXepU1oFfRSQ/4W2SABDN/RQdGCC+Od IyzysJoxeYxdYVppV2/8IVJxBY3aWo4BK9APvPqMb7fnzQIR3jKo1R1lsXOm15Q= =yCZH -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-arch@freebsd.org Wed Oct 4 10:35: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 C68BBE35580 for ; Wed, 4 Oct 2017 10:35:25 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5502C7FAE0 for ; Wed, 4 Oct 2017 10:35:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (pD9FA3C56.dip0.t-ipconnect.de [217.250.60.86]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id v94AYTKt055444 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Oct 2017 10:34:34 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id v94AZGbQ078960 for ; Wed, 4 Oct 2017 12:35:17 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id v94AZ4JM095529 for ; Wed, 4 Oct 2017 12:35:16 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201710041035.v94AZ4JM095529@fire.js.berklix.net> To: freebsd-arch@freebsd.org Subject: Re: rtools were deemed almost unused 15 years ago... From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Tue, 03 Oct 2017 23:04:38 -0000." <20171003230438.GA53445@FreeBSD.org> Date: Wed, 04 Oct 2017 12:35:03 +0200 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, 04 Oct 2017 10:35:25 -0000 > 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. 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. From owner-freebsd-arch@freebsd.org Thu Oct 5 08:49: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 998F2E3120C for ; Thu, 5 Oct 2017 08:49:38 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5255C66149; Thu, 5 Oct 2017 08:49:38 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id o52so23998826qtc.9; Thu, 05 Oct 2017 01:49:38 -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=o12rttTsfU2HSEGuRp2JXazL8tRzVgnmTL2K0hleoJ8=; b=V36dHZozcrkNn6CsqGzlQ2ja/dZXuH/KFQzcON+m6/TF9DGwKhFTDpGlofZPKNzzMc KQxl/nE3TnWSMonNhnSOMUN2vgwWwpMr3jO9ITZC1HSsD8t62ugi2u487Y+TwQoUJMlB PiwLihbdKxK9slDOsf3h1JWTcqj9ogJYchXeDQBnVoLMTX8d4b4WxB1+SBAQfk6otEvd TPHUIfcGrCAfac45P0EZmPURZsyiy0EewuaqjhGD69USUBU+wgO8VFUigyz7HETH3ka0 7l5jUCx/UXYhgCsPrQ+9IEwe3RC+/HBcNY6icExlAUSOtDzz9Sh6u8UsS1A1a+eUfDbB nGhQ== 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=o12rttTsfU2HSEGuRp2JXazL8tRzVgnmTL2K0hleoJ8=; b=BOBqgnyAKtqbArrxO9HniFcVR+seObgtqyH7p77lqLCD/vbsBV16JhEHj8aYJuyXlJ um4Jcbp2huENDvSQAmeF0V+5nD+Vhi8D+kRBmjqonjf9yLzeWPEZAMjN8vRADFSzjyCk JXV52yWzaX5yLsnF+iep02vDShqSZHsH2vhFuJ+Q8F+mhiITJfLh6IXk8gwvpl2RnWjG IcL7DxBLQCQXVcUhRZFv2PRHP5dytti8a0N55hfT5NXCSTqhYJWbg6WfUb3Ps1FV01Q2 4MLQiJt/SrKDqvys9TUw3vomOAzWP/9EfE5bTnr2GEBIP+nxdZ2dsFelTzKdnxXYchpX Hhow== X-Gm-Message-State: AMCzsaVTDFp/MzTWtzLMEy1Gmi2HQZteY6aLG+IAfF6BUmFqcYM9Xw77 MD35r3XOw9iV7mHAGiDZuAx+OKju1xj6C6x5tX3FFNIl X-Google-Smtp-Source: AOwi7QB4i3zn2Dh4WQ0p8OQizb5ljiBEPz1/hrlHgFiH1YyGvJPMDZogK6ZSyWl+Zi3VaSZNwf9FGawPMlx/QBkLO0k= X-Received: by 10.200.38.225 with SMTP id 30mr32808707qtp.8.1507193377081; Thu, 05 Oct 2017 01:49:37 -0700 (PDT) MIME-Version: 1.0 Sender: jlehen@gmail.com Received: by 10.12.163.100 with HTTP; Thu, 5 Oct 2017 01:49:36 -0700 (PDT) In-Reply-To: <20171003230438.GA53445@FreeBSD.org> References: <20171003230438.GA53445@FreeBSD.org> From: Jeremie Le Hen Date: Thu, 5 Oct 2017 10:49:36 +0200 X-Google-Sender-Auth: J_eO3Mcx_pHknrIQWbDTZKOUW3o Message-ID: Subject: Re: rtools were deemed almost unused 15 years ago... To: John 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: Thu, 05 Oct 2017 08:49:38 -0000 On Wed, Oct 4, 2017 at 1:04 AM, John wrote: > Have you picked up the recent changes to the code in your port? Yes I did: https://github.com/jlehen/bsdrcmds/commit/3bc90c337176af0953b4194c14825ea14300de90 -- Jeremie > > ----- Jeremie Le Hen's Original Message ----- >> I've slacked a bit but here we are: >> https://reviews.freebsd.org/D12573 >> >> 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 wrote: >> >> 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! >> > >> > -- Jeremie >> > >> >> >> >> Thanks. >> >> -- Jeremie >> >> >> >> On Tue, Jun 20, 2017 at 12:25 PM, Jeremie Le Hen wrote: >> >>> Hey folks, >> >>> >> >>> I remember when I was still barely out of my teenagehood, people were >> >>> mostly using ssh/scp while rtools (rsh, rlogin, ... for the >> >>> youngsters) were left in place as a courtesy for legacy production >> >>> systems still relying it on them. >> >>> >> >>> Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely >> >>> reminds us that suid binaries are an attack surface. I don't even need >> >>> to mention that it's a healthy engineering practice to remove unused >> >>> code, both from a maintenance and security perspective. >> >>> >> >>> Therefore, I hereby propose to remove rtools from the base system. I >> >>> acknowledge this will likely cause troubles for a handful of people >> >>> who are still relying on it for good or bad reasons. But the flipside >> >>> is that the attack surface of millions of FreeBSD installed out there >> >>> will be reduced. >> >>> >> >>> The proposed roadmap is: >> >>> - disable from the build on head and let it soak for one month >> >>> - remove rtools from the base. >> >>> >> >>> What do you guys think? Any preferred color for the bikeshed? :) >> >>> >> >>> >> >>> >> >>> [1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt >> >>> -- >> >>> Jeremie Le Hen >> >>> jlh@FreeBSD.org >> >> >> >> >> >> >> >> -- >> >> Jeremie Le Hen >> >> jlh@FreeBSD.org >> > >> > >> > >> > -- >> > Jeremie Le Hen >> > jlh@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" -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-arch@freebsd.org Thu Oct 5 08:57:59 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 B87A6E3166C for ; Thu, 5 Oct 2017 08:57:59 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 725CD666DE for ; Thu, 5 Oct 2017 08:57:59 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id i13so24023023qtc.11 for ; Thu, 05 Oct 2017 01:57:59 -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=RyMMBP8EELxAVTXWFLyZ0xNPGbaP9mSiIrGRC8yE248=; b=jZcBI40nU0sekiBQ54sWm3FIwx0AV6kqJS/ZYK5NFyHL9l7TeZHpmzwNF5BuYJPUTS FROIKQNbirJowEu3lZLZyMKYzcbARDdE8bkLapCALu53wZ/HDpi0LyrhviRICtNVLF6j 1SvzTd4EoUQEfZ0VLIi6TPE+HXLeUoECwOdCLqG1aT3Uh8gRDgaQJwdm3+T3d103sqqq SwCdWDFbgvhq+KccMlSM9hdkUdOkK8OmhfE5H7Ub5YXj/L7Kig6PF5fFW0/veHBsnvjP CmXV165o6H2KY2KhPQH1GOzliFSE1i/TwTUcWOtAQY43W1KMxTwRQSedbjNspnWwNbSI Ryng== 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=RyMMBP8EELxAVTXWFLyZ0xNPGbaP9mSiIrGRC8yE248=; b=g3oPQFAp5X4ebAhHi8xQGScrRW5/mJ3H50qOPAahr9VgZR2RAug11DCa/HbXxNpVat NFsL6BXfMcM9owBQC6NIFwA063La+H0HlcN0GP1InJAOrM+m9/4EWLUTgeQI0ebo0Olj R1JAISyObQA/4wVoQJr7Xxv+XBu46O+ohWwTRnAu/O9iK+Tsrpg8NA6qTLTxCbunOyUx Hm9asWtt0FfIp8K+qdYGCLTc7siQVeftVIlyjAsUcEFVFlT3F4lIQ0a0hW/n+QkimHcw CqvenmCh7Zu63FLZR3f13zmc0mBfYw5KWC1BTp7dAp945BSODFX6kr2fG2j1SUMGKopd psCA== X-Gm-Message-State: AMCzsaVagRqkR+6vX9mXGEUIi01DnjGvEFFrvd3iJL2+O8X93fPsKEj6 dyYUYcBj1O5Bx9m3b6fKdrRPvd/qVOoXXUHzay8IgL4f X-Google-Smtp-Source: AOwi7QB4Jb6DySQtEMVfgRysRhas0fZK9yYJAzgnjGqIltlQTh3A8u9OoIP1GDTqD8806TmwRpE4Y2WpaMc1IjoXwzQ= X-Received: by 10.237.58.138 with SMTP id o10mr9217043qte.190.1507193878561; Thu, 05 Oct 2017 01:57:58 -0700 (PDT) MIME-Version: 1.0 Sender: jlehen@gmail.com Received: by 10.12.163.100 with HTTP; Thu, 5 Oct 2017 01:57:57 -0700 (PDT) In-Reply-To: <201710041035.v94AZ4JM095529@fire.js.berklix.net> References: <20171003230438.GA53445@FreeBSD.org> <201710041035.v94AZ4JM095529@fire.js.berklix.net> From: Jeremie Le Hen Date: Thu, 5 Oct 2017 10:57:57 +0200 X-Google-Sender-Auth: fvP8XFHQZcKFmYjPwrEmRVzYpOs Message-ID: Subject: Re: rtools were deemed almost unused 15 years ago... To: "Julian H. Stacey" 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: Thu, 05 Oct 2017 08:57:59 -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. 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 From owner-freebsd-arch@freebsd.org Thu Oct 5 23:10:17 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 A484FE44E97 for ; Thu, 5 Oct 2017 23:10:17 +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 8204065926 for ; Thu, 5 Oct 2017 23:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7E492E44E96; Thu, 5 Oct 2017 23:10:17 +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 7DEE1E44E95 for ; Thu, 5 Oct 2017 23:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.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 46D6A65925 for ; Thu, 5 Oct 2017 23:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id y138so3358980itc.5 for ; Thu, 05 Oct 2017 16:10:17 -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=9nt2/LHmJs8ivi7VzvRYKiQPEChTCAOlA4XJfJh9mH4=; b=nSwg+cxp7AqOctSUbNenx5Nivzj/8aTP5JGtmg9NDGzIE/N84DpE/U4Zoowh9fhiRf QxgPGhOrnQ2gffi951o9TbFqOfp330n3XPouZCmJwkaDVT5pn3bwYI7Do3Px4JVbMaf5 XrBPaFSzz0hLOlA9fbjwoRg1OKlMQ29yCMSL4zgo+VEkaCcfKdGKmb13a8ZYeUAah8P2 mcDHPxxUQKP9DHAPDxnBD+0wWe05IXz5IUG5XoXU0xsfkpBA1lLPNGwiRQYPhGm8UN+G AxCODf+uyCSK4yGypLitj8w7ODu+nbOgLENdpv1TBNeO3tpS1VQIzKgnTy7YO2Uy/nI7 eZZA== 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=9nt2/LHmJs8ivi7VzvRYKiQPEChTCAOlA4XJfJh9mH4=; b=moiRQXn9D0ozX139lFpkGidgjUadowgFW0RvNguJ/buaU/cTqkivKtm1uWSBUr9cbw DE0SX4pZEoKq2mTkYXwANZPLIrdAA9jgoWKLXbP1riJNd6NP8FgUGkxUk7xADtBG/Sq5 AgvxYeCwwkIF6pOWi4cW2gd8SFRq2665p445NxvN+H++AQKbj6QM4HzXhn/10EPk6XD3 Kb1gBNDGKfkRzoHW4DcfNYzb9Jmct2KzI5yXn9hY4cYGtZyyEtYfq1iEK2nFBtBf2nwt NquiVdAHGp6CRAvjd0eetGJsbiCnI4zE5L5xTWQPlGbejxtHg50Mz5U8heSX1ZmBPKls iZug== X-Gm-Message-State: AMCzsaVe/Z0zhUUycgh2YvF0EAUQ907PEhPDSUSpl+RWzrywpOYA5YIS J49c7LUPKh6FBtAlj7qRnSc9RBIlRl7J2rMwnwbtGQ== X-Google-Smtp-Source: AOwi7QC361MMHc0LRUy5oOBCno3sen8QJEa7+zd1Cvby5x7KLmXQqhRnvxRzFjIRG1aKG7Vhsif51Ber1HDXUiQSHck= X-Received: by 10.36.201.4 with SMTP id h4mr231571itg.26.1507245016155; Thu, 05 Oct 2017 16:10:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 16:10:15 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] From: Warner Losh Date: Thu, 5 Oct 2017 16:10:15 -0700 X-Google-Sender-Auth: khhM-yOfQshCiTDkm6AjC742M6g Message-ID: Subject: Heads up: armv7 To: "freebsd-arch@freebsd.org" , "freebsd-arm@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, 05 Oct 2017 23:10:17 -0000 I've pushed in the armv7 support into the tree. Please let me know if there's any problems. It works for me, but I'm sure there's code paths i've not fully explored that will need some explanation. I've added an entry to UPDATING. If there's unanticipated bumps, then I'll update it with workarounds. I've bumped the FreeBSD_version to 1200050. Please let me know if you have problems. Warner From owner-freebsd-arch@freebsd.org Thu Oct 5 23:18: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 C4AB5E45358 for ; Thu, 5 Oct 2017 23:18:52 +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 A162065F99 for ; Thu, 5 Oct 2017 23:18:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id A082BE45357; Thu, 5 Oct 2017 23:18:52 +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 A0105E45356 for ; Thu, 5 Oct 2017 23:18:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 65BF865F98 for ; Thu, 5 Oct 2017 23:18:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id c195so3379295itb.4 for ; Thu, 05 Oct 2017 16:18: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:from:date:message-id:subject:to; bh=Dfd7GoF/4njV66raUefZAgfbwMinWadvJvH111b2gqo=; b=utfvNAje5YIN4z5Bk1d8FN99TpTDaOnrOWYFbp/nQlM3Ueu85DzL0/nzYSojesAiw2 eQyJDmW73fy6Xc4WH+oiq0dwEYBkQaAXac2Ku5YPjJuiLfDvLEOB7jI696ii0G6sCNGP c4gEBXso/Z3rrmmDGtCK+Bb2XJhwYHg+eP7/FoZGYFQmL64OkddvvcVjN3byqZ+Bz/2o A5rS3KfgxYGCl4lwVCiftM9lcSAlZjaTf1jO/SSgQgShdUORQoIl1OqlZXbAM3P/8bM2 SFmN8btDQBGsil1PKZdUggG9RV1QMv69xeRPYWmLKBl5zNkAq/yv7ZeXoRcPCDjGrUes ll1w== 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=Dfd7GoF/4njV66raUefZAgfbwMinWadvJvH111b2gqo=; b=EuSCqEkJuCKOA+x3fwrVpYgSbykZldKq1nolWCHZo2H7oVwrydJZUDTfOtwNZcLa7j i/qPl+vtSeXtQcYeeZL9CdfQ8flaqOrOqfJEPRa8ItYpd5R693NqTRrjgb23lp9Tdb+0 0Sd85phqXjhiThe8TfPZbzvMUMRfMoIK5qSY+hDahB5a/LHpH9TRsNRzjkP70j8/the1 apQW90OjhHQQrCKqhCuQePDgfWZGW1w0lLbTuEaypgYiOvnOh4EdkTpw7D2yxQyTu74a +YNRAFtvyV/O9ovERa0t8XxoekKrI3lS/dMwggOXYGp3UGVQA4Je8k/RUmajtbtGjIJD 5ZkA== X-Gm-Message-State: AMCzsaWLYyy9G/1D1PiiFSJrBUyhvrOpKO9mlKp5qK5q/aru9ZypX/Tk HHYTM1r2QMQQ0HKDOPSKVo/MTOWbHF0IHnmc/ppqCQ== X-Google-Smtp-Source: AOwi7QA8OLqfzKoFEb9hI60nrFVO/kiCz2b08c5GNpIrNVSxfETNPJEAcFZixpjBjGJzSVmHoQ+EAe71SjMkJdHbiPs= X-Received: by 10.36.203.3 with SMTP id u3mr203765itg.136.1507245531523; Thu, 05 Oct 2017 16:18:51 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 16:18:50 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] From: Warner Losh Date: Thu, 5 Oct 2017 16:18:50 -0700 X-Google-Sender-Auth: avhoH5eDQ8otAcsLHYHxVskphnk Message-ID: Subject: C++11 Requirement for base 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: Thu, 05 Oct 2017 23:18:52 -0000 It's desirable that C++11 be fully supported in base. I'd like that to become a hard requirement soon. The jemalloc folks would like to simplify their code by using C++11 (in such a way that C++ wouldn't be required for C programs). That is the forcing function to my this message. The biggest problem doing that is gcc 4.2 still being required for trailing architectures. I'd like to move from vague plans of "eventually" or "before 12" to be a specific date. I'd propose 12/31/17 as the deadline for the trailing architectures to have in place a viable external toolchain support for this as I'd like to remove gcc 4.2 then as well. Comments? Warner From owner-freebsd-arch@freebsd.org Thu Oct 5 23:28:46 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 A2E94E45570 for ; Thu, 5 Oct 2017 23:28:46 +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 7E27F66357 for ; Thu, 5 Oct 2017 23:28:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7A3EDE4556F; Thu, 5 Oct 2017 23:28:46 +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 77FE6E4556E for ; Thu, 5 Oct 2017 23:28:46 +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 3505B66356 for ; Thu, 5 Oct 2017 23:28:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id h66so14751057ioh.11 for ; Thu, 05 Oct 2017 16:28:46 -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=6AxReQyTjPW4CxXFicaMK2OMFx34A9x+gRXKod1ldfM=; b=XPd4D4dkYnaTq9TIRIo0vdKdj33MZl1V5EO9+8BNEPmgBGJQSoZvBLnUlzn2vpEWxI xwizXGSeN3bgW+h4CFakCzSCUa6EuNa+AViSRN99vyeF7kz0g1r1+rMydxPptG69nwRa aB6/k6huNWXLCcdlG/ZKV6KSP9SXf+fdNT2A2BcUD2KGPSySAAq5au4U53vyRmDJHBu9 h5+2M7BFxMjn+8CHgE9LpabUnTTPKXdu7vYiFV5UbF2FMZ4D9E6JX4tYZHLcEeOgXtVJ RE8TZ6xRwlUVm/9uCEglWm76ySrVNoO8uKeX5LPhpS449ol2PZTOeckiMkXk/ZY8I4MZ iIEw== 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=6AxReQyTjPW4CxXFicaMK2OMFx34A9x+gRXKod1ldfM=; b=FcnzgzMVwJ6YB73fd/nYsTO3HgKJY/x9zWF9gr2TOqYOWTEiG7TjeKf+SMInxG4nM0 Rb7afwvs/dEJJQhntE1LFQ3LkXJXD271zZXhHlo8O9UAcK8olCs+pO318+5lw4j31f4G JbD+XZbOfHXR6PZJhE0Wy/jVX5MqoZee94zUOonsMKyfCxFy3qEUmuIhEnMz3+MvCDJH j6287IqfptBLRMYYcLE2dlkx+uq7GaK9gg/C/WkLT+Wppg24o38MHkWX1vrQyEUkalMV j4Qm5MgOzY4H+64wcDB+rlKzHFYUg7s0IvU3EO2zrI7p5vH64O7xNiEwCJlyS1K0Q/ue k5Fg== X-Gm-Message-State: AMCzsaXuat5Cwtk/VFBp7UhmJ1yc9xA3qC7PXNpNn75OOnfdtY9IzOtN /nYLdpJ579ngArG86fTKTCA05ULO0UztQgV43ubJnQ== X-Google-Smtp-Source: AOwi7QAqjLSsZmeJ2znl/vYXsFWfqgXXbfMUVsnuLwccod7JEqumn1JYxu8sueymJ7r2SQvFfuTMkVHsnlBvimqxyog= X-Received: by 10.107.16.162 with SMTP id 34mr319346ioq.169.1507246125394; Thu, 05 Oct 2017 16:28:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 16:28:44 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] From: Warner Losh Date: Thu, 5 Oct 2017 16:28:44 -0700 X-Google-Sender-Auth: eVljSPz35mpat2-PG2fB60mj40E Message-ID: Subject: Making C++11 a hard requirement for FreeBSD 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: Thu, 05 Oct 2017 23:28:46 -0000 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. Comments? Warner From owner-freebsd-arch@freebsd.org Thu Oct 5 23:41: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 306F7E458B9 for ; Thu, 5 Oct 2017 23:41:58 +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 1B30C668A8 for ; Thu, 5 Oct 2017 23:41:58 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by mailman.ysv.freebsd.org (Postfix) id 19D9EE458B8; Thu, 5 Oct 2017 23:41: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 17104E458B7 for ; Thu, 5 Oct 2017 23:41:58 +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 E75A8668A7 for ; Thu, 5 Oct 2017 23:41:57 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E3E135A9F12; Thu, 5 Oct 2017 23:41:49 +0000 (UTC) Date: Thu, 5 Oct 2017 23:41:49 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171005234149.GE8557@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" 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, 05 Oct 2017 23:41:58 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 05, 2017 at 04:28:44PM -0700, Warner Losh wrote: > I'd like to start a conversation about the viability of making C++11 a ha= rd > requirement for bootstrapping FreeBSD and setting a specific deadline for > doing so. >=20 > 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. >=20 > 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. >=20 > 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. This deadline seems viable to me. > 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 th= at > a newer version of gcc as an external toolchain could work. mips64 should be good to go with external clang and lld in LLVM 6.0 and the llvm-devel port should be ready before then (We need to get multi-got support landed upstream and then Alex has a fix for the remaining lld issues). As it is, I run clang built mips64 binaries daily. I'm certain the riscv supporting GCC supports C++11, but we might need to do some testing and tweak some make bits. If someone wants to test sparc64, that's fine, but with Oracle laying off the SPARC it's arguably more dead than IA64 was when we removed it (Intel shipped the last design *this* May). -- Brooks --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZ1sM9AAoJEKzQXbSebgfAMdkIAJNAb/q9qJf6AGZKAebaii9m z8n+FBcIQWQ+Q9BAclHmZG85DrhQnSlablXWta6R8k6S139XWrMr9sbvLh1YRRjA UEa9UwnxvaBNveSZBA1jH5UyoTD2mLuGGeYKiczdiQCczSOMohOzuOHCdpJd3fmQ uAKUaRp7x5P8HPZ2l58RYFG3sHrvdtq8bnuQWXReUfPHuC1ZEqMcl4cgk5Ytrxf2 YYXQypnqKEtxyOlm52F517GX3s87T/noVFcoryV0uLzrb9V0Q8c3rZxfnKBNBQQo lM6XcGz8CyBtMbttVR572cC8cn+9oZ+OCm1nVcaTjy5c8ScrzOqQ1iwG6x/5m28= =rTAM -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-arch@freebsd.org Fri Oct 6 00:05:24 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 808C4E020A4 for ; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@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 6B1BF67399 for ; Fri, 6 Oct 2017 00:05:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6A520E020A3; Fri, 6 Oct 2017 00:05: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 69C2FE020A2; Fri, 6 Oct 2017 00:05:24 +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 42AEA67398; Fri, 6 Oct 2017 00:05:24 +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 DDF3110A8BA; Thu, 5 Oct 2017 20:05:22 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Thu, 05 Oct 2017 16:47:57 -0700 Message-ID: <2116882.XEKuxOb729@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: 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); Thu, 05 Oct 2017 20:05:22 -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: Fri, 06 Oct 2017 00:05:24 -0000 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.) Also, if you svn rm contrib/gcc you will nuke all of our systems because we still use 'crtstuff.c' from there on all architectures for part of the C startup code. emaste@ has looked at a replacement for that from NetBSD in the past but I'm not sure what state that is in currently. Another concern is fully replacing the compiler support libraries (libgcc and friends). Some of those also come from contrib/gcc. For mips I have some patches in review upstream to add mips to LLVM's libunwind (which allows mips to use that for libgcc unwinding). I think sparc64 might be the only other architecture not using llvm libunwind. (Fixing that is a much smaller lift than fixing clang on sparc64 btw, and I've successfully used llvm libunwind on mips worlds that are fully compiled with external GCC.) That said, I definitely support the goal of requiring C++11. I will happily start using it myself in some userland bits (truss for example could benefit from std::unordered_map<>) once it is available across the board. 12/31/17 might be a bit aggressive given the holidays at the end of the quarter, but we can start with that and revisit if need be. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Oct 6 00:19:15 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 CC689E02813 for ; Fri, 6 Oct 2017 00:19:15 +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 B508067A08 for ; Fri, 6 Oct 2017 00:19:15 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 31629 invoked from network); 6 Oct 2017 00:12:31 -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; 6 Oct 2017 00:12:31 -0000 Subject: Re: Making C++11 a hard requirement for FreeBSD To: freebsd-arch@freebsd.org References: <20171005234149.GE8557@spindle.one-eyed-alien.net> From: "A. Wilcox" Message-ID: <59D6CA6C.1040502@Wilcox-Tech.com> Date: Thu, 5 Oct 2017 19:12:28 -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: <20171005234149.GE8557@spindle.one-eyed-alien.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="slrISh42cF5UXu3P1CXAIa3Me4SDD0a6d" 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: Fri, 06 Oct 2017 00:19:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --slrISh42cF5UXu3P1CXAIa3Me4SDD0a6d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05/10/17 18:41, Brooks Davis wrote: > On Thu, Oct 05, 2017 at 04:28:44PM -0700, Warner Losh wrote: >> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 a= re >> 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. >=20 > If someone wants to test sparc64, that's fine, but with Oracle laying > off the SPARC it's arguably more dead than IA64 was when we removed it > (Intel shipped the last design *this* May). >=20 > -- Brooks >=20 Thinking out loud: 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). That could make the sparc64 port not only more widely used, but more widely tested, with more potential developers. Or maybe not. I can't see the future :) --arw --=20 A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ --slrISh42cF5UXu3P1CXAIa3Me4SDD0a6d 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 iQIcBAEBCAAGBQJZ1spsAAoJEMspy1GSK50Us7gP/1nUIhKjsRg+59JjW4DkKeD7 VGnURu2EkJh6nAJEFstA1Z6KB/9cWDt1uqsxqxQbgSstziClIJhOnsp0T+UiflFK IdHFAk8MXgH3D+hRSz7BVaKQyn5ShT3lrTQR8IR3EUO4ej6Az5DBUg/ApSEV6BTU 7ebgGn/jw8A6qHTAITIvi7YYZO9LwATuxhkEDqT5xKQaNNS4hrDTVjc8lsrSU911 Qee3lh+lvRkpqf5+ysoE23W0DJKe39R4CCw9e0issUSHsm+05f9Ji+C7ItpmPZat czcWGla763d67vWZdSfHtyEnWg1gV2qbCR/N74OQT6GBnRzX0XV4PPARqIo/a4qe 5GxMjJ6kYRRH8NVllV7YwLbkZR8KsGVZRB8wkjdKp08bPhM5tLd9K1GiXnbUc14o CcDaFHLymdciAEQA1V6mD7SRihHli7BSWcY1zCREz/yrALaLifOIVpkBYj4QbEAY PrDb8nxnwcXCZd8yFgswFH1DiYHvkg0Iv0T6BQvfPxaByxJ5dmQf2iv7bAezmdbN WlVzdTXFnW96iS8HCG/EAug87SrtgUXPF1Hcf0NXw0OQ7PxPbHDQ87/L4YbbIYPP gznw9Mq5wrdz8ZNxHSRBiJzh5tmCgBeLrSLe3askLHyTc7cDIPzDAY+s8uDgNQzt qRDvnb4ulphPIPp8vwDT =KaIF -----END PGP SIGNATURE----- --slrISh42cF5UXu3P1CXAIa3Me4SDD0a6d-- From owner-freebsd-arch@freebsd.org Fri Oct 6 07:20:11 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 95FDBE2EE68; Fri, 6 Oct 2017 07:20:11 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0707231F; Fri, 6 Oct 2017 07:20:11 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id C49351C8C0; Fri, 6 Oct 2017 07:20:10 +0000 (UTC) Date: Fri, 6 Oct 2017 09:20:10 +0200 From: Baptiste Daroussin To: John Baldwin Cc: freebsd-arch@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> References: <2116882.XEKuxOb729@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hxaughgijyfspz4y" Content-Disposition: inline In-Reply-To: <2116882.XEKuxOb729@ralph.baldwin.cx> User-Agent: NeoMutt/20170912 (1.9.0) 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: Fri, 06 Oct 2017 07:20:11 -0000 --hxaughgijyfspz4y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 f= or > > doing so. > >=20 > > 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 beca= use > > this has become a frequent request (but if you have opinions, please fi= nd > > the thread in current@ about it). I don't know the timeline of their pl= ans > > to do this. > >=20 > > I'd like to take the rather vague plans we've had "before 12" and creat= e 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 construc= ts. > >=20 > > I'd like to propose we do this 12/31/17. Any architectures that can't m= eet > > this timeline will be disconnected from universe at that time and delet= ed > > 3/31/18. > >=20 > > 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. >=20 > In-tree clang 5.0 for MIPS mostly works (modulo some small patches). How= ever, > 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-cap= able. >=20 > 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. Howeve= r, > 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 anyo= ne > has thought about how release builds will work either with only an extern= al > 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. >=20 > Also, if you svn rm contrib/gcc you will nuke all of our systems because = we > still use 'crtstuff.c' from there on all architectures for part of the C > startup code. emaste@ has looked at a replacement for that from NetBSD in > the past but I'm not sure what state that is in currently. >=20 > Another concern is fully replacing the compiler support libraries (libgcc= and > friends). Some of those also come from contrib/gcc. For mips I have some > patches in review upstream to add mips to LLVM's libunwind (which allows = mips > to use that for libgcc unwinding). I think sparc64 might be the only oth= er > architecture not using llvm libunwind. (Fixing that is a much smaller li= ft > than fixing clang on sparc64 btw, and I've successfully used llvm libunwi= nd > on mips worlds that are fully compiled with external GCC.) >=20 > That said, I definitely support the goal of requiring C++11. I will happ= ily > start using it myself in some userland bits (truss for example could bene= fit > from std::unordered_map<>) once it is available across the board. >=20 > 12/31/17 might be a bit aggressive given the holidays at the end of the > quarter, but we can start with that and revisit if need be. >=20 I'm fine with that date. Best regards, Bapt --hxaughgijyfspz4y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlnXLqcACgkQY4mL3PG3 PlrvUw//b+q++HQ/9nxMifoWutZk00Z42OThSJwiKbg4yAkmVz27OBgqCsUlOLZP SubeiDoMgkACOsZcB0j0yS/uF/NuUH/t4bAyHokmXF1u+CIB/CDZcq1WI0QkaUce nDYFPT42lMugCTdFbzFYT0H2XlBZt6+U9pr56eRVMdGSJHs44lVg1rY1ZHho6Gx/ 1Jb3q8Jt+sSJiu2VsAwDL7hQHa8ViBa4NuMqNl9U1e0lQYJTryQGuLf1VCl4tdnD 8BvzyGJFDJfgMLTk8BM11+mtyhOCgWXlpccjHASUgJgDrIXVpUc4svPluUD8K12d Q/BiWROAjfnDC/ZRp3C9FAqzYK9dMRRhPn8VC8Ufx/W5KJE4Hr5XphCDpVMDO3Ac CuDUgpSsHTjsCUUeHqshqD33/jaVu1wszka7m1QSVMTX7bfp2dgqcsOx/3pwHGFO tAuQrauxI1irsuNrJT1EhpWMXtKksL4hmXrcI/kAetVLhmhmrtpneGg5fM515BCL +dAllB8AoaT9GcYdpunVA7QWloKxOV3BwXSXjc8zgMqD2XxZe0GNAkWws6Pli9KQ SbaTG5tIwfc7aGGvwXieJW8DuNOcd1EByOEaxIaAK7lFwmqiE9BV2kjLpoY+JovE Fu/zItcMJFOuVRK2LKy713kbC3CbNyo2sk22zDmPXNu2whl4phg= =M5s0 -----END PGP SIGNATURE----- --hxaughgijyfspz4y-- From owner-freebsd-arch@freebsd.org Fri Oct 6 16:43: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 CA165E3B740 for ; Fri, 6 Oct 2017 16:43:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A8C0965BCB for ; Fri, 6 Oct 2017 16:43:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A50ECE3B73F; Fri, 6 Oct 2017 16:43:52 +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 A4B5BE3B73E for ; Fri, 6 Oct 2017 16:43:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B2BD65BCA for ; Fri, 6 Oct 2017 16:43:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id u138so8613346wmu.5 for ; Fri, 06 Oct 2017 09:43:52 -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=rpU6f0ml3/cZhBHRNLvWH52g1Sgttk8Pbjy2HVypb9Y=; b=kbMfc5iidMX1bFrfrOajQlwxC9paZhAqrL0kLcZfHXicqVIIxzKDHG9P08VOiNPq30 lr9BoKNoptVD9OgcloNvUFfJJUFdt+tgREijO/Ug/RUmlJgNJNX8uYUDkARnFXH6YpTf bPVUix9pdzDmiW+Qv2c2/11fBwRkARPcxeM9hpvlRG05qHfSDLiHD65b3h3isMVuZVFY Eq3mVVbfhRj4oLpeLFrm2jiksjy8k1ypOgNBAQGGoYPqmD381BXf1AMGbSAIOlA7hmPX /29I7yVhhX6fCgwMlQPhltFaPsbs692qjmL6SsZoXi0gOm0NzofY1D1VFGDAbUdvAzpd M7kQ== 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=rpU6f0ml3/cZhBHRNLvWH52g1Sgttk8Pbjy2HVypb9Y=; b=q9E0C1NPHp7kkPuvfJrpBGMSn3otbVFWoDXVhARuAA6fIz7nnMoGuxblq+JdQaU3vd 8fIUNz5v5QEtOd1YQZo8EPm8Fr3LM7brGFGPOjcclJDkOKhlGKSFyZFhShZA1CsK7Ygl 1a7phkpSRXIYn2C6OuYqEhCIScdtUDg5uhlOW05IszgOOKoGABeEFA8NFa21idVF/hqV 92pcfSXOgu0e9BG/lqayZaYz5SCZPcvOE+wSjb5kIUb2WTk6mf12qXoHFGVl1WlhSXaY zir5GIJdh1PJhqNEKGlN3qfO+54IQ6Lim/bgKYewS48Prl/jcOWTP2TtQlh01En093u4 Xm8Q== X-Gm-Message-State: AMCzsaX5qDhY3i7k8gmWJgqXaJTyZaZmMm3Rm8Btq5oA5i3+3Dj9bXlb uvxv8D2L+9e+YC1KvPq4mj6huWusMvHhdZ+X+C0= X-Google-Smtp-Source: AOwi7QBOBNimyIUDeWcS7G2oRW/Ir0oItiTdWYjtPvwOAXe+6wq8VQbjp6dnawaGLYNtWhPUb5hx97L+EOpIApxZb7s= X-Received: by 10.28.135.5 with SMTP id j5mr2495978wmd.21.1507308230053; Fri, 06 Oct 2017 09:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.86.70 with HTTP; Fri, 6 Oct 2017 09:43:49 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Fri, 6 Oct 2017 09:43:49 -0700 Message-ID: Subject: Re: C++11 Requirement for base 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: Fri, 06 Oct 2017 16:43:52 -0000 On 5 October 2017 at 16:18, Warner Losh wrote: > It's desirable that C++11 be fully supported in base. I'd like that to > become a hard requirement soon. The jemalloc folks would like to simplify > their code by using C++11 (in such a way that C++ wouldn't be required for > C programs). That is the forcing function to my this message. > > The biggest problem doing that is gcc 4.2 still being required for trailing > architectures. I'd like to move from vague plans of "eventually" or "before > 12" to be a specific date. I'd propose 12/31/17 as the deadline for the > trailing architectures to have in place a viable external toolchain support > for this as I'd like to remove gcc 4.2 then as well. > > Comments? pleaaase deorbit gcc-4.2 finally! ;) -adrian From owner-freebsd-arch@freebsd.org Fri Oct 6 16:55:31 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 05B96E3BBA7 for ; Fri, 6 Oct 2017 16:55:31 +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 E3AF5662A3 for ; Fri, 6 Oct 2017 16:55:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id E3126E3BBA6; Fri, 6 Oct 2017 16:55:30 +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 E29D1E3BBA5; Fri, 6 Oct 2017 16:55:30 +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 ABB44662A2; Fri, 6 Oct 2017 16:55:30 +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 55C10273A4; Fri, 6 Oct 2017 16:48:04 +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 v96GlmvQ029631; Fri, 6 Oct 2017 16:47:48 GMT (envelope-from phk@phk.freebsd.dk) To: Baptiste Daroussin cc: John Baldwin , "freebsd-arch@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD In-reply-to: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: "Poul-Henning Kamp" References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29629.1507308468.1@critter.freebsd.dk> Date: Fri, 06 Oct 2017 16:47:48 +0000 Message-ID: <29630.1507308468@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: Fri, 06 Oct 2017 16:55:31 -0000 If we allow C++ in libc, it should not merely be for the convenience of a few programmers, but because we have a vision for how it that makes the world, or at least FreeBSD, a better place. Having C++ in libc is no trivial detail, there is a number of areas where this causes bootstrapping issues and conflicts. We can solve those issues with unsightly local hacks, most notably a bogo-malloc to malloc while C++ constructs jemalloc. But hand on heart, we all know that is a bad idea, all of us have been down that road before, and we also know that there is no way to be a little bit pregnant. The other way, the right way, to accomodate the jemalloc request is to go all in. Nothing in the ISO verbiage says that you cannot have C and C++ runtimes in the same library, as long as your linker knows the zip code of it. Libc as a combined C and C++ runtime can be implemented a lot cleaner than a libc which hides C++ components in the closet. So that is my input to this question: Either we tell the jemalloc people "sorry, it's called libc for a reason" or we decide to make our libc a native C *and* C++ runtime. I see no sane or even possible "middle ground" or compromise position. Poul-Henning -- 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 Fri Oct 6 18:41: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 47B4BE3E5B4 for ; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 23E366A5AE for ; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 20378E3E5AD; Fri, 6 Oct 2017 18:41: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 1FB3CE3E5AB; Fri, 6 Oct 2017 18:41:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 A771C6A5AC; Fri, 6 Oct 2017 18:41:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id k66so7365823wmd.4; Fri, 06 Oct 2017 11:41:01 -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=JviZBxwCn7c+LM4bsaPOhWyKV3CEnnnIm+hBBbe4n8Y=; b=sG05YUF03okNbngTwG3+qc/3MomJTf7IPladVCv4dHN8JiiC2zF7ZxHs2tOrwHlp5f KrgBSuX+OEvhjdjrOIfNMHK3JFm1NuoUAAfydaND8TEwjOL8UXAQlkAZyASWkPqH0hou pvc/sssEx2K5DBA7PfL18WFDS5vOo105ryGxh3Z1grK0rCEVC86RNijKHtGts8Qr+QkS nYJ30Eydn94Nn15R+D/dMenGtFUdO+BG0QInCihd3v/MllRHTvEEry8Fo4a1CUy56GSl zA77+v0jQG7CcZ9Td5bQ0po9T+8gbMvaed+ksklk3mM/V5vKEZCHUHWMU3W+R2OL5Uem 4xeg== 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=JviZBxwCn7c+LM4bsaPOhWyKV3CEnnnIm+hBBbe4n8Y=; b=kykTArcs5e2uN3o9b9WqfAhPuR2Bvc+sQg6zJ5u+PWYUFgvx7F9p1SB/GnU6f311xV fxEXzpq4IVIqlCUlAU6sISW9ySfzwvul975kIA5vxNhzC8fFtm/TcsT4iI3QTYMJxk5E UMELNkPDuXjZxBQu+e4JnByY4SOsu2Q+AbDtLVwCNIQTTqPlDoW+c3heXYoT7lKZ2/v7 rAquTL7ux19K0dKrUR1s2bJKplgjTF3IWEX6NFlnEhbr/icvIyxYllB2AG6YgAb4UlIY rAc8l3Ygjm1rBNW5qMzKDXlSRIjLkrSFJfUPryJX+MWHToPzbMfNc/LPyr+bvIrwkPe2 Pgaw== X-Gm-Message-State: AMCzsaUXQ/XAYj9QrWeX/rd/BL+zA1m/GC04rlh+wrCFf6psON7x2YGm v6zsPi/94TpkssnKxC6kBszGEU+TbxEZc7eR97gzeQ== X-Google-Smtp-Source: AOwi7QCUyuSw8hB1D4ncCyT07fn/LicsgTAHbCgkeiBZiX59nLP8pcov1rfo5aV2iBIu5+Kc8E7Tgl7W7bBAlgyZuCY= X-Received: by 10.223.145.105 with SMTP id j96mr2758275wrj.273.1507315260173; Fri, 06 Oct 2017 11:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.86.70 with HTTP; Fri, 6 Oct 2017 11:40:59 -0700 (PDT) In-Reply-To: <29630.1507308468@critter.freebsd.dk> References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> From: Adrian Chadd Date: Fri, 6 Oct 2017 11:40:59 -0700 Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Poul-Henning Kamp Cc: Baptiste Daroussin , "freebsd-arch@freebsd.org" , "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: Fri, 06 Oct 2017 18:41:02 -0000 On 6 October 2017 at 09:47, Poul-Henning Kamp wrote: > If we allow C++ in libc, it should not merely be for the convenience > of a few programmers, but because we have a vision for how it that > makes the world, or at least FreeBSD, a better place. > > Having C++ in libc is no trivial detail, there is a number of areas > where this causes bootstrapping issues and conflicts. > > We can solve those issues with unsightly local hacks, most > notably a bogo-malloc to malloc while C++ constructs jemalloc. > > But hand on heart, we all know that is a bad idea, all of us have > been down that road before, and we also know that there is no way > to be a little bit pregnant. > > The other way, the right way, to accomodate the jemalloc request > is to go all in. > > Nothing in the ISO verbiage says that you cannot have C and C++ > runtimes in the same library, as long as your linker knows the zip > code of it. > > Libc as a combined C and C++ runtime can be implemented a lot cleaner > than a libc which hides C++ components in the closet. > > So that is my input to this question: > > Either we tell the jemalloc people "sorry, it's called libc for a > reason" or we decide to make our libc a native C *and* C++ runtime. > > I see no sane or even possible "middle ground" or compromise position. I don't mind it as long as it's "no C++ runtime bloat please". But yes, I also feel the pain of where you start that path and then suddenly you find you're al in that path. (I face this at work right now on linux platforms because a "little C++" becomes .. not little.) -adrian From owner-freebsd-arch@freebsd.org Fri Oct 6 23:21:17 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 22786E43EED for ; Fri, 6 Oct 2017 23:21:17 +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 0C836738E9 for ; Fri, 6 Oct 2017 23:21:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 087D7E43EEC; Fri, 6 Oct 2017 23:21:17 +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 07E91E43EEB; Fri, 6 Oct 2017 23:21:17 +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 CE33E738E1; Fri, 6 Oct 2017 23:21:15 +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 6E76B10A7DB; Fri, 6 Oct 2017 19:21:13 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp Cc: Baptiste Daroussin , "freebsd-arch@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Fri, 06 Oct 2017 16:21:05 -0700 Message-ID: <2706092.qpavixPdKK@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <29630.1507308468@critter.freebsd.dk> References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> 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); Fri, 06 Oct 2017 19:21:13 -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: Fri, 06 Oct 2017 23:21:17 -0000 On Friday, October 06, 2017 04:47:48 PM Poul-Henning Kamp wrote: > If we allow C++ in libc, it should not merely be for the convenience > of a few programmers, but because we have a vision for how it that > makes the world, or at least FreeBSD, a better place. > > Having C++ in libc is no trivial detail, there is a number of areas > where this causes bootstrapping issues and conflicts. > > We can solve those issues with unsightly local hacks, most > notably a bogo-malloc to malloc while C++ constructs jemalloc. > > But hand on heart, we all know that is a bad idea, all of us have > been down that road before, and we also know that there is no way > to be a little bit pregnant. > > The other way, the right way, to accomodate the jemalloc request > is to go all in. > > Nothing in the ISO verbiage says that you cannot have C and C++ > runtimes in the same library, as long as your linker knows the zip > code of it. > > Libc as a combined C and C++ runtime can be implemented a lot cleaner > than a libc which hides C++ components in the closet. > > So that is my input to this question: > > Either we tell the jemalloc people "sorry, it's called libc for a > reason" or we decide to make our libc a native C *and* C++ runtime. > > I see no sane or even possible "middle ground" or compromise position. Hmm, I don't quite agree. I think it's possible to use a restricted C++ (no rtti, no exceptions, no STL) such that you are only using language features like templates or 'auto' without requiring runtime support. I think that is the requirement we would place on the jemalloc implementation for it to remain in libc. Right now the C++ runtime is split into a couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti / exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* along with intrinsics from compiler-rt). All of these are variable in some sense (if you wanted to build a GCC-based system you might want to use libstdc++ instead of libc++, libgcc_s already varies by platform, and upstream in LLVM there is already a libcxxabi alternative to libcxxrt plus the GNU libsupc++). I think bundling any of those pieces into libc makes our system less flexible and different from all the other UNIXy systems currently in vogue. -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Oct 7 00:04:57 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 2C907E44A4B for ; Sat, 7 Oct 2017 00:04:57 +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 18A2674951 for ; Sat, 7 Oct 2017 00:04:57 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 14889E44A4A; Sat, 7 Oct 2017 00:04:57 +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 1179CE44A49; Sat, 7 Oct 2017 00:04:57 +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 C5D1374950; Sat, 7 Oct 2017 00:04:56 +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 0872D2738F; Sat, 7 Oct 2017 00:04:54 +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 v9704c30030850; Sat, 7 Oct 2017 00:04:39 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin cc: "freebsd-arch@freebsd.org" , Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD In-reply-to: <2706092.qpavixPdKK@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30848.1507334678.1@critter.freebsd.dk> Date: Sat, 07 Oct 2017 00:04:38 +0000 Message-ID: <30849.1507334678@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: Sat, 07 Oct 2017 00:04:57 -0000 -------- In message <2706092.qpavixPdKK@ralph.baldwin.cx>, John Baldwin writes: >Hmm, I don't quite agree. I think it's possible to use a restricted C++ >(no rtti, no exceptions, no STL) such that you are only using language >features like templates or 'auto' without requiring runtime support. That's what Bjarne used to call "C++ as a better C compiler". If the jemalloc crew can stay inside that dotted line _and_ the C++ compilers still allow you to do so, then that could be an "not quite pregnant yet" option. >[...] >Right now the C++ runtime is split into a >couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti >/ exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* >along with intrinsics from compiler-rt). >[...] >I think bundling any of those pieces into libc makes our system less >flexible and different from all the other UNIXy systems currently in >vogue. That goes to my point about ld: The standard doesn't say which library file which bits of the C++ runtime have to go into, we get to decide that if we want to, as long as we provide a ld(1) which knows where to find things. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Sat Oct 7 08:24: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 75696E31C62; Sat, 7 Oct 2017 08:24:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 06B8D63DD8; Sat, 7 Oct 2017 08:24:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v978OBvK096483 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Oct 2017 11:24:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v978OBvK096483 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v978OBnY096482; Sat, 7 Oct 2017 11:24:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Oct 2017 11:24:11 +0300 From: Konstantin Belousov To: John Baldwin Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171007082411.GU95911@kib.kiev.ua> References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2706092.qpavixPdKK@ralph.baldwin.cx> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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, 07 Oct 2017 08:24:18 -0000 On Fri, Oct 06, 2017 at 04:21:05PM -0700, John Baldwin wrote: > On Friday, October 06, 2017 04:47:48 PM Poul-Henning Kamp wrote: > > If we allow C++ in libc, it should not merely be for the convenience > > of a few programmers, but because we have a vision for how it that > > makes the world, or at least FreeBSD, a better place. > > > > Having C++ in libc is no trivial detail, there is a number of areas > > where this causes bootstrapping issues and conflicts. > > > > We can solve those issues with unsightly local hacks, most > > notably a bogo-malloc to malloc while C++ constructs jemalloc. > > > > But hand on heart, we all know that is a bad idea, all of us have > > been down that road before, and we also know that there is no way > > to be a little bit pregnant. > > > > The other way, the right way, to accomodate the jemalloc request > > is to go all in. > > > > Nothing in the ISO verbiage says that you cannot have C and C++ > > runtimes in the same library, as long as your linker knows the zip > > code of it. > > > > Libc as a combined C and C++ runtime can be implemented a lot cleaner > > than a libc which hides C++ components in the closet. > > > > So that is my input to this question: > > > > Either we tell the jemalloc people "sorry, it's called libc for a > > reason" or we decide to make our libc a native C *and* C++ runtime. > > > > I see no sane or even possible "middle ground" or compromise position. > > Hmm, I don't quite agree. I think it's possible to use a restricted C++ > (no rtti, no exceptions, no STL) such that you are only using language > features like templates or 'auto' without requiring runtime support. I > think that is the requirement we would place on the jemalloc implementation > for it to remain in libc. This is a requirement not only on jemalloc, but also on the compilers. I am much more worried about C++ compiler's runtime requirements than the ability of the jemalloc developers to restrict used language features to the subset which does not need some external support _at the current compiler version_. Seeing the route that clang took making C compiler unusable for normal work, I am just sure that clang++ would cause a lot of troubles if we ever try to rely on the undocumented and unpromised detail of the current implementation. > Right now the C++ runtime is split into a > couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti > / exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* > along with intrinsics from compiler-rt). All of these are variable in > some sense (if you wanted to build a GCC-based system you might want to > use libstdc++ instead of libc++, libgcc_s already varies by platform, > and upstream in LLVM there is already a libcxxabi alternative to libcxxrt > plus the GNU libsupc++). > > I think bundling any of those pieces into libc makes our system less > flexible and different from all the other UNIXy systems currently in > vogue. This also hits the ABI stability hard, see my other reply. From owner-freebsd-arch@freebsd.org Sat Oct 7 08:32:17 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 D681DE31FAD; Sat, 7 Oct 2017 08:32:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 650CC64702; Sat, 7 Oct 2017 08:32:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v978WCqR098643 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Oct 2017 11:32:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v978WCqR098643 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v978WCkc098642; Sat, 7 Oct 2017 11:32:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Oct 2017 11:32:12 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Cc: John Baldwin , "freebsd-arch@freebsd.org" , Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171007083212.GV95911@kib.kiev.ua> References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx> <30849.1507334678@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30849.1507334678@critter.freebsd.dk> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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, 07 Oct 2017 08:32:18 -0000 On Sat, Oct 07, 2017 at 12:04:38AM +0000, Poul-Henning Kamp wrote: > -------- > In message <2706092.qpavixPdKK@ralph.baldwin.cx>, John Baldwin writes: > > >Hmm, I don't quite agree. I think it's possible to use a restricted C++ > >(no rtti, no exceptions, no STL) such that you are only using language > >features like templates or 'auto' without requiring runtime support. > > That's what Bjarne used to call "C++ as a better C compiler". > > If the jemalloc crew can stay inside that dotted line _and_ the C++ > compilers still allow you to do so, then that could be an "not quite > pregnant yet" option. > > >[...] > > >Right now the C++ runtime is split into a > >couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti > >/ exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* > >along with intrinsics from compiler-rt). > >[...] > >I think bundling any of those pieces into libc makes our system less > >flexible and different from all the other UNIXy systems currently in > >vogue. > > That goes to my point about ld: The standard doesn't say which > library file which bits of the C++ runtime have to go into, we > get to decide that if we want to, as long as we provide a ld(1) > which knows where to find things. This is not how linkers work. The language standard does not say that, but the platform standards do: system ABI very much put the symbol origin in a stone. Dynamic libraries expose symbols under versions, if we ever expose some symbol under the specific version, we promise to do so to the end of times (or we break the ABI promise of stability). C++ runtime external symbols are already exported from the specific set of libraries. There are some tricks like filter objects which could somewhat alleviate the move, but maintaining them for third-party libs is too much efforts to ask, for almost no visible effect until things break. And of course there are parts of the C++ ABI which are underspecified by the Itanium ABI, which means that the ABI is not yet stable. Also we get the tie for specific compiler implementation, which runtime is imported. Since other compiler ABI is partially incompatible, but only partially, the other compiler would be impossible to use: some symbols resolution would come from our libc, some from the compiler libraries. From owner-freebsd-arch@freebsd.org Sat Oct 7 17:41: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 78436E3DAAE; Sat, 7 Oct 2017 17:41:40 +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 B08696C663; Sat, 7 Oct 2017 17:41:35 +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 CFD61738; Sat, 7 Oct 2017 12:41:25 -0500 (CDT) Date: Sat, 7 Oct 2017 12:41:24 -0500 From: Mark Linimon To: "A. Wilcox" Cc: freebsd-arch@freebsd.org, freebsd-sparc64@FreeBSD.org Subject: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171007174124.GA20810@lonesome.com> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59D6CA6C.1040502@Wilcox-Tech.com> 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, 07 Oct 2017 17:41:40 -0000 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?) But here's the current problem. 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. Neither Marcel nor Gerald nor I have any insight on how to fix this. Gerald does state that those gccs build on other OSes, so this is almost certainly a FreBSD problem. The default ports compiler has recently moved to gcc5 and then again to gcc6. The only reason gcc49 still exists in the Ports Collection is specifically for sparc64 ports. Recent llvms do not build. I have no insight into that failure, either. So, the long and short is, even with using gcc4.2.1 as an external compiler, over time, fewer and fewer ports build as they adapt to the newer compilers. This is something I don't have the cycles to fix. Unless someone else can step up and fix the compilers, we're close to the end of feasibility. In the meantime, I'll keep running package builds with gcc4.9 as long as it produces some kind of useful results. I'll be happy to discuss the build status of individual ports, but let's have that on sparc64@ rather than arch@, please. mcl From owner-freebsd-arch@freebsd.org Sat Oct 7 19:14: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 1D01CE3FB4D; Sat, 7 Oct 2017 19:14:22 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (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 53ED8C1; Sat, 7 Oct 2017 19:14:20 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-oi0-f48.google.com with SMTP id v9so22021799oif.13; Sat, 07 Oct 2017 12:14:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPvoRjzDkrOh2gqECtCvXqOOStP/7S1Sn/8xaXvdRgs=; b=Ig16zcY4uyxJ+l5st/1V/Hmbh/bZIPlluQVOxcT9LQTEW8FQiBqF5LMfXxyqvcvPu5 F8Cd9Rum+7pjK2pCO1fTIRCr//BgOOmJY+pbjErQBsnbCEDiEttXlt5TZKvrhJoGj11q 8w9Q0DwtPenxUClVKf0Nonm9XWpPo9nyOCxcnbQQD9M+i1THkMKFNXh2wPs8FUJsLt5j nKBUN0qPZ1RaDnNKZ5YWWYq9KjPGzs2jwpq21SmprSWC/sQHPpb+zS4PUZ6OAfn1Dp8t fZF17UjXsYiqBDbITzeM492Gjtnd60+L0y8UXvHxv5Uq8HiQTkIMA0supx8tkZWXSzk4 MwWw== X-Gm-Message-State: AMCzsaU4YBNOyB+o8pXFiplkbPOYZUTbbCZ85cgQVQhh5U5JmYwXSrEX qxAx7m4UjAhnvdf+OwRh8BHmscmHkc7dOC2f3wo= X-Google-Smtp-Source: AOwi7QDjzDYGo4YmoL4skBKyuyFw0IL5Gsz8SNYKpBKctOzlRc+2Kxk//H0O28njfvHr3anOVdTvujXIbIZpRbOq7u0= X-Received: by 10.157.4.37 with SMTP id 34mr3829440otc.156.1507403199627; Sat, 07 Oct 2017 12:06:39 -0700 (PDT) MIME-Version: 1.0 References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> In-Reply-To: <20171007174124.GA20810@lonesome.com> From: "K. Macy" Date: Sat, 07 Oct 2017 19:06:29 +0000 Message-ID: Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) To: "A. Wilcox" , Mark Linimon Cc: freebsd-arch@freebsd.org, freebsd-sparc64@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sat, 07 Oct 2017 19:14:22 -0000 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?) > > But here's the current problem. > > 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. > > Neither Marcel nor Gerald nor I have any insight on how to fix this. > Gerald does state that those gccs build on other OSes, so this is almost > certainly a FreBSD problem. > > The default ports compiler has recently moved to gcc5 and then again > to gcc6. The only reason gcc49 still exists in the Ports Collection is > specifically for sparc64 ports. > > Recent llvms do not build. I have no insight into that failure, either. > > So, the long and short is, even with using gcc4.2.1 as an external > compiler, over time, fewer and fewer ports build as they adapt to the > newer compilers. > > This is something I don't have the cycles to fix. Unless someone else > can step up and fix the compilers, we're close to the end of feasibility. > > In the meantime, I'll keep running package builds with gcc4.9 as long as > it produces some kind of useful results. 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. If someone wants to fix it that=E2=80= =99s where to look. I think that FreeBSD needs to always have one big-endian arch and one arch that requires IOMMU. Bonus points if it fulfills both. For a time that was sparc64. These days other arches meet that need. And at this point the most recent hardware supported by the sparc64 port shipped in ~2003. One could amortize the cost of a low end 2017 server in just the power bill within a year. I don=E2=80=99t know how much work continuing to = maintain sparc64 really adds to non sparc64 enthusiasts. Nonetheless, it is non-zero= . -M From owner-freebsd-arch@freebsd.org Sat Oct 7 19: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 E52D3E3FF20; Sat, 7 Oct 2017 19:20:27 +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 580F7183A; Sat, 7 Oct 2017 19:20:26 +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 9F053738; Sat, 7 Oct 2017 14:20:25 -0500 (CDT) Date: Sat, 7 Oct 2017 14:20:24 -0500 From: Mark Linimon To: "K. Macy" Cc: "A. Wilcox" , freebsd-arch@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171007192024.GA21581@lonesome.com> 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: 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, 07 Oct 2017 19:20:28 -0000 On Sat, Oct 07, 2017 at 07:06:29PM +0000, K. Macy wrote: > I think that FreeBSD needs to always have one big-endian arch IMHO it keeps things honest. fwiw, if you fix a port on sparc64 it will usually fix it on powerpc64 and vice versa (~80% correlation). But powerpc64 has a (hardware) future and sparc64 doesn't. I run both at home, but not the powerpc64 continuously. (Actually first typed "4U" it as "$U". Same idea.) So, I'm willing to help keep it going (and even loan a machine to the effort), but I am overcommitted in other areas already. mcl