From owner-freebsd-arch@freebsd.org Sun May 27 19:56:04 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A4B2F7E776 for ; Sun, 27 May 2018 19:56:04 +0000 (UTC) (envelope-from joel@vnode.se) 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 B17AE6B867 for ; Sun, 27 May 2018 19:56:03 +0000 (UTC) (envelope-from joel@vnode.se) Received: by mailman.ysv.freebsd.org (Postfix) id 7517DF7E774; Sun, 27 May 2018 19:56:03 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 611D7F7E773 for ; Sun, 27 May 2018 19:56:03 +0000 (UTC) (envelope-from joel@vnode.se) Received: from oden.vnode.se (oden.vnode.se [IPv6:2001:19f0:6c01:6b7:5400:1ff:fe33:16b1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oden.vnode.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0F0C6B865; Sun, 27 May 2018 19:56:02 +0000 (UTC) (envelope-from joel@vnode.se) Received: from ymer.vnode.se (62-20-154-136-no280.tbcn.telia.com [62.20.154.136]) by oden.vnode.se (Postfix) with ESMTPSA id 2777A1F694; Sun, 27 May 2018 21:55:54 +0200 (CEST) Date: Sun, 27 May 2018 21:55:53 +0200 From: Joel Dahl To: John Baldwin Cc: arch@freebsd.org Subject: Re: RFC: Create a default wlan for wireless NICs Message-ID: <20180527195553.GA48909@ymer.vnode.se> Mail-Followup-To: John Baldwin , arch@freebsd.org References: <6686653.ooTk0CQ0bF@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6686653.ooTk0CQ0bF@ralph.baldwin.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 19:56:04 -0000 On Fri, May 25, 2018 at 02:28:42PM -0700, John Baldwin wrote: > From the bikeshed department.... > > The change at https://reviews.freebsd.org/D15481 would create a default > wlan for wireless NICs by default. The default wlan's ifnet name would > match the name of the adapter (e.g. "iwn0"). Existing configurations > would still be honored and people who need multiple wlan devices can > still do so using existing configuration variables in rc.conf, etc. > > However, the out of the box experience on a new machine would be that > 'ifconfig iwn0' would Just Work(tm) for wireless NICs as it does now for > wired NICs, and you could just use 'ifconfig_iwn0="WPA DHCP"' in rc.conf. > I think this is more consistent with how we present NICs to users in > general. Yes. Do it. :-) -- Joel From owner-freebsd-arch@freebsd.org Mon May 28 02:29:01 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 380BBEF4A5B for ; Mon, 28 May 2018 02:29:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C1342777B4 for ; Mon, 28 May 2018 02:29:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7F79AEF4A57; Mon, 28 May 2018 02:29:00 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CFBFEF4A56 for ; Mon, 28 May 2018 02:29:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDA51777B2; Mon, 28 May 2018 02:28:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id v13-v6so6048783wrp.13; Sun, 27 May 2018 19:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uWEYYFqYGwatt1zvvcL4alIV8I+a8GEGn+dPYIdcvIs=; b=pGWLQnt3GSKn6QoBTxPvV6Gr7RlERexkNw1llaAE1igf1dLKaq/7MfMs0ELjO5ikF6 wyJaHKcbn5Nu1Mt6fhZ5Oeyel2Rzt8H1DOU8yEsz0HYkeHJPiIL5ppPpkpOYUk7pXnLW GD5A6Kxmok2NYltUxxOq/zFvVg3ihGunTqU8dWqtV0KLfoDsSg5GdYcLvyJz6Tp7NxaJ j4Yhln2tEziYmB+JQwqwv6FQ29GLWVVqbiUXCtHNoQ+BpayI2ICUlCY5gLthcTXzwjvZ 5zYmj2UyRAHlq/yvShKb0EVMlhKW2817fmrwrU+TTpo9hzNqDRKXQCskfFgerJ2B8MCD ll8g== 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; bh=uWEYYFqYGwatt1zvvcL4alIV8I+a8GEGn+dPYIdcvIs=; b=HsDnPpdzimes24/GZklnRGmji0W8MPtt892NKKeEj2Y9qeZjv8+Foefjb0iMlt0I8O 8ZTiUj5cXW0RKHx/h0HPSisitgVH3VI0l2Tr4/w5zhcRsXH7k2YN3qpAUwRrwVIT36LY AEDnPvgkh94oxK+DxKSxeuVFdQWCerw5SWidg0zztgqxCKcAEL+BA/NYo60AniFsofwh nRRqkmqO9eHI+v6T5O+VeMjCg5rIe94lyyeIJBeRoCQqCtYO5euODjcenH6yFAMFqiEA ounbkWEo/8qt1VfBvrOgNBx/zxPm9GoRgu6OSPwQ+z5bradrrLWtI3gE/qF67YEIaBcV O6eA== X-Gm-Message-State: ALKqPwdAsUuZSFvO5uPMCK2t1HmAWf3vS27gn4hu/5H2DRhSLAu6d2xT J79riE+XiXT489yjqds1aEyYvV9XxBG1BpYVI4kvSA== X-Google-Smtp-Source: ADUXVKL9tWw2s2GC/0STt+bDWDhj2xYBWIW4rAhnxYeJbDdG9E44o8cToLhf0UzxRuQraVxZvIlFKODYTQBgWXYPCAs= X-Received: by 2002:adf:ac69:: with SMTP id v96-v6mr3976034wrc.5.1527474537372; Sun, 27 May 2018 19:28:57 -0700 (PDT) MIME-Version: 1.0 References: <6686653.ooTk0CQ0bF@ralph.baldwin.cx> <20180527195553.GA48909@ymer.vnode.se> In-Reply-To: <20180527195553.GA48909@ymer.vnode.se> From: Adrian Chadd Date: Sun, 27 May 2018 19:28:44 -0700 Message-ID: Subject: Re: RFC: Create a default wlan for wireless NICs To: John Baldwin , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 02:29:01 -0000 Lol. :-) The main change here is people having to unlearn wlanX being the device and things are now named dependent on your hardware type. I mean, ok ok it could just be like freebsd-4 or whatever, pre-vap support. :-) (do it!) -adrian From owner-freebsd-arch@freebsd.org Mon May 28 03:08:39 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8E76EF5DF6 for ; Mon, 28 May 2018 03:08:39 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 421F778BAE for ; Mon, 28 May 2018 03:08:39 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 055ACEF5DF5; Mon, 28 May 2018 03:08:39 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4C28EF5DF4 for ; Mon, 28 May 2018 03:08:38 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 676B478BAC; Mon, 28 May 2018 03:08:38 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-io0-x229.google.com with SMTP id e15-v6so4173976iog.1; Sun, 27 May 2018 20:08:38 -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=xbplxLLVm4vpF3zVAOIUjuaAaTeVXmLJSjpI00OYDow=; b=mXtkGFR50ORqVV5c+iP1zJmXWRVdJur90ayKXNCgBIftp1z+6bmp+0LYGAEkP+MCQC Lp6UkRcWSlelVaIORz0UIGvNocfZjyFyXw/LyAQ+299bvFK1jsIzyZlus0TTKMWGWLMe vAQiYdBySeQLh+9FLXhejZ5z1rFGZ26ILZiU4kfRST5pP+Ozpt0UlzFUA3gV5JMYUxEe 0zg6nTuvKxpNmqSUfJmdd8Ka2mMeaRGPgNo+If9HD0AJaIMRybCmVrTN0rwo5BmDJAZr it1eZVl6q31tbAK6jfIeMnSiypj5Xc65+9nAOng2PbXdYZ1IUKX/jmyj9IE8agl58YsJ XM3Q== 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=xbplxLLVm4vpF3zVAOIUjuaAaTeVXmLJSjpI00OYDow=; b=H8FltOwSHc2NXCUu9xIRTu80CNAgBds3GAHu/h4AiVX8MgBH+NqDx3jExsoFwlJL3N 2TBLHREC98bIKygxa9CyFAmLvuVWKjemuIRLt5UaOA+wwRDlnnGTNXIcN6jSqHHlJEMv l2hfgLZNgrKrmDAnO6nhr6x/RywBQySJPzjWTNU12ZyeL4btNKKwG5kcVEkQbs4TRCNg S7Zkmnwx6rCrOI8hU7evJqkMVKqpITh6Px2x+TmFwdKqyYuLplcvL9FMJyvdJCgtLez5 1ncBPxI/NYmxoUXGTqLpVwB2v3a0uxedFNSeNdfOHadRVuh8qhQiLjwqWLMD99pzZKDb 4ckg== X-Gm-Message-State: ALKqPwdpZbMO5p+2v8M2KEUAsvNrAXxFFKp2BhxQcpr9OuoLrfvfnyRN KfqsdEhP6YopX+55GEQNC83ra3Ub8226XssUO8M= X-Google-Smtp-Source: ADUXVKICNRkLSfDmlO00Bmi8TpUSJ3DW+prOlmjFJNz70pGemscBeSrONLYH0mmPLNh3IaEKl8Cporx3Zk/R4z33VMc= X-Received: by 2002:a6b:a348:: with SMTP id m69-v6mr9210483ioe.26.1527476917650; Sun, 27 May 2018 20:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8d5c:0:0:0:0:0 with HTTP; Sun, 27 May 2018 20:08:37 -0700 (PDT) In-Reply-To: References: <6686653.ooTk0CQ0bF@ralph.baldwin.cx> <20180527195553.GA48909@ymer.vnode.se> From: Adam Date: Sun, 27 May 2018 22:08:37 -0500 Message-ID: Subject: Re: RFC: Create a default wlan for wireless NICs To: Adrian Chadd Cc: John Baldwin , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 03:08:39 -0000 On Sun, May 27, 2018 at 9:28 PM, Adrian Chadd wrote: > Lol. :-) > > The main change here is people having to unlearn wlanX being the device and > things are now named dependent on your hardware type. > > I mean, ok ok it could just be like freebsd-4 or whatever, pre-vap support. > :-) > > (do it!) > > > -adrian > I like this change. Having my network device reflect the driver name is useful and makes it more consistent. -- Adam From owner-freebsd-arch@freebsd.org Mon May 28 18:08:05 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0044DF74D9F for ; Mon, 28 May 2018 18:08:04 +0000 (UTC) (envelope-from rpokala@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 922EC79DD1 for ; Mon, 28 May 2018 18:08:04 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4DDB9F74D9D; Mon, 28 May 2018 18:08:04 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BC08F74D9C for ; Mon, 28 May 2018 18:08:04 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5CF379DCF; Mon, 28 May 2018 18:08:03 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [192.168.1.4] (c-73-241-240-124.hsd1.ca.comcast.net [73.241.240.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 66BB316D4F; Mon, 28 May 2018 18:08:03 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 28 May 2018 11:07:59 -0700 Subject: Re: To assert() or not to assert(), that is not really a question... From: Ravi Pokala To: Poul-Henning Kamp , Message-ID: <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com> Thread-Topic: To assert() or not to assert(), that is not really a question... References: <4514.1527319154@critter.freebsd.dk> In-Reply-To: <4514.1527319154@critter.freebsd.dk> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 18:08:05 -0000 -----Original Message----- From: on behalf of Poul-Henning Kamp Date: 2018-05-26, Saturday at 00:19 To: Subject: To assert() or not to assert(), that is not really a question... > ... > > 1. "Regular asserts" - things which are just plain wrong, which > probably means we have a genuine bug somewhere. Examples could > be null pointers where previous checks should have ensured this > not be so. Also error situations for which there is no saner > handling that killing the projcess. > > ... > > 3. "wrong asserts" - Internal state is messed up, program flow > has taken a "impossible" branch. A good example is the > default branch of a switch on a finite input set. Hi Poul-Henning, I am in strong overall agreement with your argument. I am however confused as to how (1) and (3) are different; they're both irrevocably bad internal state. Thanks, Ravi (rpokala@) From owner-freebsd-arch@freebsd.org Mon May 28 18:24:11 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D399F7594F for ; Mon, 28 May 2018 18:24:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) 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 CE3807A5BF for ; Mon, 28 May 2018 18:24:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 89D67F7594E; Mon, 28 May 2018 18:24:10 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 776B2F7594D for ; Mon, 28 May 2018 18:24:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5577A5BD; Mon, 28 May 2018 18:24:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 07BB514888; Mon, 28 May 2018 18:24:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w4SIO7Wp022471 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 May 2018 18:24:07 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w4SIO6af022470; Mon, 28 May 2018 18:24:06 GMT (envelope-from phk) To: Ravi Pokala cc: arch@freebsd.org Subject: Re: To assert() or not to assert(), that is not really a question... In-reply-to: <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com> From: "Poul-Henning Kamp" References: <4514.1527319154@critter.freebsd.dk> <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22468.1527531846.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 28 May 2018 18:24:06 +0000 Message-ID: <22469.1527531846@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 18:24:11 -0000 -------- In message <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com>, Ravi Pokala= writ es: >> 1. "Regular asserts" - things which are just plain wrong, which >> probably means we have a genuine bug somewhere. Examples could >> be null pointers where previous checks should have ensured this >> not be so. Also error situations for which there is no saner >> handling that killing the projcess. >> = >> ... >> = >> 3. "wrong asserts" - Internal state is messed up, program flow >> has taken a "impossible" branch. A good example is the >> default branch of a switch on a finite input set. > >Hi Poul-Henning, > >I am in strong overall agreement with your argument. I am however >confused as to how (1) and (3) are different; they're both irrevocably >bad internal state. The regular assert is assert() as we know and love it, and if it triggers it reports the C-source of the failing condition. The WRONG macro always triggers, and reports its string argument. Here is a random snippet of varnish code showing both: /* Per specification */ assert(sizeof vpx1_sig =3D=3D 5); assert(sizeof vpx2_sig =3D=3D 12); [...] p =3D req->htc->rxbuf_b; if (p[0] =3D=3D vpx1_sig[0]) i =3D vpx_proto1(wrk, req); else if (p[0] =3D=3D vpx2_sig[0]) i =3D vpx_proto2(wrk, req); else WRONG("proxy sig mismatch"); Poul-Henning PS: You can explore the Varnish source code here: https://github.com/varnishcache/varnish-cache Asserts defined in: .../include/vas.h Custom backtrace/state dump in: .../bin/varnishd/cache/cache_panic.c Code coverage results: http://varnish-cache.org/gcov/ You may also find the void-pointer paranoia interesting: .../include/miniobj.h -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Mon May 28 18:49:53 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D37AFF7723E for ; Mon, 28 May 2018 18:49:52 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 686787B5D5 for ; Mon, 28 May 2018 18:49:51 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-245-183.albq.qwest.net [67.0.245.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 264F4192888 for ; Mon, 28 May 2018 11:00:07 +0000 (UTC) To: freebsd-arch From: Sean Bruno Subject: How to update or should we update Kerberos Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: Date: Mon, 28 May 2018 12:49:41 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dOAImFo6Jeu3qVkSTrJ0u3YlzIohATRsl" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 18:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dOAImFo6Jeu3qVkSTrJ0u3YlzIohATRsl Content-Type: multipart/mixed; boundary="1goeFdhORpuVUgCxita4IOVYQXcUi4gIf"; protected-headers="v1" From: Sean Bruno To: freebsd-arch Message-ID: Subject: How to update or should we update Kerberos --1goeFdhORpuVUgCxita4IOVYQXcUi4gIf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable https://github.com/heimdal/heimdal/releases Since we haven't updated Kerberos for 6 years, I'm curious why we even have it floating around in base. I'm ignorant as to what we need it for. sean --1goeFdhORpuVUgCxita4IOVYQXcUi4gIf-- --dOAImFo6Jeu3qVkSTrJ0u3YlzIohATRsl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlsMT0VfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LYxIAgArrdwMe6gShfkQVHKhVW9/Luvy4Ofkm03fz+Kmuj4HABPXrKXVgjirt2n giCmTWyygC6IEdT900dzpBYmAwkiVeIu5JutZZvfJx8c5dckc/tQCUTY3xWFXnF/ FClJbUEO2ZUa2jsLVNVGFV9vhapZkWbO5aNBUNJRho7simVhZLMPcLuZ7HKMI/Yi TX/KWpRsU18EAwAgT4VrzCsbPw+BxZ6kWF1/sYz05P8SinwUTj81Sl/Fy/QHatQ/ XeWSTmn65Hi0yqBYKp6SOk571XmgvPuXinnYWVF2wegHjglrecSxBAVViKezo4qK k3qKINp+plraJt/9+od3ssMu97dyuw== =QEef -----END PGP SIGNATURE----- --dOAImFo6Jeu3qVkSTrJ0u3YlzIohATRsl-- From owner-freebsd-arch@freebsd.org Mon May 28 20:07:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B2DFF7F616 for ; Mon, 28 May 2018 20:07:40 +0000 (UTC) (envelope-from rpokala@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 014408133F for ; Mon, 28 May 2018 20:07:40 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B4758F7F611; Mon, 28 May 2018 20:07:39 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2203F7F610 for ; Mon, 28 May 2018 20:07:39 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56CFA8133C; Mon, 28 May 2018 20:07:39 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [192.168.1.4] (c-73-241-240-124.hsd1.ca.comcast.net [73.241.240.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id BCDF717947; Mon, 28 May 2018 20:07:38 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 28 May 2018 13:07:35 -0700 Subject: Re: To assert() or not to assert(), that is not really a question... From: Ravi Pokala To: Poul-Henning Kamp CC: Message-ID: <40636EBA-9D41-4F3E-8D10-3654E92FC6AA@panasas.com> Thread-Topic: To assert() or not to assert(), that is not really a question... References: <4514.1527319154@critter.freebsd.dk> <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com> <22469.1527531846@critter.freebsd.dk> In-Reply-To: <22469.1527531846@critter.freebsd.dk> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 20:07:40 -0000 Interesting stuff. Thanks, phk! -Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: Poul-Henning Kamp Date: 2018-05-28, Monday at 11:24 To: Ravi Pokala Cc: Subject: Re: To assert() or not to assert(), that is not really a question.= .. -------- In message <4427091E-3B0E-4C34-B4C6-3557DD7B55E4@panasas.com>, Ravi Pokala = writ es: >> 1. "Regular asserts" - things which are just plain wrong, which >> probably means we have a genuine bug somewhere. Examples could >> be null pointers where previous checks should have ensured this >> not be so. Also error situations for which there is no saner >> handling that killing the projcess. >>=20 >> ... >>=20 >> 3. "wrong asserts" - Internal state is messed up, program flow >> has taken a "impossible" branch. A good example is the >> default branch of a switch on a finite input set. > >Hi Poul-Henning, > >I am in strong overall agreement with your argument. I am however >confused as to how (1) and (3) are different; they're both irrevocably >bad internal state. The regular assert is assert() as we know and love it, and if it triggers it reports the C-source of the failing condition. The WRONG macro always triggers, and reports its string argument. Here is a random snippet of varnish code showing both: /* Per specification */ assert(sizeof vpx1_sig =3D=3D 5); assert(sizeof vpx2_sig =3D=3D 12); [...] p =3D req->htc->rxbuf_b; if (p[0] =3D=3D vpx1_sig[0]) i =3D vpx_proto1(wrk, req); else if (p[0] =3D=3D vpx2_sig[0]) i =3D vpx_proto2(wrk, req); else WRONG("proxy sig mismatch"); Poul-Henning PS: You can explore the Varnish source code here: https://github.com/varnishcache/varnish-cache Asserts defined in: .../include/vas.h Custom backtrace/state dump in: .../bin/varnishd/cache/cache_panic.c Code coverage results: http://varnish-cache.org/gcov/ You may also find the void-pointer paranoia interesting: .../include/miniobj.h --=20 Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe =20 Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Tue May 29 00:36:12 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA73CF70DAF for ; Tue, 29 May 2018 00:36:12 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 4DAAA6C550; Tue, 29 May 2018 00:36:12 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-61fff7000000405f-16-5b0c9f46a1cb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.81.16479.64F9C0B5; Mon, 28 May 2018 20:31:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4T0V0QC012363; Mon, 28 May 2018 20:31:01 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4T0UvMX021327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 May 2018 20:30:59 -0400 Date: Mon, 28 May 2018 19:30:57 -0500 From: Benjamin Kaduk To: Sean Bruno Cc: freebsd-arch Subject: Re: How to update or should we update Kerberos Message-ID: <20180529003057.GB65175@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrOs2nyfa4M0dI4vZ06cxWfT0nmB0 YPKY8Wk+SwBjFJdNSmpOZllqkb5dAlfGo8XPGAu2CVTc2rmZrYFxEl8XIyeHhICJxJdVi9m6 GLk4hAQWM0ncenaJBcLZyCgx//ACdgjnKpPEmquL2UFaWARUJS487WYBsdkEVCQaui8zg9gi AsoS2zu6GUFsZgFtiXunWthAbGEBc4nGOcfAbF6gdQtPrQfrFRKwkzh97xMrRFxQ4uTMJywQ vWUSjQ8eA9kcQLa0xPJ/HCBhTgF7iZblF8BKRIFW7e07xD6BUWAWku5ZSLpnIXRDhLUkbvx7 yYQhrC2xbOFrZgjbVmLduvcsCxjZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6uVmluilppRu YgSHviTPDsYzb7wOMQpwMCrx8DIw8UQLsSaWFVfmHmKU5GBSEuU9zwMU4kvKT6nMSCzOiC8q zUktPsSoArTr0YbVFxilWPLy81KVRHi5dLmihXhTEiurUovyYcqkOViUxHmzFzFGCwmkJ5ak ZqemFqQWwWRlODiUJHgr5wEtECxKTU+tSMvMKUFIM3FwHmKU4OABGt4PUsNbXJCYW5yZDpE/ xagoJc6rC5IQAElklObB9YJSlkT2/ppXjOJAbwlDtPMA0x1c9yugwUxAg59M5AYZXJKIkJJq YBTXZXBt5K+w7pHmvKGjahrnt//FtKkx1V5BnH+Lwupl/lx5cvL93tW9tnMVviwTKlCKer1w zqfZD912/v9dknB0bw4jr6BR1t32y2rO2xRe7+V1PJMvJb9r6b7HnU+fRKvn5HjVa906sefb 2x154txc3UHMWUV5GvsvMIic2TS7SU50thXXeiWW4oxEQy3mouJEAOpFNtA0AwAA X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 00:36:13 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 28, 2018 at 12:49:41PM -0600, Sean Bruno wrote: > https://github.com/heimdal/heimdal/releases >=20 > Since we haven't updated Kerberos for 6 years, I'm curious why we even cy has some WIP in projects/krb5, which at least initially was to switch to MIT krb5 in base (but now may be more ambitious and leave both Heimdal and MIT options). > have it floating around in base. >=20 > I'm ignorant as to what we need it for. It's a great way to simplify the bootstrap process when setting up new machines (in an existing realm environment), in particular, it is used in the FreeBSD cluster. Prior to pkgng's introduction of signed packages, it was the only way for me to securely integrate a new install that did not involve hand-transcribing key material or putting it on removable media. I think the signed-packages situation helps somewhat, but there are definitely still cases where it's useful to have. On the other hand, it's also sometimes frustrating when it's 6-year-old code and I also want to be in an MIT krb5 environment. But I hope that cy will continue with the project branch and we'll get an update "soon". -Ben --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlsMnzYACgkQKNmm82Tr dRITqwwgjD6UspRytOlHGOKWn0QTysW/YgnJQ6jvZi4lVfKmmG95QqmgtZI/A5g8 WcKwkBNGlTWGD9i+QXPmvnKLjkwIB1tUey/3CYP2GVRuiFqiI0aJBirSoMvAZEUO IIo0mAVMT6MzY8szuKWnuh6pU+2c0oUKqASy3TZ28manwOSU0b6Ylh5YXJslbSpV EeMGa2VApFfVk1E/E3Lro7RytFziMMLX7oy4PscelP6Tj+YxrOoQ1QlGvea2XGHQ 99bEKm04Ilmu4WAmvexKdVpdJ5CGTNpZD9TqAerTmDSGY7IH+vMFQyrzc8oWIIuS U/x07Ghnjjq/AERt2hWNPDd1Wn25sVvluCMssdkg6qrFN7ZFBbc02b5wgNGVFRnk ufPOlZoT04bwrjng6bAwXmTw0jZb660pK90EUwNahp1ubiiGxn522Wgu9KX9ti7y dWSpGedBSVCBEH84JVU6bk7yquGuJw7xh8fMNuSFCHSwwXOr3vs2B9RIjVsXFvLQ MYq/DLcxWYG1dQ== =3nZb -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-arch@freebsd.org Tue May 29 02:34:41 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF570F7A19C for ; Tue, 29 May 2018 02:34:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A24871524; Tue, 29 May 2018 02:34:40 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id NUT6fn3yEuYopNUT8f1z3P; Mon, 28 May 2018 20:34:39 -0600 X-Authority-Analysis: v=2.3 cv=GopsBH9C c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=VUJBJC2UJ8kA:10 a=Nk2HUJP5AAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=tIwHfEbsL6Y0Z_M3gIcA:9 a=CjuIK1q_8ugA:10 a=q5ElMP0IXWY55gIGnw_N:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 464F41C82; Mon, 28 May 2018 19:34:36 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w4T2YaUd003994; Mon, 28 May 2018 19:34:36 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w4T2YZH9003991; Mon, 28 May 2018 19:34:35 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201805290234.w4T2YZH9003991@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Benjamin Kaduk cc: Sean Bruno , freebsd-arch Subject: Re: How to update or should we update Kerberos In-Reply-To: Message from Benjamin Kaduk of "Mon, 28 May 2018 19:30:57 -0500." <20180529003057.GB65175@kduck.kaduk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 May 2018 19:34:35 -0700 X-CMAE-Envelope: MS4wfCLPQtFALtAM/vrO/herrrov1f+g+hgyM5VGo9vxBwvtw2SrFfGotoeW3irz6H7dmyiYsRpDwSYJLOOS9gcy8mSrA1YbZnI3V3Psp9No6sVTNN89lKri 5sONMgdm5ijcvAreimSyipAt6bwX2w9jOYLKZfhNhR/CLkOWd/atsE6ZiKAhMUj2FpsS6HA7Mro441d+IQBM76eEQ+SCCouCEsLHmZRFIfZGxCgx6U32/MGW X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 02:34:41 -0000 In message <20180529003057.GB65175@kduck.kaduk.org>, Benjamin Kaduk writes: > > --jI8keyz6grp/JLjh > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, May 28, 2018 at 12:49:41PM -0600, Sean Bruno wrote: > > https://github.com/heimdal/heimdal/releases > >=20 > > Since we haven't updated Kerberos for 6 years, I'm curious why we even > > cy has some WIP in projects/krb5, which at least initially was to > switch to MIT krb5 in base (but now may be more ambitious and leave > both Heimdal and MIT options). Yes. The first phase, to make kerberos in base private, has been committed to my project branch. It broke over 800 ports. I'm working on cobbling a ports patch. A private kerberos in base cleans up a lot of nasty issues in ports. The next bit is messy. Originally my plan was to replace Heimdal with MIT however one of our cluster admins objected. Though both Heimdal and MIT use the same protocol, the kadmin protocol is incompatible. This is a bit of a POLA violation. IMO FreeBSD should ship with Kerberos client commands and private libraries and allow the user to select one of the ports for their KDC. A packaged base would make this a little more politically feasible. With this in mind, the only viable option that would be acceptable to everyone is a knob to allow building of one or another in base. In other words Heimdal in base should probably also be updated. > > > have it floating around in base. > >=20 > > I'm ignorant as to what we need it for. > > It's a great way to simplify the bootstrap process when setting up > new machines (in an existing realm environment), in particular, it > is used in the FreeBSD cluster. Prior to pkgng's introduction of > signed packages, it was the only way for me to securely integrate a > new install that did not involve hand-transcribing key material or > putting it on removable media. I think the signed-packages > situation helps somewhat, but there are definitely still cases where > it's useful to have. When I was at $JOB-1, our script created a keytab and pushed keys through an ssh session from each admin's Linux, FreeBSD, or Solaris desktop. IMO, in today's environment, I'd be inclined to create a site-wide meta-port with all required FreeBSD ports for the site as prereqs and a port that configured kerberos. I know one person who does this using site-wide Linux RPMs at a Linux shop. When the site-wide config changes he updates his meta-ports and does yum update. This might be something we might want to document in a howto doc for pkgng. > > On the other hand, it's also sometimes frustrating when it's > 6-year-old code and I also want to be in an MIT krb5 environment. > But I hope that cy will continue with the project branch and we'll > get an update "soon". I'm working through all 800 broken ports. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Tue May 29 12:47:36 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A717F79E9F for ; Tue, 29 May 2018 12:47:36 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA02685A5 for ; Tue, 29 May 2018 12:47:35 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-245-183.albq.qwest.net [67.0.245.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id D9C44192888; Tue, 29 May 2018 04:58:24 +0000 (UTC) Subject: Re: How to update or should we update Kerberos To: Cy Schubert , Benjamin Kaduk Cc: freebsd-arch References: <201805290234.w4T2YZH9003991@slippy.cwsent.com> From: Sean Bruno Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: <8e9fa53a-7455-d408-501e-461f40d44a3a@freebsd.org> Date: Tue, 29 May 2018 06:47:29 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201805290234.w4T2YZH9003991@slippy.cwsent.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EWqNamxbhDQJPIG44vP96AI3BHNXduvJN" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 12:47:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EWqNamxbhDQJPIG44vP96AI3BHNXduvJN Content-Type: multipart/mixed; boundary="tjmh1yFeQjzYZVaGKGZ6hEex0egVqScR4"; protected-headers="v1" From: Sean Bruno To: Cy Schubert , Benjamin Kaduk Cc: freebsd-arch Message-ID: <8e9fa53a-7455-d408-501e-461f40d44a3a@freebsd.org> Subject: Re: How to update or should we update Kerberos References: <201805290234.w4T2YZH9003991@slippy.cwsent.com> In-Reply-To: <201805290234.w4T2YZH9003991@slippy.cwsent.com> --tjmh1yFeQjzYZVaGKGZ6hEex0egVqScR4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/28/18 20:34, Cy Schubert wrote: >>> I'm ignorant as to what we need it for. >> It's a great way to simplify the bootstrap process when setting up >> new machines (in an existing realm environment), in particular, it >> is used in the FreeBSD cluster. Prior to pkgng's introduction of >> signed packages, it was the only way for me to securely integrate a >> new install that did not involve hand-transcribing key material or >> putting it on removable media. I think the signed-packages >> situation helps somewhat, but there are definitely still cases where >> it's useful to have. > When I was at $JOB-1, our script created a keytab and pushed keys=20 > through an ssh session from each admin's Linux, FreeBSD, or Solaris=20 > desktop. Heh, yeah, I asked this question *wrong*. I know how we use it in the cluster. :-) I mean to ask, "why aren't we using ports for kerberos?" What purpose does it serve in the base system? sean --tjmh1yFeQjzYZVaGKGZ6hEex0egVqScR4-- --EWqNamxbhDQJPIG44vP96AI3BHNXduvJN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlsNS+FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LZcMwf/QiTFInG5TNw+SG9et1qYphCkCnSnF0j+HkjwiPyIbWuETzI0v9wMR5sM 4El+Pevq2xNDqOkxUoyLxi4CW2/nXI+BshOSTk2e4Tlg52NYqk6LQdsXOEDbe1xN OwvTjzZYRE1+gmzyXb6kkvBMDcCMYhtK6WHpskDHj60tGFGgUGElylQ72DjuwWR9 /T0o2/AheEJm3SecXnqcxE84P2QEtnJv4J63qYErrnIHhWvbtPH1VWvsHcShWt62 IPNpHGQ78WPZbTxzggV0M1dl+UAmcLIaTUVdfNkS/U2wYhdIIw755eaXWRDqaV/s 9hHIt+S4/2VL8a4p7/ld1fox3L7Hxg== =9X8K -----END PGP SIGNATURE----- --EWqNamxbhDQJPIG44vP96AI3BHNXduvJN-- From owner-freebsd-arch@freebsd.org Tue May 29 12:58:56 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 599F3F7AB8C for ; Tue, 29 May 2018 12:58:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660072.outbound.protection.outlook.com [40.107.66.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D035068E8B; Tue, 29 May 2018 12:58:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM (52.132.44.24) by YTOPR0101MB0876.CANPRD01.PROD.OUTLOOK.COM (52.132.50.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.797.11; Tue, 29 May 2018 12:58:53 +0000 Received: from YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::3108:2182:5a42:5f4]) by YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM ([fe80::3108:2182:5a42:5f4%13]) with mapi id 15.20.0797.017; Tue, 29 May 2018 12:58:53 +0000 From: Rick Macklem To: Sean Bruno , Cy Schubert , Benjamin Kaduk CC: freebsd-arch Subject: Re: How to update or should we update Kerberos Thread-Topic: How to update or should we update Kerberos Thread-Index: AQHT9vWfrLN1Ao0bcEmrsam5xc+PSqRGqHyAgAABQKI= Date: Tue, 29 May 2018 12:58:53 +0000 Message-ID: References: <201805290234.w4T2YZH9003991@slippy.cwsent.com>, <8e9fa53a-7455-d408-501e-461f40d44a3a@freebsd.org> In-Reply-To: <8e9fa53a-7455-d408-501e-461f40d44a3a@freebsd.org> 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=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB0876; 7:yR/36CtAWZKRSoTRXX83i+StqJUjHhEX5xA3VSZWWefHsUS7ipr98BO9NBy+7fO1w68/x5fg4DJI6xmaXp/Jjz82igZ0Pg75pSP+VTqBNVvfK6qoj7/wteMLen6B+loys+jnrm4gA3ICgDsY/7S15GAxo5FQBFb4xXYWZcVHgIJWDFEgk4lv4hpb9Fqq4oZopWxv7Ajjin3k7xf9uCkluJIDWqEXSfb6wdIFF4hpzYIbrLurzuh8HBUcXaECNWK2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB0876; x-ms-traffictypediagnostic: YTOPR0101MB0876: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB0876; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB0876; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39380400002)(39860400002)(346002)(376002)(199004)(189003)(2171002)(486006)(305945005)(106356001)(110136005)(446003)(74316002)(6246003)(25786009)(4326008)(81166006)(8936002)(105586002)(316002)(786003)(229853002)(11346002)(86362001)(97736004)(81156014)(5250100002)(2900100001)(476003)(186003)(102836004)(2906002)(9686003)(59450400001)(6436002)(14454004)(26005)(76176011)(33656002)(7696005)(3280700002)(53936002)(99286004)(6506007)(478600001)(15650500001)(8676002)(5660300001)(68736007)(3660700001)(74482002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB0876; H:YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: HvSFzK7q/c8Lz6SUAgsb4b3Rdk6Eu7YAPVeXBxG0qmgbfQJJgrIALsp7WLqKGTIgUm4PV7kcvZMsoIVhakv0Wmb6OMwY8iDErTH7cLQ7aK6Rno2i0opdIeDEt1yNxTb2uy9744doDuSf8LLxMrNEuudP3YRL1zOZ1q4MM0u3OAgdrtO9MBfnjfe7OUXRnkV/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5302d287-45d4-4c9d-03a7-08d5c563ee34 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 5302d287-45d4-4c9d-03a7-08d5c563ee34 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 12:58:53.0832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0876 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 12:58:56 -0000 Sean Bruno wrote: [stuff snipped] >Heh, yeah, I asked this question *wrong*. I know how we use it in the >cluster. :-) > >I mean to ask, "why aren't we using ports for kerberos?" What purpose >does it serve in the base system? Although I have no idea how many use it, both the NFS client and server can= do Kerberized mounts. I haven't tried, but it probably needs some bits to buil= d it and if you move it to ports, there would be duplicates (and the opportunity= to have one change without the other introducing a hard to find bug). Also, I'd argue that security technology like this is pretty "core". I am mainly referring to the libraries and client side stuff and not the KD= C. rick From owner-freebsd-arch@freebsd.org Tue May 29 13:04:33 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC9BEF7B1FE for ; Tue, 29 May 2018 13:04:33 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A89D6952A; Tue, 29 May 2018 13:04:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id NeIZfrbHLSzNNNeIbfEMgT; Tue, 29 May 2018 07:04:25 -0600 X-Authority-Analysis: v=2.3 cv=KuxjJ1eN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=VUJBJC2UJ8kA:10 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=w8qqzX4uBYbWuJsBrMMA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id BDEA8742; Tue, 29 May 2018 06:04:23 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w4TD4N8J059916; Tue, 29 May 2018 06:04:23 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w4TD4NAr059913; Tue, 29 May 2018 06:04:23 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201805291304.w4TD4NAr059913@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Sean Bruno , Cy Schubert , Benjamin Kaduk , freebsd-arch Subject: Re: How to update or should we update Kerberos In-Reply-To: Message from Rick Macklem of "Tue, 29 May 2018 12:58:53 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 May 2018 06:04:23 -0700 X-CMAE-Envelope: MS4wfG17W6cTgCRslf0tC4DLXqSOpiXJJRu1Lw7f/Iy1H7DmM8dIrmAfBkJqBKvKsLa09BsgzttsIQb8uJYQWdo4adSydmKrGNOYuR2pliNDyGad8buSJnVn gpcMP9OvJKVeIBa6Y4Ad4CW0zGt9Zjo5bTSRKm112+Granr2Oh0ptS8lBoGYd6dMlIXbBZBIu7tg/H9SF+BrOGJGsTGpCrkS55ncxfdqccPyGfPTsUBV3m0o 1gW8v6hvjwX9oNt/QGN3KJdieng7hFwgiiC5HJQgl0E= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 13:04:34 -0000 In message , Rick Macklem writes: > Sean Bruno wrote: > [stuff snipped] > >Heh, yeah, I asked this question *wrong*. I know how we use it in the > >cluster. :-) > > > >I mean to ask, "why aren't we using ports for kerberos?" What purpose > >does it serve in the base system? > Although I have no idea how many use it, both the NFS client and server can d > o > Kerberized mounts. I haven't tried, but it probably needs some bits to build > it > and if you move it to ports, there would be duplicates (and the opportunity t > o > have one change without the other introducing a hard to find bug). > > Also, I'd argue that security technology like this is pretty "core". > > I am mainly referring to the libraries and client side stuff and not the KDC. IMO the base should only contain the libraries and client side. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Tue May 29 16:22:03 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EF96EF61D4 for ; Tue, 29 May 2018 16:22:03 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 961C87326E; Tue, 29 May 2018 16:22:02 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-525ff700000042e4-4b-5b0d7cf733e2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C4.F1.17124.7FC7D0B5; Tue, 29 May 2018 12:16:55 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w4TGGrsZ031300; Tue, 29 May 2018 12:16:54 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4TGGmNv001973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 May 2018 12:16:51 -0400 Date: Tue, 29 May 2018 11:16:48 -0500 From: Benjamin Kaduk To: Cy Schubert Cc: Rick Macklem , Sean Bruno , freebsd-arch Subject: Re: How to update or should we update Kerberos Message-ID: <20180529161645.GF27985@kduck.kaduk.org> References: <201805291304.w4TD4NAr059913@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201805291304.w4TD4NAr059913@slippy.cwsent.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrPu9hjfaYMoSWYue0zUWs6dPY7J4 uOwak0VP7wlGBxaPJyc/sXjM+DSfxeP35r1MAcxRXDYpqTmZZalF+nYJXBlfl7azFEwQqFhx sY+xgfEtTxcjJ4eEgIlEy/l9TF2MXBxCAouZJPb8WcQM4WxklDjd0QTlXGWSmDprLRNIC4uA qsTkow/ZQWw2ARWJhu7LzCC2iIC2xJXDHWA2s0CVxOr2qSwgtrCAuUTjnGNsIDYv0LpD196w QAxdzShx+eIfFoiEoMTJmU9YIJq1JG78ewm0jAPIlpZY/o8DJMwpYCNx5OknRhBbVEBZYm/f IfYJjAKzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjOAg luTdwfjvrtchRgEORiUe3o4o3mgh1sSy4srcQ4ySHExKorwWRUAhvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIryle3mihXhTEiurUovyYVLSHCxK4rzZixijhQTSE0tSs1NTC1KLYLIyHBxKErwM wGgVEixKTU+tSMvMKUFIM3FwggznARr+vxqohre4IDG3ODMdIn+KUVFKnJcPJCEAksgozYPr BSUZiez9Na8YxYFeEeZNAFnBA0xQcN2vgAYzAQ1+MpEbZHBJIkJKqoHx2gXXUIHSaYqq5z4r blzj1BXuZM5SfoHv2TqTuKmW7kpyu753Gmc9ZIu5+eZa1jffdZs36kSuem3+fTr/Ekufvec/ TX1365v5g2vzpT4enfnyl4StboP/TP6qpiirLzfNGiZKr1oUsCd10rrM/KftLewJHH/7Fu82 Yz+WM3UqU+a9fD2jGZ9OK7EUZyQaajEXFScCAErHdZMNAwAA X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 16:22:03 -0000 On Tue, May 29, 2018 at 06:04:23AM -0700, Cy Schubert wrote: > In message PRD01.P > ROD.OUTLOOK.COM>, Rick Macklem writes: > > Sean Bruno wrote: > > [stuff snipped] > > >Heh, yeah, I asked this question *wrong*. I know how we use it in the > > >cluster. :-) > > > > > >I mean to ask, "why aren't we using ports for kerberos?" What purpose > > >does it serve in the base system? > > Although I have no idea how many use it, both the NFS client and server can d > > o > > Kerberized mounts. I haven't tried, but it probably needs some bits to build > > it > > and if you move it to ports, there would be duplicates (and the opportunity t > > o > > have one change without the other introducing a hard to find bug). > > > > Also, I'd argue that security technology like this is pretty "core". > > > > I am mainly referring to the libraries and client side stuff and not the KDC. > > IMO the base should only contain the libraries and client side. I'm inclined to agree -- running a KDC with the implementation in the base system doesn't seem like a great plan to me. To expand the NFS use case a bit more, NFS uses the GSS-API to secure RPCs (only when security features are enabled, of course). The GSS-API normally operates only with message tokens that are opaque to the application layer, but for efficiency/speed we want to do the bulk data processing in the kernel. The traditional way to do this is to have an implementation-specific extension to the GSS-API that exposes a "lucid" (i.e., not opaque) structure with information about a security context and its key material, and shove that stuff into the kernel to use for per-message processing. Since this non-standard structure is implementation-specific, it's generally expected that the kernel code is kept in sync with the userspace code that does the actual security context negotiation/handshake and the key export. This basically requires having it in the base system, AFAICT. -Ben From owner-freebsd-arch@freebsd.org Tue May 29 20:43:26 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8DD7F74999 for ; Tue, 29 May 2018 20:43:26 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) (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 2E5347E203 for ; Tue, 29 May 2018 20:43:26 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf0-f169.google.com with SMTP id p14-v6so7839723pfh.9 for ; Tue, 29 May 2018 13:43:26 -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:from:date:message-id:subject:to; bh=1Lo7lwd8RoKAt76bzYJp75lRTnq65pK7IrFO/clGREc=; b=bEuBt1c4w7s4arDqxkvJ476JCOuRpagOC9u3ZLlsUvHzh7unX7fR4SxO+l6v0JkJDy odRpa8hSgFAMqGx/LIkbu+2NkE3S/KTdBzObdOJhvipbXS2EATbzkxjAC7+y4XjJVZZ4 DCtC6GY2Rw1xguceUTgB+dXszGcjPneBbdbU6YjMwffPJ0mneMCY/nlitcZlcwFlGxe1 rSHOeDDpoZMJYFhKVLn3pjgzReEUWjxbEci05jGAY5RGO1JM4AaoAiM/3k0iRUkC7e/r LXG5L5uSb8PV8Jd5E1mtS9pZgR3PPOLM5omZTPySm+h783Lq1iXPVXSNUtKZAHuuuK5Y yneA== X-Gm-Message-State: ALKqPweDYkekv/Um+zEq6PfP+WjuV0yVFyw30umPS5Hf5nKnG6AAgW4A Sp2q+apc7vYMPdTxLpXjczGhVKSV X-Google-Smtp-Source: AB8JxZq6S8q+Yfc6E8P/o39+HVV8rvEg7gj0223hm+hfbA2URs1oaZgBKL2v7AJJUoEkLg8C1EPFTA== X-Received: by 2002:aa7:83c7:: with SMTP id j7-v6mr18765168pfn.50.1527626598862; Tue, 29 May 2018 13:43:18 -0700 (PDT) Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com. [74.125.83.47]) by smtp.gmail.com with ESMTPSA id q24-v6sm212063pfh.26.2018.05.29.13.43.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 13:43:18 -0700 (PDT) Received: by mail-pg0-f47.google.com with SMTP id e21-v6so7096141pgv.0 for ; Tue, 29 May 2018 13:43:18 -0700 (PDT) X-Received: by 2002:a63:6e4f:: with SMTP id j76-v6mr248235pgc.16.1527626598262; Tue, 29 May 2018 13:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:c502:0:0:0:0 with HTTP; Tue, 29 May 2018 13:42:47 -0700 (PDT) From: Gleb Popov Date: Tue, 29 May 2018 23:42:47 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Rationale for setting COMMLEN to 19 in struct kinfo_proc To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:43:26 -0000 Hello. I've been debugging a failing Qt (KDE, to be precise) test and found that process name returned in kinfo_proc structure gets truncated to 19 symbols. This causes other errors in the application. I'm wondering why is this field so small and is there possibility to increase it? I think, having applications with names longer than 19 characters is not that rare. Relevant header: /usr/include/sys/user.h Simple testcase to feature the problem: # cat k.cpp #include #include #include #include #include #include #include #include int main() { auto pid = getpid(); struct kinfo_proc kp; int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; size_t len = sizeof(kp); u_int mib_len = sizeof(mib)/sizeof(u_int); if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) return -1; puts(kp.ki_tdname); puts(kp.ki_comm); return 0; } # c++ -o abcdefghijklmnopqrstuvwxyz # ./abcdefghijklmnopqrstuvwxyz abcdefghijklmnop abcdefghijklmnopqrs From owner-freebsd-arch@freebsd.org Wed May 30 00:16:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3172FFC37CA for ; Wed, 30 May 2018 00:16:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4A8585DDC; Wed, 30 May 2018 00:16:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6FEF75A9F12; Wed, 30 May 2018 00:16:38 +0000 (UTC) Date: Wed, 30 May 2018 00:16:38 +0000 From: Brooks Davis To: Gleb Popov Cc: freebsd-arch@freebsd.org Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc Message-ID: <20180530001638.GN99063@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vbzKE9fGfpHIBC6T" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 00:16:40 -0000 --vbzKE9fGfpHIBC6T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: > Hello. >=20 > I've been debugging a failing Qt (KDE, to be precise) test and found that > process name returned in kinfo_proc structure gets truncated to 19 symbol= s. > This causes other errors in the application. I'm wondering why is this > field so small and is there possibility to increase it? I think, having > applications with names longer than 19 characters is not that rare. >=20 > Relevant header: /usr/include/sys/user.h >=20 > Simple testcase to feature the problem: >=20 > # cat k.cpp > #include > #include > #include > #include >=20 > #include > #include > #include > #include >=20 > int main() > { > auto pid =3D getpid(); > struct kinfo_proc kp; > int mib[4] =3D { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; >=20 > size_t len =3D sizeof(kp); > u_int mib_len =3D sizeof(mib)/sizeof(u_int); >=20 > if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) > return -1; >=20 > puts(kp.ki_tdname); > puts(kp.ki_comm); >=20 > return 0; > } > # c++ -o abcdefghijklmnopqrstuvwxyz > # ./abcdefghijklmnopqrstuvwxyz > abcdefghijklmnop > abcdefghijklmnopqrs Changing the size of fields in kinfo_proc would be enormously disruptive. Take a look at all the source that uses KERN_PROC_PID for a subset of things that would break. Sometimes we can break these interfaces, but I think this one would require new sysctl mibs. If we did that we should come up with an interface that is identical between 32-bit and 32-bit systems and doesn't export pointers. -- Brooks --vbzKE9fGfpHIBC6T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbDe1lAAoJEKzQXbSebgfAvp0H/2e09ofL4ZQyHkzbnnskb54V Aghoi0n6oDRBXdxgq9Tza1rXXfq57wGj/Zperb0H9GO3BJzQW9Hbx8FPPWfO42vP WJJYc+IhJ3ikLE18+XprUdVOlOiNBbW57qx5dnQ6WtsVBBFBdxgKq3fe/3ocOKNQ 0lE61pfhx01pwj5KGNtVQOKRqUF4DwTbCj2+PLCPlguXQ1rlVHv62i/4W24JpG7F EDvoHJ6DZ/N/yePBPA1b1P/VVbDoWxIpti934cqZhGpZd+jF1fDK9AfbGUNA2Adq 72pWZhirWL1nnFEkZVvNoKIYVEMaY+WPJ6nTCb5VWDQfm8lmf+qFhKcUjrGN5Y0= =s08Z -----END PGP SIGNATURE----- --vbzKE9fGfpHIBC6T-- From owner-freebsd-arch@freebsd.org Wed May 30 02:10:52 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05808EF3820 for ; Wed, 30 May 2018 02:10:52 +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 AC5FE69516 for ; Wed, 30 May 2018 02:10:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (96-86-69-187-static.hfc.comcastbusiness.net [96.86.69.187]) by mail.baldwin.cx (Postfix) with ESMTPSA id 89A7C10AFD4 for ; Tue, 29 May 2018 22:10:44 -0400 (EDT) Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc To: freebsd-arch@freebsd.org References: <20180530001638.GN99063@spindle.one-eyed-alien.net> From: John Baldwin Message-ID: <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> Date: Tue, 29 May 2018 22:10:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180530001638.GN99063@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 29 May 2018 22:10:44 -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.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 02:10:52 -0000 -- John Baldwin On 5/29/18 8:16 PM, Brooks Davis wrote: > On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: >> Hello. >> >> I've been debugging a failing Qt (KDE, to be precise) test and found that >> process name returned in kinfo_proc structure gets truncated to 19 symbols. >> This causes other errors in the application. I'm wondering why is this >> field so small and is there possibility to increase it? I think, having >> applications with names longer than 19 characters is not that rare. >> >> Relevant header: /usr/include/sys/user.h >> >> Simple testcase to feature the problem: >> >> # cat k.cpp >> #include >> #include >> #include >> #include >> >> #include >> #include >> #include >> #include >> >> int main() >> { >> auto pid = getpid(); >> struct kinfo_proc kp; >> int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; >> >> size_t len = sizeof(kp); >> u_int mib_len = sizeof(mib)/sizeof(u_int); >> >> if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) >> return -1; >> >> puts(kp.ki_tdname); >> puts(kp.ki_comm); >> >> return 0; >> } >> # c++ -o abcdefghijklmnopqrstuvwxyz >> # ./abcdefghijklmnopqrstuvwxyz >> abcdefghijklmnop >> abcdefghijklmnopqrs > > Changing the size of fields in kinfo_proc would be enormously > disruptive. Take a look at all the source that uses KERN_PROC_PID for a > subset of things that would break. > > Sometimes we can break these interfaces, but I think this one would > require new sysctl mibs. If we did that we should come up with an > interface that is identical between 32-bit and 32-bit systems and > doesn't export pointers. p_comm[] in struct proc is only 20 bytes long (19 chars + nul), so you can't make it bigger in kinfo_proc anyway as we only store 19 chars in the kernel. (Note that we do have room to grow char arrays if needed without having to completely rototill though; we use a hack to store the "rest" of the thread name in a separate array to export the full 19 chars of the thread name now.) If you want the raw command line you can't get that via kinfo_proc. You can use the kern.proc.args sysctl or wrapper functions like kvm_getargv() or procstat_getargv(). You can then use argv[0] as the command name instead. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Jun 1 11:45:12 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23E3BF760F5 for ; Fri, 1 Jun 2018 11:45:12 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) (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 C132C76EBF; Fri, 1 Jun 2018 11:45:11 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf0-f175.google.com with SMTP id a14-v6so12411060pfi.1; Fri, 01 Jun 2018 04:45:11 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OzQz9wY5up/XXu2ewtgKoiBxVVlZizfdY0rSPVmQq9Y=; b=YKsZjXVy8ON3ctx02qk0cFj32euH9Dk/BC74SHJkoWwPpCsQL+2h83qhpWxYnGyukb mUL1AlZwXf70tGfiacllrjf/oznB4GjYvb73d4rmzjbyFOyAW21NtqNPB4OHso54pFay 3WqiBxbs9qc+SnOUL+wFaepIgKEp19JeO7p5COP32R8AzUlUI9GPDFf18rC1VUgkyF7y e7APTUYg8SIJUxYuQrZaGPzpWN006toqBfF41srcOyC7vNWDBrd3wMZcrnggp/9MN6+S 8A8/cTtzTd+aRFj9UtUdbKUVRp+N2ZvQsLOkC31KMbdedEmVzwmjM2QaSwGztrqfe8XA SsNA== X-Gm-Message-State: ALKqPwfUmONpeT1jOCmv0wYxz7RBc61MtRzdF3KgOaSSG3JFHbHk1aTZ FMlVFVLZE+fklnirJu8STLdTsfeU X-Google-Smtp-Source: ADUXVKKS2FXM71dRZV4GpaXXIQFxe6ag+pZ+LyE84D9a6pm494MzgfUOicTpszWtjW7SR4nLqUbw5A== X-Received: by 2002:a63:7f51:: with SMTP id p17-v6mr8572092pgn.36.1527853505092; Fri, 01 Jun 2018 04:45:05 -0700 (PDT) Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com. [74.125.83.44]) by smtp.gmail.com with ESMTPSA id k80-v6sm38505756pfa.168.2018.06.01.04.45.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 04:45:05 -0700 (PDT) Received: by mail-pg0-f44.google.com with SMTP id p8-v6so11163744pgq.10; Fri, 01 Jun 2018 04:45:04 -0700 (PDT) X-Received: by 2002:a63:4003:: with SMTP id n3-v6mr8609305pga.184.1527853504874; Fri, 01 Jun 2018 04:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:c502:0:0:0:0 with HTTP; Fri, 1 Jun 2018 04:44:34 -0700 (PDT) In-Reply-To: <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> References: <20180530001638.GN99063@spindle.one-eyed-alien.net> <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> From: Gleb Popov Date: Fri, 1 Jun 2018 14:44:34 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc To: John Baldwin Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 11:45:12 -0000 On Wed, May 30, 2018 at 5:10 AM, John Baldwin wrote: > > -- > John Baldwin > On 5/29/18 8:16 PM, Brooks Davis wrote: > > On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: > >> Hello. > >> > >> I've been debugging a failing Qt (KDE, to be precise) test and found > that > >> process name returned in kinfo_proc structure gets truncated to 19 > symbols. > >> This causes other errors in the application. I'm wondering why is this > >> field so small and is there possibility to increase it? I think, having > >> applications with names longer than 19 characters is not that rare. > >> > >> Relevant header: /usr/include/sys/user.h > >> > >> Simple testcase to feature the problem: > >> > >> # cat k.cpp > >> #include > >> #include > >> #include > >> #include > >> > >> #include > >> #include > >> #include > >> #include > >> > >> int main() > >> { > >> auto pid = getpid(); > >> struct kinfo_proc kp; > >> int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; > >> > >> size_t len = sizeof(kp); > >> u_int mib_len = sizeof(mib)/sizeof(u_int); > >> > >> if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) > >> return -1; > >> > >> puts(kp.ki_tdname); > >> puts(kp.ki_comm); > >> > >> return 0; > >> } > >> # c++ -o abcdefghijklmnopqrstuvwxyz > >> # ./abcdefghijklmnopqrstuvwxyz > >> abcdefghijklmnop > >> abcdefghijklmnopqrs > > > > Changing the size of fields in kinfo_proc would be enormously > > disruptive. Take a look at all the source that uses KERN_PROC_PID for a > > subset of things that would break. > > > > Sometimes we can break these interfaces, but I think this one would > > require new sysctl mibs. If we did that we should come up with an > > interface that is identical between 32-bit and 32-bit systems and > > doesn't export pointers. > > p_comm[] in struct proc is only 20 bytes long (19 chars + nul), so you > can't make it bigger in kinfo_proc anyway as we only store 19 chars > in the kernel. (Note that we do have room to grow char arrays if > needed without having to completely rototill though; we use a hack to > store the "rest" of the thread name in a separate array to export the > full 19 chars of the thread name now.) > > If you want the raw command line you can't get that via kinfo_proc. > You can use the kern.proc.args sysctl or wrapper functions like > kvm_getargv() or procstat_getargv(). You can then use argv[0] as the > command name instead. > Thanks for your suggestion. I've tried that out and it does seem to work. However, I'm slightly confused by the fact that procstat_getargv() returns only command name and not the whole argv line, as function's name suggests. Here is my code: int main(int argc, char* argv[]) { kvm_t * kvm = kvm_open(nullptr, "/dev/null", nullptr, O_RDONLY, ""); int cnt; struct kinfo_proc * kp = kvm_getprocs(kvm, KERN_PROC_PID, getpid(), &cnt); struct procstat * ps = procstat_open_sysctl(); char ** argv0 = procstat_getargv(ps, kp, 0); puts(*argv0); procstat_close(ps); kvm_close(kvm); return 0; } Running "veryveryverylongcommandname" correctly produces "veryveryverylongcommandname" line on stdout, but "veryveryverylongcommandname args args args" also gives only "veryveryverylongcommandname". Is this correct behavior or am I missing something? > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Fri Jun 1 13:41:59 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 836B6FD4DD4 for ; Fri, 1 Jun 2018 13:41:59 +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 0B3C67C40B; Fri, 1 Jun 2018 13:41:58 +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 ESMTP id w51Dfl4d029181; Fri, 1 Jun 2018 16:41:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w51Dfl4d029181 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w51DflDO029180; Fri, 1 Jun 2018 16:41:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 1 Jun 2018 16:41:47 +0300 From: Konstantin Belousov To: Gleb Popov Cc: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc Message-ID: <20180601134147.GB3789@kib.kiev.ua> References: <20180530001638.GN99063@spindle.one-eyed-alien.net> <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) 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.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 13:41:59 -0000 On Fri, Jun 01, 2018 at 02:44:34PM +0300, Gleb Popov wrote: > On Wed, May 30, 2018 at 5:10 AM, John Baldwin wrote: > > > > > -- > > John Baldwin > > On 5/29/18 8:16 PM, Brooks Davis wrote: > > > On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: > > >> Hello. > > >> > > >> I've been debugging a failing Qt (KDE, to be precise) test and found > > that > > >> process name returned in kinfo_proc structure gets truncated to 19 > > symbols. > > >> This causes other errors in the application. I'm wondering why is this > > >> field so small and is there possibility to increase it? I think, having > > >> applications with names longer than 19 characters is not that rare. > > >> > > >> Relevant header: /usr/include/sys/user.h > > >> > > >> Simple testcase to feature the problem: > > >> > > >> # cat k.cpp > > >> #include > > >> #include > > >> #include > > >> #include > > >> > > >> #include > > >> #include > > >> #include > > >> #include > > >> > > >> int main() > > >> { > > >> auto pid = getpid(); > > >> struct kinfo_proc kp; > > >> int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; > > >> > > >> size_t len = sizeof(kp); > > >> u_int mib_len = sizeof(mib)/sizeof(u_int); > > >> > > >> if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) > > >> return -1; > > >> > > >> puts(kp.ki_tdname); > > >> puts(kp.ki_comm); > > >> > > >> return 0; > > >> } > > >> # c++ -o abcdefghijklmnopqrstuvwxyz > > >> # ./abcdefghijklmnopqrstuvwxyz > > >> abcdefghijklmnop > > >> abcdefghijklmnopqrs > > > > > > Changing the size of fields in kinfo_proc would be enormously > > > disruptive. Take a look at all the source that uses KERN_PROC_PID for a > > > subset of things that would break. > > > > > > Sometimes we can break these interfaces, but I think this one would > > > require new sysctl mibs. If we did that we should come up with an > > > interface that is identical between 32-bit and 32-bit systems and > > > doesn't export pointers. > > > > p_comm[] in struct proc is only 20 bytes long (19 chars + nul), so you > > can't make it bigger in kinfo_proc anyway as we only store 19 chars > > in the kernel. (Note that we do have room to grow char arrays if > > needed without having to completely rototill though; we use a hack to > > store the "rest" of the thread name in a separate array to export the > > full 19 chars of the thread name now.) > > > > If you want the raw command line you can't get that via kinfo_proc. > > You can use the kern.proc.args sysctl or wrapper functions like > > kvm_getargv() or procstat_getargv(). You can then use argv[0] as the > > command name instead. > > > > Thanks for your suggestion. I've tried that out and it does seem to work. > However, I'm slightly confused by the fact that procstat_getargv() returns > only command name and not the whole argv line, as function's name suggests. > Here is my code: > > int main(int argc, char* argv[]) > { > kvm_t * kvm = kvm_open(nullptr, "/dev/null", nullptr, O_RDONLY, ""); > > int cnt; > struct kinfo_proc * kp = kvm_getprocs(kvm, KERN_PROC_PID, getpid(), > &cnt); > > struct procstat * ps = procstat_open_sysctl(); > > char ** argv0 = procstat_getargv(ps, kp, 0); > > puts(*argv0); > > procstat_close(ps); > kvm_close(kvm); > > return 0; > } > > Running "veryveryverylongcommandname" correctly produces > "veryveryverylongcommandname" line on stdout, but > "veryveryverylongcommandname args args args" also gives only > "veryveryverylongcommandname". Is this correct behavior or am I missing > something? You do not print argv[1] etc, so they are not printed. Note that availabitily of the argv and env is optional, the data can be missed for many reasons. Kernel is guaranteed to see it only during execve(2), not between. > > > > -- > > John Baldwin > > _______________________________________________ > > 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" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Jun 1 17:20:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58BF0FC9C05 for ; Fri, 1 Jun 2018 17:20:28 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E663F681D5 for ; Fri, 1 Jun 2018 17:20:27 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-245-183.albq.qwest.net [67.0.245.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7B39519288E for ; Fri, 1 Jun 2018 09:33:19 +0000 (UTC) To: freebsd-arch From: Sean Bruno Subject: Building and Iterating Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: Date: Fri, 1 Jun 2018 11:20:22 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yUp6vOVvezZKGaKT5rq79Lj5KcAxuOhex" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:20:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yUp6vOVvezZKGaKT5rq79Lj5KcAxuOhex Content-Type: multipart/mixed; boundary="JNwkqQwTENYyzCffflNnJCYVbetxwreQd"; protected-headers="v1" From: Sean Bruno To: freebsd-arch Message-ID: Subject: Building and Iterating --JNwkqQwTENYyzCffflNnJCYVbetxwreQd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Before I dive into the mk files of a buildworld, I'd like to describe "what I want" so as to start a discussion of my goal. 1. If I select no toolchain (WITHOUT_TOOLCHAIN), but clang needs to be built, only build a toolchain that targets the ARCH being requested. 2. If I select no toolchain (WITHOUT_TOOLCHAIN), but clang needs to be built, give me a knob to turn that aborts the build with a meaningful message that lets me know I need to update the toolchain on my buildbox. 3. If the boostrap toolchain needs to be built in the normal case, only target the ARCH being requested. I understand that we "want" a CC installed that targets all architectures and this is something I agree wi= th. sean --JNwkqQwTENYyzCffflNnJCYVbetxwreQd-- --yUp6vOVvezZKGaKT5rq79Lj5KcAxuOhex Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlsRgFZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LacYwf/RPD2jw9fbJ/b6IkZDW0jPaYanoAWH7fF+rlowKKzLTi364K1+5FxTP9N 7PEgNDXUOwDnvcEyrHzjGyg7LvOP1Zm3A5Ukf2VyOD6hIubKh/CdGAiYWBcgIRB2 nWCoC0GqW0eq3zWgnLvJOfn32j/XMqa80lqc6HPeoJTcy7gC8+A4oI7LiYhSzL6k sTvIJTtgl1YyQrnYlXStn90po9fJXWEkCjROsYBMfLE8d/mX2Aq7dcPQpsbWvy4g eGevz0vc6JQqWx2OYZYakjb4eC5YHYSjvMF+LG0V0oq/JBG9CiQq29ewshxkDrEB Mey758VaBX7hnDUfm8O4Ip98GIeO8Q== =uO8P -----END PGP SIGNATURE----- --yUp6vOVvezZKGaKT5rq79Lj5KcAxuOhex-- From owner-freebsd-arch@freebsd.org Fri Jun 1 19:22:09 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0122EFAB8B for ; Fri, 1 Jun 2018 19:22:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E2E06E249; Fri, 1 Jun 2018 19:22:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id e15-v6so22549284iog.1; Fri, 01 Jun 2018 12:22:09 -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=w1aqZJKoHorq15mU8Uk7IWjmhyYiIb7Qo6nESEi3SE8=; b=RKNpXyCXoVp3tg97JORT+Y9DKAR5faMARV3loRgH4re2YevPV/dFRuDITdDUs4h0ss mPQnes4C+Te27YrzQ8mwQU8pL9cmRilA29Ya0BFz1pJxkmvTZZynmotkCpmwDu1QVxci AxRqeorX/mYIQb1XUDc/C9U3FQbawOClaCJa7Xx6y2S8rPD+gouq4b68DZat4Apyy1cn XxwhtLFrnmHCZ1S5VMKw2HPv0BNK4bWO6rdxHPVDRo26fthNoUQeMhUhpeP+OmDeKp/v oLXRFVHW/7adDmHRHO3OuiECRhsR2EKy7dWXl2NlBxJZ75hNaa00re/XdExWl8W9AVmO T9kw== 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=w1aqZJKoHorq15mU8Uk7IWjmhyYiIb7Qo6nESEi3SE8=; b=HZmuf4Wlf/HuR5ov6e726R5tlktT/5+H+wYE7dCCZqMGE9CSGP0FUF5NLivZ7BU8Jb yXz8EdHDT6/V0r30ans1pk5vCpOqNiIzGMuJuJ9crA4CTekaQJoYe2GEXSu69sVdx+sD 3ELt5OzELQS1XdpuKmOnarN5BE8tCoDL0vrSjvRBDyH93XH9OohuUf4T1tNUdAjxOTnv isjUfcV/FIg+WkIrKbjf+QFtK5z4m6wk9ecHengefHyhiPcl5K24BYvql+MnUSveF07X E4fYfK5j4fVIeaBYLogEgoxEimcleNH9VBZuZKL53CAD/dTeuzUkutwlFhu5wXrHx87k kPDQ== X-Gm-Message-State: APt69E2nGj4ZQG7gLIl8/HR75xU2vuX7P2PtJH3xncbh/N0vI7Uekg+1 9gtPtQFRh9+dnKt0vDKl9TF0gA1QK4GrPHNDot2vng== X-Google-Smtp-Source: ADUXVKLKS5b7aH3p6tbREZ4pUpml3UCdyHocBYQZn6g7fBCklZ+IZN0i+dqF9pz2kyQH64yYbBk8FfhN5sVSGWUpZVw= X-Received: by 2002:a6b:2cd:: with SMTP id 196-v6mr11557350ioc.294.1527880928047; Fri, 01 Jun 2018 12:22:08 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:87c4:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 12:21:47 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Fri, 1 Jun 2018 15:21:47 -0400 X-Google-Sender-Auth: 1jjPiSV_eRNf0FGkV6J5dcwlDeg Message-ID: Subject: Re: Building and Iterating To: Sean Bruno Cc: freebsd-arch Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 19:22:09 -0000 On 1 June 2018 at 13:20, Sean Bruno wrote: > Before I dive into the mk files of a buildworld, I'd like to describe > "what I want" so as to start a discussion of my goal. > > 1. If I select no toolchain (WITHOUT_TOOLCHAIN), but clang needs to be > built, only build a toolchain that targets the ARCH being requested. Note that WITHOUT_TOOLCHAIN controls only what tool chain is built for your target -- i.e., whether the installed world has a /usr/bin/clang, /usr/bin/ld, etc. It has no effect on whether or not Clang/LLVM/LLD/ELF Tool Chain is built as a build tool. From owner-freebsd-arch@freebsd.org Fri Jun 1 20:02:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5916DF72554 for ; Fri, 1 Jun 2018 20:02:48 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B68257071F; Fri, 1 Jun 2018 20:02:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id u4-v6so16501207lff.3; Fri, 01 Jun 2018 13:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QaKoWGue6p9610F02ZwdoExdbWY1lmSUZYOUZylR1O0=; b=dkqnJRshA4AbmLdYkPmWLk6RwziE7dx0Nx0yXzGHtwEEmWbzUlgbjEAr7y1/I30bmB ItIL0XiNj55GthI//UfeeoevpbWYt4Dilu+3l4ePTssVAN9Oz+EK6oJ7A/4RtvNjCsD6 enggMUeYRi46VHNVhDc8bemwutHfk7nW/0J8yvUBzCaDE8XGg6gL3dHiThDkLrrref+h 6SubuzTnLzAhgX5nP2xDTJY79c0uCmJ7YZ+8heM3e3+V4eyalFqrxzHYHMDaUmHOvUSN 3ziMFdlJ3DbkuOD0tplL6mKKijVWMpYnYJfWPdZiSAezD0y3kFfx+ea1VMdWnoHGuzL2 AmmA== 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=QaKoWGue6p9610F02ZwdoExdbWY1lmSUZYOUZylR1O0=; b=K+mV99iDmCZeOGjY+w8u5QjlsJ3RrrzYTVmjEWZr9PF8aSk2cH5fjMhFqRLN2Ju3FN fEy1Ku2GGjLEeWVGMPNQW4lGkUgPiPH5+j6tXjL379jmWtUsl7ql7Dna8wJWKC6DIl21 UKmtx8DJmKElQj0UHZQzoB2/XK2kAqev0BBscfuZ+W/DYQPGJvWZK+TFD4vXKcQTN249 O3+nuJHc1ijKLfhxD6x36crQRY2tGyLtO3dCm1tQyV9MOyVmoT0czMZd5dExqA0rUTJp CNLd8wp84zl4o967BIdKMyZGeflirwPBm9mI9AgzyzaSUguuwxG4Goydq7ilTjqUjero uPEw== X-Gm-Message-State: ALKqPwcHr3rwMk68AilqagTgkMIVQfP88014/ow7v/iDZD7FyY4D+Gjy 9pnwL6Evv/ZrW0WjOwY0PgoYvPsEWfPQUSrPoyQ= X-Google-Smtp-Source: ADUXVKJ0fhQnivQ5gK6oo9YSnvhEIp8Bm9GHjv/gWR1onpnSoZ0cuMeO+Pm3WtylepqpdsMsJMf3VujDeQ1gbQmOHHI= X-Received: by 2002:a2e:6591:: with SMTP id e17-v6mr5505742ljf.145.1527883366249; Fri, 01 Jun 2018 13:02:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Stone Date: Fri, 1 Jun 2018 16:02:34 -0400 Message-ID: Subject: Re: Building and Iterating To: Sean Bruno Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:02:48 -0000 On Fri, Jun 1, 2018 at 1:21 PM Sean Bruno wrote: > 3. If the boostrap toolchain needs to be built in the normal case, only > target the ARCH being requested. I understand that we "want" a CC > installed that targets all architectures and this is something I agree with. Has anybody instrumented the build to determine how much time this would actually save? Before trying to optimize the build we need to be sure that we're actually targetting the right optimizations. From owner-freebsd-arch@freebsd.org Fri Jun 1 20:12:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66632F73E77 for ; Fri, 1 Jun 2018 20:12:28 +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 1596570F91; Fri, 1 Jun 2018 20:12:27 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7DC305A9F14; Fri, 1 Jun 2018 20:12:21 +0000 (UTC) Date: Fri, 1 Jun 2018 20:12:21 +0000 From: Brooks Davis To: Sean Bruno Cc: freebsd-arch Subject: Re: Building and Iterating Message-ID: <20180601201221.GC29648@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:12:28 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 01, 2018 at 11:20:22AM -0600, Sean Bruno wrote: > 3. If the boostrap toolchain needs to be built in the normal case, only > target the ARCH being requested. I understand that we "want" a CC > installed that targets all architectures and this is something I agree with. The LLVM backends are a tiny part of the LLVM build both in terms of number of files and compile complexity. Removing them would require quite a bit of work (and ongoing maintenance) for a negliable improvement. --- Brooks --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbEaikAAoJEKzQXbSebgfAXRoH/2l5GyjWUfff4WFPSEUKwrkh 4mAhMiGYpEqohKhWb/EQrxvlVCSXTiCmCgVKz21n2OLdIcfBVlC7kH4nrIVw4gyO 3ROgxodjENK1XBfVRaMaeFJ1SVXKWOXkPfYb6kSBjFj+EOByAKCwr0bRXbfhcs/g dhIEPJ14kMjKHz48ZvSsqBYzSB5/QsgT8QgKb50xOdtEOBnrUX1IYDgyKY+kci4P RsFDn6H9aDj3W8QcZ1RoFGTUWIiqdFHN5A0NKOy3+8kEUOq8eGUTD+/xRWfCi9Gz yK+96K5xeEwYovzeWba/1csIdz8RQTO7uGc6pwNNdK8aZMyOFRIpC4pcGZLi4Js= =txsK -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From owner-freebsd-arch@freebsd.org Fri Jun 1 20:59:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 256B5F7B841 for ; Fri, 1 Jun 2018 20:59:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3051736D7; Fri, 1 Jun 2018 20:59:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id CC67FFC2; Fri, 1 Jun 2018 23:59:26 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Building and Iterating To: Ryan Stone , Sean Bruno Cc: "freebsd-arch@freebsd.org" References: From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <5d855fdd-f471-b9cf-de30-b6ef69945a9e@FreeBSD.org> Date: Fri, 1 Jun 2018 23:59:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:59:28 -0000 On 01.06.2018 23:02, Ryan Stone wrote: >> 3. If the boostrap toolchain needs to be built in the normal case, only >> target the ARCH being requested. I understand that we "want" a CC >> installed that targets all architectures and this is something I agree with. > > Has anybody instrumented the build to determine how much time this > would actually save? Before trying to optimize the build we need to > be sure that we're actually targetting the right optimizations. LLVM build could easily take one hour to be built on rather modern system. My VM to build NanoBSD images has 8GiB of RAM (1/4 of total physical RAM), 4 cores of i7 (out of 4 cores / 8 threads) and resides on SSD (SATA one). Build WITH cross-toolchain AND world toolchain is about 2.5 hours and build WITHOUT ANY toolchain (using host's one as cross-compiler) is less than a hour. -- // Lev Serebryakov From owner-freebsd-arch@freebsd.org Fri Jun 1 22:11:11 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA985FD3547 for ; Fri, 1 Jun 2018 22:11:10 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 695B476E8F; Fri, 1 Jun 2018 22:11:09 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-245-183.albq.qwest.net [67.0.245.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id DDD9619289F; Fri, 1 Jun 2018 14:24:09 +0000 (UTC) Subject: Re: Building and Iterating To: Brooks Davis Cc: freebsd-arch References: <20180601201221.GC29648@spindle.one-eyed-alien.net> From: Sean Bruno Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: <43b75e30-70af-e98d-7d9f-8fccaf3dcbba@freebsd.org> Date: Fri, 1 Jun 2018 16:11:06 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180601201221.GC29648@spindle.one-eyed-alien.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3z9ZuxdTalW0G6DH8D2eJDSCO1TxtFxEE" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:11:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3z9ZuxdTalW0G6DH8D2eJDSCO1TxtFxEE Content-Type: multipart/mixed; boundary="IYKstwpHx3Jfv4a6Z24UcUVyGAg9E7tkp"; protected-headers="v1" From: Sean Bruno To: Brooks Davis Cc: freebsd-arch Message-ID: <43b75e30-70af-e98d-7d9f-8fccaf3dcbba@freebsd.org> Subject: Re: Building and Iterating References: <20180601201221.GC29648@spindle.one-eyed-alien.net> In-Reply-To: <20180601201221.GC29648@spindle.one-eyed-alien.net> --IYKstwpHx3Jfv4a6Z24UcUVyGAg9E7tkp Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/01/18 14:12, Brooks Davis wrote: > On Fri, Jun 01, 2018 at 11:20:22AM -0600, Sean Bruno wrote: >> 3. If the boostrap toolchain needs to be built in the normal case, on= ly >> target the ARCH being requested. I understand that we "want" a CC >> installed that targets all architectures and this is something I agree= with. >=20 > The LLVM backends are a tiny part of the LLVM build both in terms > of number of files and compile complexity. Removing them would > require quite a bit of work (and ongoing maintenance) for a negliable > improvement. >=20 > --- Brooks >=20 Brooks: Can you educate me on why its so hard to maintain this part of our tools? I'm ignorant here and haven't looked to deeply into the abyss whereas you have been swimming in the darkness. sean --IYKstwpHx3Jfv4a6Z24UcUVyGAg9E7tkp-- --3z9ZuxdTalW0G6DH8D2eJDSCO1TxtFxEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlsRxHpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LbncAf8CjYKp68b1nYPvArRu4jJGGGyoYyfry5Nimskh6eKkLU1Bov1txvfFELW sFSom3b4n+18h4D/+JgD/geiYxc8tpWafSY40Oq9iJs16GCejBxQxQHY5D20NcG+ PCk8jr8Gm6oYWF/n5oEHAdLKWe4QiXm4ftBY5/4XABU5ylKCKM1RGRh4oKwfTFVG RI73POEh+amFO9YvI6+n9KXucOnaxyICZ1OVjhkN+piliTQ1dEzjYSAw75OQU39W 9UL5fJ4oGgctvohwtgvB/AUfVgXTECsddb+4OGYGU8WZHROMLtIdG0MDL1Y6SAAO IgviU9Eb4bGqzRl0F96mkhSoLO+7ag== =9Ib3 -----END PGP SIGNATURE----- --3z9ZuxdTalW0G6DH8D2eJDSCO1TxtFxEE-- From owner-freebsd-arch@freebsd.org Fri Jun 1 22:29:17 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1CFDFD5A1B for ; Fri, 1 Jun 2018 22:29:17 +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 546D177C77; Fri, 1 Jun 2018 22:29:17 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id C605E5A9F12; Fri, 1 Jun 2018 22:29:14 +0000 (UTC) Date: Fri, 1 Jun 2018 22:29:14 +0000 From: Brooks Davis To: Sean Bruno Cc: freebsd-arch Subject: Re: Building and Iterating Message-ID: <20180601222914.GE29648@spindle.one-eyed-alien.net> References: <20180601201221.GC29648@spindle.one-eyed-alien.net> <43b75e30-70af-e98d-7d9f-8fccaf3dcbba@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5p8PegU4iirBW1oA" Content-Disposition: inline In-Reply-To: <43b75e30-70af-e98d-7d9f-8fccaf3dcbba@freebsd.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:29:17 -0000 --5p8PegU4iirBW1oA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 01, 2018 at 04:11:06PM -0600, Sean Bruno wrote: >=20 >=20 > On 06/01/18 14:12, Brooks Davis wrote: > > On Fri, Jun 01, 2018 at 11:20:22AM -0600, Sean Bruno wrote: > >> 3. If the boostrap toolchain needs to be built in the normal case, on= ly > >> target the ARCH being requested. I understand that we "want" a CC > >> installed that targets all architectures and this is something I agree= with. > >=20 > > The LLVM backends are a tiny part of the LLVM build both in terms > > of number of files and compile complexity. Removing them would > > require quite a bit of work (and ongoing maintenance) for a negliable > > improvement. >=20 > Can you educate me on why its so hard to maintain this part of our > tools? I'm ignorant here and haven't looked to deeply into the abyss > whereas you have been swimming in the darkness. Because upstream makes absolutely no provision for this. In our case we do maintain the build infrastructure which would help a bit (since we wouldn't be maintaining diffs to CMakeFiles), but it won't help at all with the fact that any code can assume that all backends are there and the constants associated with there are defined. I'm not sure how big that part is, but we'd certainly have some divergence to maintain. IIRC the backends are <5% of LLVM compile time. IMO, the best way to avoid building LLVM as a bootstrap tool is to use xtoolchain ports. For i386 and amd64 I mostly use CROSS_TOOLCHAIN=3Dllvm60 (having installed xtoolchain-llvm60). I think there is still work to be done to make all of this more friendly (e.g. I'd love an xtoolchain-universe12 metaport and a simple way to use it.) -- Brooks --5p8PegU4iirBW1oA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbEci6AAoJEKzQXbSebgfApHoH/iIpnOSS/o/q3GCGagy3C9ug sUsFXmbVxzJlpADWSUXjj02b4wV6bFcZWJg/0G5DMPtXTXtp4EjR2jl1sKCBmPDY CxWYIZPq9TdAhEeJcS1ZZBczCllXMyQC98/adeKS2MSmiVj+JO6ZgZy+fdWv4pVp l5/m2EmmkOgIeX5w53PMRK+ZKJ0Ukgb6k7FZrzGQry996AohdjA98Z4zV78n8uFs KPE9Pg4pbYtAw/7Wbet4QkuozZRbUbDDseQQqg0VBmDQnY4FxkBGHfURf0JvFQ7P FTcPTdoodIYOQs9TOK3u+QhAOFhAtkIw+ah2cDyQWQpLlz1wOCc4nEstBZthdgI= =sg3Q -----END PGP SIGNATURE----- --5p8PegU4iirBW1oA-- From owner-freebsd-arch@freebsd.org Fri Jun 1 22:50:01 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF72EFDDAD2 for ; Fri, 1 Jun 2018 22:50:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (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 7098E79AC8; Fri, 1 Jun 2018 22:50:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f179.google.com with SMTP id g7-v6so7651517ioh.11; Fri, 01 Jun 2018 15:50:01 -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:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=R7652G017rN2TsFSfC+h02rGz668JCifTQHi0dKj2Gw=; b=I1m8RwoJ0zREqmJTq7g5k6Bj3Rl5+1SeMDCd5XYib+mj9YpIWX1NVD/5z7KBQ8oNmJ UEkEx4u0uO/UHG9dR/NZjUBqKL+2Ae4BAlNTrOLTq4Oh511Mxnnw8bZpwgHQsx/Y2TKd ca03hod9tVLbUPqxVcqTCTD2i7j1K1CIq5r9cSvF5Dnb6PF78xf71lT6regj0P6q8nBQ 0ZPKq+1hD43t8M0y5t4nI91ROFhSqqLfKlqCE5NYtSuNEc5GoCjBK40UES2YGn2jH79s KwYZBsTDJ89n54+QlJta+QUVzuhKUSIDCNE8L1eJff63kgZoBl34+grxxsWuO2wwO4Qj g+oA== X-Gm-Message-State: APt69E1siP/AdUke7rWX/0ViBjVlm1P3exgjoqMOA/a7KhLGIJeDU3pR Q2Mv5Pw5ZEPdqgz4ZH4t+mBw0oRh X-Google-Smtp-Source: ADUXVKKb6ZLPzaCcpbAsNzaCDfKlN6vzQ4ctFDGtINayZYqSbqv1NiXO45WUmt1uegWKu8KtDUKXNQ== X-Received: by 2002:a6b:fa18:: with SMTP id p24-v6mr6941407ioh.134.1527892954372; Fri, 01 Jun 2018 15:42:34 -0700 (PDT) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com. [209.85.214.43]) by smtp.gmail.com with ESMTPSA id u206-v6sm1439702itc.40.2018.06.01.15.42.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 15:42:34 -0700 (PDT) Received: by mail-it0-f43.google.com with SMTP id c3-v6so3717499itj.4; Fri, 01 Jun 2018 15:42:34 -0700 (PDT) X-Received: by 2002:a24:8385:: with SMTP id d127-v6mr6316382ite.58.1527892954116; Fri, 01 Jun 2018 15:42:34 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:5995:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 15:42:33 -0700 (PDT) In-Reply-To: <5d855fdd-f471-b9cf-de30-b6ef69945a9e@FreeBSD.org> References: <5d855fdd-f471-b9cf-de30-b6ef69945a9e@FreeBSD.org> From: Conrad Meyer Date: Fri, 1 Jun 2018 15:42:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Building and Iterating To: lev@freebsd.org Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:50:02 -0000 On Fri, Jun 1, 2018 at 1:59 PM, Lev Serebryakov wrote: > On 01.06.2018 23:02, Ryan Stone wrote: > >>> 3. If the boostrap toolchain needs to be built in the normal case, onl= y >>> target the ARCH being requested. I understand that we "want" a CC >>> installed that targets all architectures and this is something I agree = with. >> >> Has anybody instrumented the build to determine how much time this >> would actually save? Before trying to optimize the build we need to >> be sure that we're actually targetting the right optimizations. > LLVM build could easily take one hour to be built on rather modern syste= m. > > My VM to build NanoBSD images has 8GiB of RAM (1/4 of total physical > RAM), 4 cores of i7 (out of 4 cores / 8 threads) and resides on SSD > (SATA one). Build WITH cross-toolchain AND world toolchain is about 2.5 > hours and build WITHOUT ANY toolchain (using host's one as > cross-compiler) is less than a hour. Unfortunately, you aren't actually measuring the impact of Sean's #3 =E2=80= =94 which proposes eliminating cross-compilers from Clang *when building Clang is actually desired or required.* It isn't clear that the additional cross-compiler backends add significant overhead to the total Clang build time, which includes a lot of shared code, like C and C++ parsing, generic optimization code, etc. Ryan's just asking for someone to measure that to justify the change. Best, Conrad From owner-freebsd-arch@freebsd.org Sat Jun 2 17:29:30 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBD02FD4E6D for ; Sat, 2 Jun 2018 17:29:30 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002: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 608756DBE0; Sat, 2 Jun 2018 17:29:30 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-yb0-x242.google.com with SMTP id h141-v6so2571226ybg.4; Sat, 02 Jun 2018 10:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k0x841W2TWVtt5lp1ERxQ16a4SvbTRi4J1YD6mnkKi0=; b=LWsPNmY/j/3pW4XsoC25KqZNiGGRYZTgKmYyNDQpD/HjPoJ/VJJ5mxfGWppDWxZ2dM +Swdn/frx3RC8XLaYWLeWrmQRfsLOjpbBEfw/nEjEGQ2YalrCBnsbglezWjMTfYbir6t 00xBnscuSetPvitew95bVbTRVzHV8brCEVFVDoJ/0o1EIFRL4IdGHFFnHZBXBxE1VmHB RJCrdNiAMBZD1uWlmlmGWsfweJRZt+u1x3Z4dt2kykJjTuSZLhfYlMK83BV8hqUfu1bC hhrpZ8MWADwEj5jYqjHsK7lgfnGxkmJrkceqa//wwlRwkl22J6YvAKR90eGs56HLXaIm y1IA== 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=k0x841W2TWVtt5lp1ERxQ16a4SvbTRi4J1YD6mnkKi0=; b=c5l1cbaibiD2h6RtTArSVLKMEek1qtv6V6DOS/CWQe6BHKZNiuyG693o+RvgpFZ+M3 GoR+omv/hD3oj8rzF+PJ51YKgUsqr1r8q1lZDUUFmVq9MngZK9idHfCVU+refo7ec/N/ UtwrZQCuI+Z151xVzxfE1jfs7SFunfwBJENZPPTaPaIY5bea/bz1ouSgznR46pSQWVuX n5LlIlTyMJpVtX+COsoK7dUBxZHBfablSRC6dLsK0kszl7PidS33426Bmz+u/gpOuFaO cy69OyKE3ffdJ/JaenNgwi3EIDFEN5CH4xL7eV/66IK9VZP/46jUmEPh0v5kL6zItchX 6FRQ== X-Gm-Message-State: ALKqPwfvqyTEpuGu8ddZel7yj97sv3uohGEmVBKtYXqO1nrYSet3acWl pNbP/cD6Nq7x5syAZmF4VQY+tyPJPwyu/SsXYH+QStvh X-Google-Smtp-Source: ADUXVKLvbTPwjDoyjQkHxld/9ZMczCJhenDCjOLedmYomMxTEhXP9lcxC/DpZcjFUMDrArjyM2DMJuhAZEcqGoGhnn4= X-Received: by 2002:a25:44a:: with SMTP id 71-v6mr8585493ybe.463.1527960569447; Sat, 02 Jun 2018 10:29:29 -0700 (PDT) MIME-Version: 1.0 References: <20180601201221.GC29648@spindle.one-eyed-alien.net> <43b75e30-70af-e98d-7d9f-8fccaf3dcbba@freebsd.org> <20180601222914.GE29648@spindle.one-eyed-alien.net> In-Reply-To: <20180601222914.GE29648@spindle.one-eyed-alien.net> From: Alexander Richardson Date: Sat, 2 Jun 2018 18:29:18 +0100 Message-ID: Subject: Re: Building and Iterating To: brooks@freebsd.org Cc: sbruno@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 17:29:31 -0000 On Fri, 1 Jun 2018 at 23:29, Brooks Davis wrote: > > On Fri, Jun 01, 2018 at 04:11:06PM -0600, Sean Bruno wrote: > > > > > > On 06/01/18 14:12, Brooks Davis wrote: > > > On Fri, Jun 01, 2018 at 11:20:22AM -0600, Sean Bruno wrote: > > >> 3. If the boostrap toolchain needs to be built in the normal case, only > > >> target the ARCH being requested. I understand that we "want" a CC > > >> installed that targets all architectures and this is something I agree with. > > > > > > The LLVM backends are a tiny part of the LLVM build both in terms > > > of number of files and compile complexity. Removing them would > > > require quite a bit of work (and ongoing maintenance) for a negliable > > > improvement. > > > > Can you educate me on why its so hard to maintain this part of our > > tools? I'm ignorant here and haven't looked to deeply into the abyss > > whereas you have been swimming in the darkness. > > Because upstream makes absolutely no provision for this. In our case we > do maintain the build infrastructure which would help a bit (since we > wouldn't be maintaining diffs to CMakeFiles), but it won't help at all > with the fact that any code can assume that all backends are there and > the constants associated with there are defined. I'm not sure how big > that part is, but we'd certainly have some divergence to maintain. IIRC > the backends are <5% of LLVM compile time. > If you build from the upstream CMakeLists you can set -DLLVM_TARGETS_TO_BUILD=X86 (I believe =host should also work) and then compare that to the time it takes when building with -DLLVM_TARGETS_TO_BUILD=all. I don't think it will save very much time compared to the total build duration since you will still need to build quite a few files from lib/Target (especially for x86). ~/cheri/llvm(master * u=)> find lib/Target -name "*.cpp" | wc -l 723 ~/cheri/llvm(master * u=)> find . -type d -name "test" -prune -o -name "*.cpp" | wc -l 3147 Just based on this it would seem like in the best case you *might* be able to reduce LLVM compile time by < 20%. However, depending on the target you will have to build about 200+ files in lib/Target as well and at least to me it seems like the .cpp in clang take a lot longer to build than in LLVM. My guess is that omitting the cross toolchain could give you maybe 5-10% reduction in LLVM compile time but I haven't measured it. Alex