From nobody Tue Jul 23 19:58:13 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT7HV44WKz5QJgP for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7HV3GGKz476f for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721764694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ILnigj07bQFH2MZxpFb0aCMfHaK2T4up+dsXo06Sg5s=; b=yz5qISMgy/XGFaqfySo7CJ5QZZjrau2buh8IxzJHoeniGRGY8Xf4EVlWqsa+yhGJ8fjcVh OCDUPmD2VXciZhXc/tLVvuPfZPsW6x7Sz9kk7kyJrNoKuLW/9yXPv1NNK1Grzk7TVhwH+f 0ohFsf25mRnp83RPAoKVVzHo6ZWOc8DDYn9z3bdXqJ8CAaHPk6ZB55o7OZrIbEFbMScIOI iHaAUBB4o1d0leq42nRN6s4VIPoR835Y54lgMsudv22GYw8tkMorQIG9FdnddaSzf5513e frvjMSCI9Bn5a5PRroTPgxU3E308Lpv18HUcfOcpF75UwJUCsdZ3OS+wKl2XUw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721764694; a=rsa-sha256; cv=none; b=Q3s8rUlKoToBGYElXKIIp9KPCzJ8sniN2jUWjzYAuFlcjZpkLqWa1BPxt8srcwTPHI2haZ 0yGI8OH/fmiAR9HIZm/jOLs9hp/0qJLw+rBbLlVjFjdNzLvbZOQABKn4G9lMoyeUFEnMWs YlT2nHiBhVU9bpSHSVNpv+Xo0XlMUVg23NXw7CwuKVVRW1QER+eZlYHdJjZE4FWdR1cSpX SBnuqoj1fv64owvvW4S7GY/o/MhEWx92Ep1liycHpLAW2Bj2sgUoORDmktai3frdWxCQNg byBInVuTUTV8QC3Kiz4pzOG/V6uDcTN28UmxzsZ2wQ76YvqViENEMCHcAtawiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721764694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ILnigj07bQFH2MZxpFb0aCMfHaK2T4up+dsXo06Sg5s=; b=pganxC2Ju0G02ISKeojNLhq5XTqkOfYK/n7gJNBGWB2I4/LnpcTthac4OeA/ujkvsbQjxP NN+tBvxjfGdIFFNtEmyJ+HH9Kb/Tim5dPvcOwtTapRiM8pnbX3RA+k9Kkq6O567Mxu8s4H mmCn7RsMvDy7+FDgGNppnOm/2tj6kUE0bYfBuAef+gPSEO1zAGBXRy6KUXekJ0sKIhPPBL 6MsvPL1pBhxpRhSSYCniGIVIl0oWAVQjvvhrPdpDpZ9kSQFJY2ap6k0bJrYRGRkcZbU/JB VtlTx0HT9quF5lZc+XwBoC3gAwlb6u29WWsfXrRRxHQ7R/45WIC8AoZCNuvPow== Received: from [IPV6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76] (unknown [IPv6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT7HV2CDZzFNK for ; Tue, 23 Jul 2024 19:58:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> Date: Tue, 23 Jul 2024 15:58:13 -0400 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: John Baldwin To: arch@FreeBSD.org Subject: Default NO_CLEAN=yes in 15+ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The buildworld and buildkernel targets include a "clean" step before building objects dating back before my time to 'make world' (I haven't looked to see how far back it goes). To permit incremental builds, this step can be skipped via NO_CLEAN=yes. This step is a bit unusual in build systems however. Most build systems have separate commands for building vs cleaning (e.g. 'make all' vs 'make clean') and over time FreeBSD's build system has gained dedicated clean targets as well (cleanworld and cleankernel). For myself, I always use NO_CLEAN=yes when building worlds and kernels. If I need a clean build I use the dedicated clean targets (e.g. cleanworld) first. In particular, cleanworld/cleankernel are far more efficient since they use a single recursive 'rm' whereas the "clean" step involves a full tree walk with nested make invocations of the 'cleandir' target. A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To preserve existing behavior this knob currently defaults to on, but I know Ed's goal was to eventually flip the default so that NO_CLEAN builds would be the default. I would like us to do that starting in 15. Further off, I would suggest that we remove the "clean" step outright, perhaps in 16.x. Regardless, we will need to update documentation to prefer the clean targets over WITH_CLEAN=yes if our docs do not do this already. -- John Baldwin From nobody Tue Jul 23 20:03:52 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT7QF5FHNz5QJv9 for ; Tue, 23 Jul 2024 20:04:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7QF3Wzsz48j1 for ; Tue, 23 Jul 2024 20:04:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-39834949f27so20612255ab.2 for ; Tue, 23 Jul 2024 13:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721765044; x=1722369844; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z5+iwfJ99+ZJ1yp0xXbv2r9MaISTEvv4LEPdVSAlL7U=; b=eJHiAE1+BrLfUSYxzN5twHYRm/fZ+OVmQKXkflbopKrAvxcylnoRTD4Usqt6HcGuGM HtuDLp1qiYr4rSJ7+JP9xcJKYJ456FlGEXQ3qTsmtDBIC1TZI426xhfQG8bTbOrCqRT/ 0B0d0RWxnZDDkVsGDNOrIJ6uGEvIA/qtLMi9VootJF1IFG4+PH0SrayuFoodlvMb4JSs 1Kje+8jKVaCliv/yUlx0Mmj0i9jcgI2Fd+OgNkmdUNDBlDd81rVAlEVCjJdLQ7jZSCN5 vUP3rz388X0AwCDdztY5cqsLJl3ZWpcNFTJuWoXmFqlYZqgerdunzHxq/uUHrMgHB94i ibWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721765044; x=1722369844; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z5+iwfJ99+ZJ1yp0xXbv2r9MaISTEvv4LEPdVSAlL7U=; b=W6CLVu29XT+DXNzADe7k/3nr2qnaZRpm7Aa1u988c6WqMSU/B8SoxplswEwAixXyqT ByXxV1ILc1ZqqD0zkhkRfJLqclPgY+43r/0yIL2+irkbBvwbqaAf3f4X7b5ljijHy5aq XO9E3e1xjktRlw/likAt16D58IghFhrh5uzoqaLHMSTdYaDXXGBJwEBG54zf9k3QWRDy uMuL8hz9Fs6S99krUrZAUUqqeX6/q0wyScvKhVLOXbGcnK98+SGPIiCHi2nCKXPpvSGK TxBexv9a+b2FRas1/oFZ4ZBzhSgiUiC4LfQdVh9qsS6i402q329PbGNT8uYr9MU6Y9wK fm1g== X-Gm-Message-State: AOJu0YyaPhTF6hEgRN2wZgdhs/rYEwsNvHyInnKdbyGhN7uqAyo/wX4f uN5l0jSYBJ/kvbN3FkVCeXP96o1jrEOQV07yg6rU3B+7IkewNkhg31+sqQmMd4/RE5mNOPlcFmX kk8WR9wZIdR/IWUpJCzcWjrs1LI9vV7p7GDG12Q== X-Google-Smtp-Source: AGHT+IFER5zY7twGMVE2hsv1bFo/6+zCKB48aZWim2Zm0VTJ7iw46nPc8qkVv30rUrShnu3qUktZYUQbVR7lPeIlnjc= X-Received: by 2002:a92:c243:0:b0:398:1bf7:a177 with SMTP id e9e14a558f8ab-39a1925327fmr615195ab.5.1721765044530; Tue, 23 Jul 2024 13:04:04 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> From: Warner Losh Date: Tue, 23 Jul 2024 14:03:52 -0600 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ddd003061defa9a1" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WT7QF3Wzsz48j1 --000000000000ddd003061defa9a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024, 1:58=E2=80=AFPM John Baldwin wrote: > The buildworld and buildkernel targets include a "clean" step before > building > objects dating back before my time to 'make world' (I haven't looked to s= ee > how far back it goes). To permit incremental builds, this step can be > skipped > via NO_CLEAN=3Dyes. This step is a bit unusual in build systems however. > Most > build systems have separate commands for building vs cleaning (e.g. 'make > all' > vs 'make clean') and over time FreeBSD's build system has gained dedicate= d > clean targets as well (cleanworld and cleankernel). For myself, I always > use NO_CLEAN=3Dyes when building worlds and kernels. If I need a clean b= uild > I use the dedicated clean targets (e.g. cleanworld) first. In particular= , > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. > > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To > preserve > existing behavior this knob currently defaults to on, but I know Ed's goa= l > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. > > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x. Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do this > already. > +1 On the one condition that NO_CLEAN will be silently ignored after... Warner > -- > John Baldwin > > --000000000000ddd003061defa9a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 23, 2024, 1:58=E2=80=AFPM John Baldwin <= ;jhb@freebsd.org> wrote:
The buildworld and buildkernel targets incl= ude a "clean" step before building
objects dating back before my time to 'make world' (I haven't l= ooked to see
how far back it goes).=C2=A0 To permit incremental builds, this step can be= skipped
via NO_CLEAN=3Dyes.=C2=A0 This step is a bit unusual in build systems howev= er.=C2=A0 Most
build systems have separate commands for building vs cleaning (e.g. 'ma= ke all'
vs 'make clean') and over time FreeBSD's build system has gaine= d dedicated
clean targets as well (cleanworld and cleankernel).=C2=A0 For myself, I alw= ays
use NO_CLEAN=3Dyes when building worlds and kernels.=C2=A0 If I need a clea= n build
I use the dedicated clean targets (e.g. cleanworld) first.=C2=A0 In particu= lar,
cleanworld/cleankernel are far more efficient since they use a single
recursive 'rm' whereas the "clean" step involves a full t= ree walk with
nested make invocations of the 'cleandir' target.

A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to= as a
WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes.= =C2=A0 To preserve
existing behavior this knob currently defaults to on, but I know Ed's g= oal
was to eventually flip the default so that NO_CLEAN builds would be the
default.=C2=A0 I would like us to do that starting in 15.

Further off, I would suggest that we remove the "clean" step outr= ight,
perhaps in 16.x.=C2=A0 Regardless, we will need to update documentation to<= br> prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do this already.

+1

On the one = condition that NO_CLEAN will be silently ignored after...

Warner
--
John Baldwin

--000000000000ddd003061defa9a1-- From nobody Tue Jul 23 20:05:15 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT7Rc71LYz5QJvN for ; Tue, 23 Jul 2024 20:05:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7Rc6XKqz49hD for ; Tue, 23 Jul 2024 20:05:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721765116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IXf5CQPtba/XquHjcp9IIxglket7wvVFkRDS46k8QcE=; b=PAVQPYtNEeAGFClaZorkPWFoLYXmF00b3kbLGStm3q09yWVjzque12PTp2oOqiz7XpVcrT BnoOBEMXCdNKMtL8Lxn62YGBJ3FzA6Njqe645iaPs64fVcnkPKPW8xgQpTQZReSGraRxyr lKx4ZyWLMjtxXpd6jlZIUc4s0XAyCcjNOYqf1I5DGhX+OelnUBEFOM/JrlSERKlKZtCFau +/SME4RVZwA2Fi9bLf4oz4Z+IETVqtL3sEe7K93h9MZCHYXb8swPwVfKT+qc0zzgzGPhjf nxlQ08qfmm899wC38nG5hfg235BFOqEEECFJ97I4H5xXY5z+FWyndDgYGBE8eQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721765116; a=rsa-sha256; cv=none; b=xeuwn1AVF0unqPesQN36gO+sCo8rct7TSvVBZJquksgtWdFX8ySBvWdliBoZKBF6WvSu+l naEMM/bDJ+Fow/Pxk8kXV3EgBK5srZSUj5GiMQGTITN0l1qjoZM3+2ATcBGMzJamx12zPF vXCPUVhZmzQVw/XzWdyaFd04R5aLMg5+GATudY5k22Rf+Bh+zxyuvJoIDTxjF18F6lcExN K+u4Dswf+kHdFdFZPPzfr7ijO0W830mAlByGEYPUvslrrdEHZxYBvmJaqPQz8BSRfQGQcJ e4b8h6YvVSsB/nMHhX0zZGu8T+9xGMRKkj3WJ/yF+SdVf3tJRUmDOicP4NDA/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721765116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IXf5CQPtba/XquHjcp9IIxglket7wvVFkRDS46k8QcE=; b=Qar6lHN8qNeIbksf2ZGJPWpCfru0R7lHhbJYdEQOCiFgnUpw2y4yZ7c9dHnAZ8B6lPBSia 023G5q2Pxq70sJoh0iS+JBM0bT9TMv4187tfKZbpn/3jhHlo3RhRRbd4nMk5kJW8HK5t7A lDt3qnYFBt6BB3LVMV7kKL0z4dxXkyymCtoeAxZjEJNgfDYr23A5UM5I8kLLLBTSDDo92J VyTa1yI+of+2Lk5+fXVbt8Y8dR8HA94yo1FcvVo4s2ILnoIxusAMixu3FgMHnaKGKRsAAg MkjZOzgPYJDr1W+/vd1iD2XCedGnylFMObAoWd0esjs36M0fIZ+ejrfDiX9lsg== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT7Rc4v5FzGCV for ; Tue, 23 Jul 2024 20:05:16 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <7a43f00d-b628-45ef-bfef-9685bbf999cf@FreeBSD.org> Date: Tue, 23 Jul 2024 15:05:15 -0500 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Default NO_CLEAN=yes in 15+ To: freebsd-arch@freebsd.org References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> Content-Language: en-US From: Kyle Evans In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/23/24 14:58, John Baldwin wrote: > The buildworld and buildkernel targets include a "clean" step before > building > objects dating back before my time to 'make world' (I haven't looked to see > how far back it goes).  To permit incremental builds, this step can be > skipped > via NO_CLEAN=yes.  This step is a bit unusual in build systems however. > Most > build systems have separate commands for building vs cleaning (e.g. > 'make all' > vs 'make clean') and over time FreeBSD's build system has gained dedicated > clean targets as well (cleanworld and cleankernel). >. I note that "most build systems" includes our very own bsd.prog.mk, bsd.lib.mk, bsd.kmod.mk... extending some consistency to our higher level build orchestration seems fine. > For myself, I always > use NO_CLEAN=yes when building worlds and kernels.  If I need a clean build > I use the dedicated clean targets (e.g. cleanworld) first.  In particular, > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. > > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes.  To > preserve > existing behavior this knob currently defaults to on, but I know Ed's goal > was to eventually flip the default so that NO_CLEAN builds would be the > default.  I would like us to do that starting in 15. > Yes, please. > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x.  Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=yes if our docs do not do this > already. > Yes, please. Thanks, Kyle Evans From nobody Tue Jul 23 20:08:17 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT7W863snz5QKl7 for ; Tue, 23 Jul 2024 20:08:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT7W84L1Zz4C8q for ; Tue, 23 Jul 2024 20:08:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd2c.google.com with SMTP id ca18e2360f4ac-816d9285ebdso235978239f.0 for ; Tue, 23 Jul 2024 13:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1721765299; x=1722370099; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=YytxfDlWjtIuuFF8SAKkph5JiNFfD+7i+hIGg05/Q3M=; b=XhV6dtasEWskslBAIJ+eZPFIvvOJl8ntQDReu2ijLT3jttR6mBzhhzlnBO+0aNK9kV zcny/EZAaPyDUN5LtPOZ4UX3Qh7cMBFBmj1+kLz9MmkbP5uXMNGLrY8tfgS1zdnyKe/J n8kY7UDfhTaknx5rp5MQuvmq8cj7WFSWKUp1a3uXbnXeLiE7pnYG1yq3ZW7ACATPq7Kp 9RKcKneZR/VgRwAgo6OAn/BGlkwEpxV6IxbuyCjoAys4Ovrmo3ga5iaiGoMtrbb9zg1m sQTlCoRweRx3RFcPgmY3tRoAhiFREo47u3RmsfwxF+yFZM7vzLFb+2C+QVyBUNm4qh5L 8lFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721765299; x=1722370099; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YytxfDlWjtIuuFF8SAKkph5JiNFfD+7i+hIGg05/Q3M=; b=GOudEt9edxnZRp0DN4RiWFXPh1jAbHQSUymEuQzaUlpadyt3jsxRul+nL5elVarzCt 1HpuzKeJ/Zv5qDvrADAxPjppFvvB3M6WZVsmCapv2NVyn56JVqOFAgT0ZHw9+UOVOGUF vMFozb24C3uUZw8WpN1RUE1QkZCVg2/oxinK0TDyImfMMwCDsOZIxKICF6113iJgf0SM By0hU5LisohCJ4hNgu3DYkvx8UPSJ46RCh+0uwpGEnnDEReOW/yg/M7u/sGn8W89iQ4+ mQt+6593r+ZVVKwNLm6QCeeVR0QXWvpd4DjObkMy5tiehNz/qLLj2qd+kDNrVvPYlOAA suqg== X-Gm-Message-State: AOJu0Yw2k/OY/xLsj4CiquHme37Xvq4hIdLhSgswDbt03Al+CvaekHU0 2liDguNpFp6qPYCraiZ9fPa1jHQwRLUJTpbnpeMCH+fu2e4vCjawujqCNSkHVUw4Gi+o4LbHpYq k X-Google-Smtp-Source: AGHT+IGm9NuGAB5YsUgdkVMoMHTkKhjLdxOhDTlb+YOOGkRw7VKD7mQ9Y3N9DXsX6W9lk960diSiEA== X-Received: by 2002:a5e:9701:0:b0:807:4340:947e with SMTP id ca18e2360f4ac-81f71d9d7d2mr17361739f.15.1721765299517; Tue, 23 Jul 2024 13:08:19 -0700 (PDT) Received: from mutt-hbsd (174-24-87-135.clsp.qwest.net. [174.24.87.135]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4c28c6f05b5sm50176173.43.2024.07.23.13.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 13:08:17 -0700 (PDT) Date: Tue, 23 Jul 2024 20:08:17 +0000 From: Shawn Webb To: John Baldwin Cc: arch@freebsd.org Subject: Re: Default NO_CLEAN=yes in 15+ Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eoazrax3o7oapfy7" Content-Disposition: inline In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WT7W84L1Zz4C8q --eoazrax3o7oapfy7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: > The buildworld and buildkernel targets include a "clean" step before buil= ding > objects dating back before my time to 'make world' (I haven't looked to s= ee > how far back it goes). To permit incremental builds, this step can be sk= ipped > via NO_CLEAN=3Dyes. This step is a bit unusual in build systems however.= Most > build systems have separate commands for building vs cleaning (e.g. 'make= all' > vs 'make clean') and over time FreeBSD's build system has gained dedicated > clean targets as well (cleanworld and cleankernel). For myself, I always > use NO_CLEAN=3Dyes when building worlds and kernels. If I need a clean b= uild > I use the dedicated clean targets (e.g. cleanworld) first. In particular, > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. >=20 > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To pre= serve > existing behavior this knob currently defaults to on, but I know Ed's goal > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. It would make sense to me to default MK_CLEAN=3Dno in release branches. Perhaps stable branches, too. While I don't hold a strong opinion on the matter, I would prefer MK_CLEAN=3Dyes to remain the default on the main branch. I can't give tangible examples, but I remember running into weird issues occasionally when using `make buildworld WITHOUT_CLEAN=3Dyes` in main. I probably should do a better job at documenting those (infrequent) issues when they arise. >=20 > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x. Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do this > already. I would not be in favor of removing the clean step. Removing clean outright seems like a step too far--a potential POLA violation, even. Please keep clean in. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --eoazrax3o7oapfy7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmagDaoACgkQ/y5nonf4 4fpSTw/+I+BcOPG8wEGk66ZKseJegDAW81kIzty1PWr20sWUowpJUe7v6Zsui9nq H2gToYVsRDm//MSPjwvKg0XdS2R3+vG/ifHm0+640kJ+RF7hMcGLQi2MgRYw57tf RQ8dfuzO1cA/cQ5dKmuniE+pxgmcMFl+cpzx5ZfvqZcOMJ0SdIDV+AldpPqIx+g5 NK/pPxZ/wPvuteF3EBlKilYnYxjwkKmT2yKS0WzmwDvScgHHNdbLCI4A+P6wyeBQ DG7BuMuW0KxWwkaG+pciM7DByOMvhkWfM8/kHmEX7DSwuWRdZWXFBrtutyZuk8s/ OapVvvwxiUYUBlDLQElxjgHd3xgQK9aqwVD5+ej+WIsIXzanef0KzgCGiWsoKv2l 1jr8e/piDNanH8uL96qw7NgZXLaCi7uBTcpySRHUUVVuNqXkUL0C9GnXG2L/GzEG LDJm68cFHkZa1VdnssBOtmTy7nRDE3IpZ/5NmxbewxmsmpE+g7LMSym6ChpRp+D+ FdBSPizOgeskXvXjCg6m2U8kGsOmsYQ5jaZkamWTNtoGPcxjOUOOeeFWUvhgMctc zNfS/M3G5rDY3vNgOOs+MWEJqrfYFQAUhCGKPZDWkcYemjlGANBngHLmVokb04/s s4F2BTVZcuK1fggrvDMyU2O4M9SyYQKWI89+2FsMohO7v1jx+b8= =LfS3 -----END PGP SIGNATURE----- --eoazrax3o7oapfy7-- From nobody Tue Jul 23 20:33:28 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT84B0WZcz5QN27 for ; Tue, 23 Jul 2024 20:33:30 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT84975Mqz4KXM; Tue, 23 Jul 2024 20:33:29 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721766810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qcPzhCQPmIicoLqsJVVFwI0KuYCWGBvcVAOwefwLe48=; b=LMHAVoShSFgOSySDqQVt59PFto2zWqnhA+/D3cWUzfsbTwPkwfkMyi74V6jKXaZ5UzZclm icvuxSEqidCpCkh8DP6UbAxO8OqJLdnLj8N6wTILfQSGDr9FHu0A3XmZQDIb1uJSJoD+/J Uyn7BcaAthHXORT7qh7gR3Z+01UThHgrdO3eb2zKE7IQj7lWQwbmwP6SGSVIsxmGUx8kn9 VYh8yW+J4BJCIcJYDBVmvt+cj3AaXiXKxKqclWLnI+eFmOJNCqmvN8M4yeysyZ+WN/oJwu QH4RCINOId+7Jk4FAnI14z+1EEvAZzmGJtJ11HyboucdmY8CitkcqYK3Oc+1mg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721766810; a=rsa-sha256; cv=none; b=pRwo+WTz515RLhWOnU0c2s5RBXqlaH24LyUYkYJ1sDS+2kpGJCXxPkLTSvb60+2GGyYSw9 gWP9nCZlO62tjX7gQ4gaznbLOhgw9GrcYKIMiFSsBXAz9a64c3gaQek3jeHbOfbTH6Hw1+ cz4dLTwyx8rC87dVPHnqWGGpTiB/yCLqNe98m05Q9U2qOAXnjxijfOUvdcaFK6UaGqkExr czfZ+++3X/qsTSkImlVOozrJwohhlhBs4GOj1Of2vweyvRsejnH+eWOmjiBw7LVMz0TgFD 4GDD2kL7D1SS2tRnmURC8xppw0wvdPi9eV11NJfYJP+b5wq6w5Bh3BVEDpnz5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721766810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qcPzhCQPmIicoLqsJVVFwI0KuYCWGBvcVAOwefwLe48=; b=yR2i4lZ9SadQKFAAShMKBOvrucXrK1PuzFbYBCmMuP5NNji8aYPLL33kkPbK3cYojFe+dQ fqj6+e+q3ZKjPMphw40lrgNHcm+q7hKXcV3k7Zbqh9eNlfnaMvJHTeGobmeNIQWZYScV94 IoSKY3ilxiKpRF7ihw1Xr+sBl31FKTEsDJYi5Ic7Asydwt4iRJEXDyHDyD9s0C9FmuV6UZ hH8PkZrjMf/WF2vkGuSSYir0lA83GDhizppSok/pyTuLjXiqD7Jei9rf8g42bhPH9NXKDS dhBDQLGywh365XqcskQw1ibNsHmjaygcwwkE8JrRuKzoFyDCea/BddEJrej5cw== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT8496R8czGf8; Tue, 23 Jul 2024 20:33:29 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id C4A943C019B; Tue, 23 Jul 2024 20:33:28 +0000 (UTC) Date: Tue, 23 Jul 2024 20:33:28 +0000 From: Brooks Davis To: John Baldwin Cc: arch@freebsd.org Subject: Re: Default NO_CLEAN=yes in 15+ Message-ID: References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: > The buildworld and buildkernel targets include a "clean" step before building > objects dating back before my time to 'make world' (I haven't looked to see > how far back it goes). To permit incremental builds, this step can be skipped > via NO_CLEAN=yes. This step is a bit unusual in build systems however. Most > build systems have separate commands for building vs cleaning (e.g. 'make all' > vs 'make clean') and over time FreeBSD's build system has gained dedicated > clean targets as well (cleanworld and cleankernel). For myself, I always > use NO_CLEAN=yes when building worlds and kernels. If I need a clean build > I use the dedicated clean targets (e.g. cleanworld) first. In particular, > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. > > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To preserve > existing behavior this knob currently defaults to on, but I know Ed's goal > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. +1 We should continue spot cleanups for things like foo.c -> foo.S as required rather than pointlessly rebuilding everything every time. It's much better for a small number of people to spend time tidying things up than to make expensive cleaning the default. > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x. Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=yes if our docs do not do this > already. I strongly agree. It's all weird and unnecessary with things like git-clean(1) available. Eventually I'd like to get rid of cleandir and its weird behavior differences based on .OBJDIR's existence. This is tooling for the distant past. -- Brooks From nobody Tue Jul 23 20:37:08 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT88f52xCz5QMxg for ; Tue, 23 Jul 2024 20:37:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT88d5rlKz4Kck; Tue, 23 Jul 2024 20:37:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f44.google.com with SMTP id ca18e2360f4ac-819c1f5348aso213466839f.0; Tue, 23 Jul 2024 13:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721767040; x=1722371840; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XN2ye7hpq9PfkA4IrzyjqUHzrA6GrnKuOup8jF5ZZ/0=; b=upyBCzZRoFChK2upOwvhEYIDzfSJgqomPELZdnb2MRO0+a06FZELh2QY0SV+g9Rp51 QCdfFvAO9dmTLakz9c41vWM9zW9Mj75dy0LUHGYuYcqxW2PhYhv5/Y4IghmGZTAIuzh6 98Ao/RmbIaaI57rfWklzGAP/4RIAJR8G5LR5cKXNGVtF7y8I1IA4O7TDPBZjJuSn/IPp NITzq07SxUagWjEe44P1c8N/27YqvC5JOS0ArnWt+D4u+CHeW2N9s5c6OSocxECjEqVG siEUX40N9V6In6wR1+NJDzPRMZmNrLujlZ0jRIddNihxkp/v0UqrxXSeXFPamg9Aovo/ c3FQ== X-Forwarded-Encrypted: i=1; AJvYcCUEWJPrw/qaDLopzyv+4SgtRTkdPmLgkqNIt/k9tAtLYuaBVUULU/qaXJ2oBg+7POCcjGUAkAQxma3xMGIVz5MV X-Gm-Message-State: AOJu0YxdEeqExPJKlpvdi02zMkoywNVjKsK0lN7rVR+a/G2ON/dC+Mix SpIOXklPrOYbIuie34r0ryX90qZ+5Nhdj+Z7/ZVb0ILjrylAjUCmfoGrzp0eDr4vLBxyuL77UNg 2B9GiFYzK622jNbZL5yyjvKuC8zikEMPp X-Google-Smtp-Source: AGHT+IEGco1Ex6lawunqCanOAC2IUskdbwuhF99YoSW5P+YanXN1xHqJ+NUkJCFDSlbVf0+zsLzucQqvVBAWe/GSUgo= X-Received: by 2002:a05:6602:2b09:b0:7fc:923f:255b with SMTP id ca18e2360f4ac-81f71da0188mr28621239f.16.1721767040058; Tue, 23 Jul 2024 13:37:20 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> In-Reply-To: From: Ed Maste Date: Tue, 23 Jul 2024 16:37:08 -0400 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: Shawn Webb Cc: John Baldwin , arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WT88d5rlKz4Kck On Tue, 23 Jul 2024 at 16:08, Shawn Webb wrote: > > It would make sense to me to default MK_CLEAN=no in release branches. > Perhaps stable branches, too. While I don't hold a strong opinion on > the matter, I would prefer MK_CLEAN=yes to remain the default on the > main branch. > > I can't give tangible examples, but I remember running into weird > issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in > main. I probably should do a better job at documenting those > (infrequent) issues when they arise. Issues do arise on occasion, and there are some known deficiencies in our standard infrastructure with respect to dependencies. Have a look at tools/build/depend-cleanup.sh for some special cases to handle no-clean builds. We need to get better at making sure these are consistently added for new cases. Our assumption should be that non-clean builds are generally expected to work, on an ongoing basis. There may be rare cases where it is too awkward to add a special case. If that happens we should just have the build perform a full clean if we can detect the failing condition, or give a heads-up on mailing lists that a clean build will be required. We need to guarantee that release artifacts aren't affected by incremental build contamination, of course -- but that is (needs to be) done by the release build process starting with a fresh checkout, rather than relying on a clean step built into the default target. If you do run into a problem with an incremental build please follow up on the mailing list (or in a PR) so that it can be added to the special case script. From nobody Tue Jul 23 21:29:12 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT9JV0pJ8z5Qxc5 for ; Tue, 23 Jul 2024 21:29:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT9JV02Zvz4RsT; Tue, 23 Jul 2024 21:29:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721770154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=khwCl3zSBODlwkTAQXy1egKOtsOtPn1RjnO7RzOt2t8=; b=eL4Y8xaMLENFzvHhcnAmorWkaYr+ufb4c5xV6Uu0mw7r/IRbghW2DZdW0RhjyrX+dDplYs uc/wKrHm/LapiAO0uYPdSRGLHj/nv22YGIlQFmb5yOgu//ApeSW7UZX53vDk7BBY09Ad0T ht22D1FZngKfgEVlY3Cti5LLBbyhRiH5FRqGzZf1NrQuTzgHORWQiae6Rk7GXOv8Jl3Clp 6gRjZwsqdBCN8hxa/JcmbyRicqgzQGSmw13fy1uyXC0hNTuRRqChq4dS56AGFRrprJf9LF lxDYF75Z5A/YEJEHn5xB2/SNtiVLG91URGuP+sQ03o0OoqlvR65mXaPGDHQzYA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721770154; a=rsa-sha256; cv=none; b=Qk75/QD9pwgvHJUzdoOd7Xkn4vGWKU+ubmcCJPRbgdJAEHDRUDdIn53ITx0clcZhdM3wdA wqVutWZ54oM0x3Jetz9tbQaBHXaIdZhr6Nm1HkAGW3WqQLNwUrpi1csBrSATcbCtOkTfFW 7RawBLEPjGfDvMqMLxLbA8hjL+7i9r/iM8+HaQ+PePmVjfez6xY6DkwyKtUhVrtAhRlww+ Nom6WaJPJhV30PZ9Lun16MuowsBflBw/hrKSqkjKQ0OnR3FLn8e/rWSh/jHt8iT9fgRy1x wi6PdGL+q7+3nkyUN2nAUt2DA/hlPcafi44xA88skB5azeC0Edd6dTtzwkGKvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721770154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=khwCl3zSBODlwkTAQXy1egKOtsOtPn1RjnO7RzOt2t8=; b=P83LcSwc+1Z7JE0sl4QN1pXRHKbwe8jvaUrhRk0fPk39apHlIGhWuPiyfd+QfYV7og8KAr aN0UKkkVyoshD1FkFd0XJvbSQf/9XXF8qqvlg3/+V3fK2jX50DTK5JMJ72wi7lwAEfULQ3 ua+4KOXsChnPawnjfwyy0U04Cs/b1REOgZ5lahrRtr94LVlo8d5MQXrY3AZMeUkrkFMMEN evrN76YYZYB4cs2mItIFFVhrRw9FTKw1nsXrwAKG1mTcUaLKO6oHXTcHNOiD9cxZbvTo2y ZFAa98wJTyYU62r+fA9RARJdB1hjxwQBplNnU8klvLefl1houmyZdGDrk5xM3Q== Received: from [IPV6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76] (unknown [IPv6:2601:5c0:4200:b830:1c6f:3b0e:485e:1a76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WT9JT5l8XzHXL; Tue, 23 Jul 2024 21:29:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> Date: Tue, 23 Jul 2024 17:29:12 -0400 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Default NO_CLEAN=yes in 15+ Content-Language: en-US To: Shawn Webb Cc: arch@freebsd.org References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/23/24 16:08, Shawn Webb wrote: > On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: >> The buildworld and buildkernel targets include a "clean" step before building >> objects dating back before my time to 'make world' (I haven't looked to see >> how far back it goes). To permit incremental builds, this step can be skipped >> via NO_CLEAN=yes. This step is a bit unusual in build systems however. Most >> build systems have separate commands for building vs cleaning (e.g. 'make all' >> vs 'make clean') and over time FreeBSD's build system has gained dedicated >> clean targets as well (cleanworld and cleankernel). For myself, I always >> use NO_CLEAN=yes when building worlds and kernels. If I need a clean build >> I use the dedicated clean targets (e.g. cleanworld) first. In particular, >> cleanworld/cleankernel are far more efficient since they use a single >> recursive 'rm' whereas the "clean" step involves a full tree walk with >> nested make invocations of the 'cleandir' target. >> >> A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a >> WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To preserve >> existing behavior this knob currently defaults to on, but I know Ed's goal >> was to eventually flip the default so that NO_CLEAN builds would be the >> default. I would like us to do that starting in 15. > > It would make sense to me to default MK_CLEAN=no in release branches. > Perhaps stable branches, too. While I don't hold a strong opinion on > the matter, I would prefer MK_CLEAN=yes to remain the default on the > main branch. > > I can't give tangible examples, but I remember running into weird > issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in > main. I probably should do a better job at documenting those > (infrequent) issues when they arise. To be clear, the suggestion is that when you hit an issue, just run 'make cleanworld' rather than relying on the omission of NO_CLEAN=yes to do this for you (and much slower at that). Have you used any other build systems where 'make' does an implicit 'make clean' before it builds? I have never encountered another where this is true. 'clean' is always a separate target from 'all' in my experience. -- John Baldwin From nobody Tue Jul 23 21:46:01 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WT9h73Ryqz5R0QF for ; Tue, 23 Jul 2024 21:46:15 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WT9h669W9z4VhY for ; Tue, 23 Jul 2024 21:46:14 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-e05ed8a5526so5840224276.3 for ; Tue, 23 Jul 2024 14:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1721771174; x=1722375974; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dUJpEyV2M1CksJFPT3rpRgH8Ohd2yO/5F9xO9zqTybo=; b=e2k4cxGr3vY7fmXynhCXroHNCBKjt81O+w/b4Nrlu/sIHRJvKFgaVo1SScV4GxcBS/ 2VJ6O8gyuRnhU1qhx4DNBlZMY3ZDizpdJCFFEgCS5IjrdM7RkZQ6gzDHhxFP3oKaV94e 3IU6e5sVnxnh1aLOZPMsDCOhX/DVA/Jfd0t2+cXFgRYQaodPK2IK1Mo4aQEiAvwaEJLD qz3kLUGfypK5KmeNsa8CXohVrHN/19L68lLDOr08M22e8rtUoulpmoVIE3D1yXrPWtEN gJpvD6HbriSFk5acjsDaUsUtXYzem6hDQ2QPCZhPvpJl4wuZtu/lgv+h7y85wv+n9r+J R2Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721771174; x=1722375974; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dUJpEyV2M1CksJFPT3rpRgH8Ohd2yO/5F9xO9zqTybo=; b=pNa5OUzIZzTqDueJq0bZMQB3MYv8FKTORVxAhxjg1jLQLKNXx6mQB34Cb/gGoqveIi sThvZtsjdYGKCQ6JKdasHEKq3e9HikWdQg3DgedXdbVh3wP0mEbBJZlCDvAYsauhjOKf IO7C3V2y3w0OKkbjohCleqzkjCDt+XpZoDaDnf9x2biN0btD75TW/5MIExU0u7Wo7fAE myH9S8sfmVqyj7s3CZD9vO8//zKYEpycVgPFXxhc+PhssNN10HRc1hd3MZbfpmLniC85 XOt/IdTeujelz1y8OLZE5HvgWKDiAG7LcqztlbF/u4aZiRJlCBpHBoTCBOl43K7gMJSY xkCA== X-Gm-Message-State: AOJu0YyhUxWwVQYzGnWCE0mbh164odfIYZjpVaWr8Ltqi3CLwuMsPhbO WmfUWrs9I2dO8LmI5bAeOfXOwMWEc2q7qQxg2Z/IKeFrIcT91xgMVQ1Yl8b8sQ== X-Google-Smtp-Source: AGHT+IEUaSkhyER7T9xIrDVBGAovtO1u4tLwp3MyPalc3iinoAbY/j6PEDS699mNZEOalRwksbSHGg== X-Received: by 2002:a05:6902:1202:b0:e02:b5cf:97ac with SMTP id 3f1490d57ef6-e0b0e37e16amr459227276.3.1721771173793; Tue, 23 Jul 2024 14:46:13 -0700 (PDT) Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com. [209.85.128.175]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e0b0eb32552sm43182276.44.2024.07.23.14.46.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jul 2024 14:46:13 -0700 (PDT) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-65fdfd7b3deso60356657b3.0; Tue, 23 Jul 2024 14:46:13 -0700 (PDT) X-Received: by 2002:a05:690c:2e0d:b0:65f:86a2:b4c5 with SMTP id 00721157ae682-6727ce1e0dcmr2634477b3.31.1721771172605; Tue, 23 Jul 2024 14:46:12 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> From: Tomek CEDRO Date: Tue, 23 Jul 2024 23:46:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: John Baldwin Cc: arch@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WT9h669W9z4VhY On Tue, Jul 23, 2024 at 9:58=E2=80=AFPM John Baldwin wrot= e: > > The buildworld and buildkernel targets include a "clean" step before buil= ding > objects dating back before my time to 'make world' (I haven't looked to s= ee > how far back it goes). To permit incremental builds, this step can be sk= ipped > via NO_CLEAN=3Dyes. This step is a bit unusual in build systems however.= Most > build systems have separate commands for building vs cleaning (e.g. 'make= all' > vs 'make clean') and over time FreeBSD's build system has gained dedicate= d > clean targets as well (cleanworld and cleankernel). For myself, I always > use NO_CLEAN=3Dyes when building worlds and kernels. If I need a clean b= uild > I use the dedicated clean targets (e.g. cleanworld) first. In particular= , > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. > > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To pre= serve > existing behavior this knob currently defaults to on, but I know Ed's goa= l > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. > > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x. Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do this > already. > > -- > John Baldwin +1 :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Jul 24 05:11:02 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WTMYP3wccz5RCHN for ; Wed, 24 Jul 2024 05:11:05 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTMYP1XK2z58j0; Wed, 24 Jul 2024 05:11:05 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721797865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZxMK2nn50h9Q+Kf76/VIRtLghQwXBu6wyXgp6KWM6dg=; b=oDaRAoJZzkvSHsyRNpcBMAKvJcwsA/KxRbgQBqIrHF27ouPdSOFmq4wxowzHN2KrR60kIj q7sdYa28U6DqZ8gp15kLiTE547EHHNVqwVuEc6hIZLquTU+EZSjXMN35zgefxMe7vt8sg1 XfBaXF7GEroqsTaXanRvxGfPUKiUqwB6q53G/GtAgOrtvnXlPgouuZvq/V/kU5Dmb3HcFb O37OiXo6RhzeJMF44MvHworedUeQmj1sPA0iCj8frWPORYwtyBNJs+YEiTUBvv4jwyPPE9 2veKrV+dV15eXzKgpAeWFrgwD9R3U5RQrYVAUL27kejEsOK4z+9v8b1jyMlSAQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721797865; a=rsa-sha256; cv=none; b=CURSgAAVQBeeoQPh7CDT+JKk7zvhQ+8pV5lGcclQr2rkXPgrUt0p8NyR8b/5Ef6kTC9AiD 0sKQO+efA47yj2IA8DYaS78yQHh2WqYPfONmc93ZZ2gwkC9+cZYsrn/dJtOxUNTcENZO7P SA4g/dr1rtt8/NpbF2/1LcKBC8apgYhR3t91cy+IvVrzfUD7Jqu6C2PCAWQ6fBTWvz2PIT UWNeOhKjqPvQszrxfvmA9QdjtNodPWaA5FAVmvGNluZnn4LTBBE27EOFss9nO9jS1cgkf4 Q7hPes3Kz9tebBtq6s1IT7Ecyxh2uExUqD36AZsufbACOqD2gotMBH4SgxuHMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721797865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZxMK2nn50h9Q+Kf76/VIRtLghQwXBu6wyXgp6KWM6dg=; b=GSJn/se8n2f489Jsu5clPmp1SbvbqbfdleNLrjP2hQV8zWLCgZxC1zzwfzHadH67cGI/7F JQPDjm5HZt/oogOlGd8YFBIl0HtXwkMkwhNzduEJmcC3h+P71+17hiZSVGBGz/GLOH5Ul2 3+Z9babZboZ41qbm7yOrF8TQi7ODENytIVQswAQG1utWNDzmXTYmKJTxwaX/HleMftSrnu 603soA15trx5ykK51dUJC9Z87yOdqmeoGXPowGnx2ED9FFGc3iME0R0i64c+mlEX9Hfb4m aLvKSwsenuNRCBTd9gSc3T0A3LwmESlvPda7JmBzJb0hh5wXYoicTE8zCfN+3A== Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:386:9c20:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WTMYP0Z8zzRZp; Wed, 24 Jul 2024 05:11:05 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id ECC8910239; Wed, 24 Jul 2024 07:11:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Default NO_CLEAN=yes in 15+ In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> (John Baldwin's message of "Tue, 23 Jul 2024 15:58:13 -0400") References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 24 Jul 2024 07:11:02 +0200 Message-ID: <86msm72x3t.fsf@ltc.des.dev> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Baldwin writes: > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To pre= serve > existing behavior this knob currently defaults to on, but I know Ed's goal > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. It already defaults to off (since 473fda75dd6cf in 2016) if you have filemon(4) loaded and meta mode is not explicitly disabled. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Jul 24 07:31:23 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WTQgb5gvYz5RR2L for ; Wed, 24 Jul 2024 07:31:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTQgZ4930z46j2 for ; Wed, 24 Jul 2024 07:31:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hBknCPuj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721806297; bh=vlfF7A9taAYz++MPHzxaA2MlxBwpY70BDvUe/eqWHIg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hBknCPujd9SrN+LF+QlB2ZOlGNjIcnVl0oqwwqyYF+9SDo5GdysbX7rKPl8F4qF+I8Ua1ETNPMS20W+ci6+mw3prYpOt23WAnRXk+lKJ6Y346n4/Ifro6ZcUYAKmIy1LFSw2kvMqI6V5jX5xI0S8BLxd44kuOqFVl8mv9ZOlvMAES1zISS/Ml5P7/8/2w69e8rk5fIOguGGisSQvUUzWmjZVgZ12mpqRhzpBH8qNxcTuh8c1hcBCGIWEOHtpyJM1XsVtnhwkDEhu/pp6Nhg6efNZQo2ADjqE0P9zgI6doKJK6dVSyErUB82/H/0m/GY0AyaG70ezKPjHiM60po9Tow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721806297; bh=SOaHb5TK1xo7VwfS/RvyKNw5v+sxxzQ+A/IS9Zm2Y87=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=n/InIu3PvK0//nznzvhmItYYMvQ9mkTUprLrRDGmcQ4vUAElX7kMZ12BBe0p6Vvne4rQcQCsVIRVx7E4+8iGXMPm48jyvWkW6E3l9QYzR+pxnyc7I7pqCnDdid9DVORuRQCRDqkT30Ia2W2BijCanSFkSMwDaZoKczG1PLz/FrrhspF4WKcAlNLBiOgyPX0mJe9yTdr0Z0YSUApUUyG7/Wr3g0piKDlVG/U2yg1qMmT7mRqnMl4DovWJuxpvYhvOiMSCd6MNsvZFNcqLIoGM7wTG1pszqcZpT56ouggZW1NreKuG2GZ0I7hmn/VtJZLkeW0pz0M/T8LI3v/JkaE0wg== X-YMail-OSG: 7fl0MpsVM1loIMvxhcOvy88r3t6Bntf52_i_zXWpAXZAtfEiIpiTMqastxRPNvY TLAD0WB4SoWyn8UrP2oCFLbNVIB0DvN6oj9zlXJpfh2JPp2T4OXbw5FSrLZIR.YnAvAxhHd4Hd.Y FX2CJS29Bg.Eg4vREIHQevNkrUSjDAVf3xeC76Z1rzzrApCob5Q9ujYqkUQ.bMe2513NgaUDmej0 DxEqz0BDBiMIOLfEJUelAB_AmerasY3btAWgT_7a7Y5G5yYjlIyGCo7sGdnsPtMnOMdErjFb0Jts ryrHbve6d00t5ariceWjdZUVMH7ngzWFlhTW86bDcQVJq_8doc3gRMz6cMkqBhbWZrIN8eKAHZP8 tpRw1s19669kUDI7L8HR04A3pQI8qKKo0HYMrLYGrFqYGhcU3giDOsDu_ubHEjrxsBLKfz2x1M6u niF.mM5nyilcduH62E1RLaAQCMTWZgAc4nsMxEGRUns5vuCIjIID3p.0qd90xkUzl9sApfWipYHs cLc19qISqT83kfeyaGF2tnM3YqiSMfgOg9qYkFPP7KdZGSKPcF0fWg8_cfuje7leZxp5QSLzgT0R GZuDCCV6zQ7TLP1HWVVnyQlE1.XKwOEnMXY0xeJkNgYjKO5oS.nugYQeFJlWGxF2MSqEJxHr_jQ3 nr4Y.56P8dxKncEOcoUs3dKAtls9l2XaFGWepGXRqbaZz2iAj8y22wlrZyiRSWo_wf03J7kU5599 vm4WWlTdQr1.HyYSdRV3xuP5hta_OMmLsvq6OekoH6x4RaNGJKMCvXXEWtF_0BIqlCn4jlfmx818 WtTEv1glfnM2zxUOFR.BcH7utFtVowbxRIIZF.j71uSa2oQOgwP0kSd3Q3CAHAUgZQ.VuGhcgk9J GOKMYfFEdwFptal7oMEJlevnQzAUpdSSamyll2UOko_jI3cfs6jlAAx8MggCMdeAKrXQmLppi4FJ _56tO_ey3V4Gtdtd5slcZfPYFFA1kEmEWsWaNq9eSRKRYd4HnG4JK48NcjYMnKNIR8oXd82HGf.O uICvhXAbJqiucfqOGqeHuURSm6.1iq5IgeRxWwY.l0CRnF.Dbk0ZVUwSqW5QMc6zk7V1l3S4RRL8 CbR.qSoQZkrGjY5JEnu9KMpA9PQTDswtu2cdkSYMtMTRpnxlcLIDj0cwGrl3woGefiICvE3kJm25 l0VcchwrfdUPwPwOZ8sLKHgEIMRGtMSLcdY8wDvndQgfXjk2bpHGzDlxlZr13TTUQRUIPeYw3A_g aWHo3bbxAnlOqcEbnJuzCxGV7Wg.Fiw_HspmVoXjUu9ovzfhPMsR2sIYmqr8MOis6AeitEDM3Vr6 5YWqu9bftx57YZ6yUS1ZRY1Vkiz.CD34LMWB0.AjfFZGZ9RPt2zA3hy9WxqqeRVSOkrP30eVO0uM BggwTvOd1ORPXuUCTSwNLKG.deLGUIL7038VZGUXqBtCHWOBYEsEQSfRtv9yev1tOTymbxmXS0Li ix.hcZ3xKVirZ9ITRUHdYdtizA_8rpvYahMvrfYHGnuWr28LHtmgzLkzyvyqZHLy0cprFHvi3_xw T7HoOwLn4unebw3pn90LE_N7jCdUGWqxxdbh0IUPfN1gQY7ps6HI0bi2PfDL3tzlAH_b_hBlQdxf vErQMWKE6IWw8XKVUeZwM9I1gTqds_ljy4fxsCcSbgoRK2F_JwSJN9wXPXS9BXUsJWpm54T298vZ 959m7UxPAV_oLntDPJ2d_m.GFDY1PMO1xn1bMBqBg.v3ovMzsoc63LGWNpBHgEUPD96tp.PdUhl9 ACL2KDnAJtJRMlo4Y1xPlKCLuYsXFRDbSH5yGmUNrG8lSXxgA4iYWKRh5eKqzy82Vgtssdiokvwo p3biBjzZp6Tje8MLwKqQ04URPiNum1P7OC8Mhi14ebSUa12Hoi8bFB3E9XKSEYkhl7EHKGTKYdMO fHQwY66XiIZS_P4soi6W42C_YwD1POW_JN9LnBY5dZVv5Dc1blSX9j6zup5dxJyNQNsv0N3VvWJL 4eI90nkqWnc7zzsQetUYmj.JXw1O5pcjZN6OA15rfHYPhuc_Of40Tp7lrT5R4x_KXT53mf_RzL7f lxWoeVjDm3SWTNOIZ2en4BkRsYSk29yLBCP_WA5LeyZ0hbOZGXlAhRE_ESnmy6cBNuLVjh4mFwM7 1Lc4CwxPOG6VqUa3s9Z12E3RB5Lvtz6PbhsxxLxpPRDr.nL5XYwhbzBcIzMZ2bGTVPfiUHjpHbyr Cy9ajXzwCx.VtI982WLUDW9MIPDVb0qKtioIBhPvstFH5S3D3du_m2PZfxR0zP_uULD9r25jt X-Sonic-MF: X-Sonic-ID: 00141bab-f419-4fbe-848d-794b2f8351f4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 24 Jul 2024 07:31:37 +0000 Received: by hermes--production-gq1-799bb7c8cf-9xr4w (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 85b637d3fdf409c6389bd908e96eb27e; Wed, 24 Jul 2024 07:31:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: RE: Default NO_CLEAN=yes in 15+ Message-Id: <2BB28579-7C7B-4268-B3C6-BD8E11233CE7@yahoo.com> Date: Wed, 24 Jul 2024 00:31:23 -0700 To: John Baldwin , freebsd-arch X-Mailer: Apple Mail (2.3774.600.62) References: <2BB28579-7C7B-4268-B3C6-BD8E11233CE7.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.688]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4WTQgZ4930z46j2 John Baldwin wrote on Date: Tue, 23 Jul 2024 19:58:13 UTC : > The buildworld and buildkernel targets include a "clean" step before = building > objects dating back before my time to 'make world' (I haven't looked = to see > how far back it goes). To permit incremental builds, this step can be = skipped > via NO_CLEAN=3Dyes. This step is a bit unusual in build systems = however. Most > build systems have separate commands for building vs cleaning (e.g. = 'make all' > vs 'make clean') and over time FreeBSD's build system has gained = dedicated > clean targets as well (cleanworld and cleankernel). For myself, I = always > use NO_CLEAN=3Dyes when building worlds and kernels. If I need a clean = build > I use the dedicated clean targets (e.g. cleanworld) first. In = particular, > cleanworld/cleankernel are far more efficient since they use a single > recursive 'rm' whereas the "clean" step involves a full tree walk with > nested make invocations of the 'cleandir' target. >=20 > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as = a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To = preserve > existing behavior this knob currently defaults to on, but I know Ed's = goal > was to eventually flip the default so that NO_CLEAN builds would be = the > default. I would like us to do that starting in 15. >=20 > Further off, I would suggest that we remove the "clean" step outright, > perhaps in 16.x. Regardless, we will need to update documentation to > prefer the clean targets over WITH_CLEAN=3Dyes if our docs do not do = this > already. I use META_MODE and do not explicitly control NO_CLEAN. Any implications for META_MODE for this change? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jul 24 08:44:39 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WTSJ40trTz5RXgf for ; Wed, 24 Jul 2024 08:44:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTSJ33v5Jz4GLk; Wed, 24 Jul 2024 08:44:51 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 46O8ids6007428; Wed, 24 Jul 2024 17:44:40 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1721810681; bh=+SoaoI2NauKQ2td1nWj8TkmGoTpjZLIv7pNx+GUYr+k=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=b4RpBG9oOQ0XqRPGFKP3hKj4+2vbONyn6bHC7zzSSDTY6JHzDCYMRB5bWe0X1d3vb 4AgkyOS6TNG0XDfp8NjlDF/srKuWb16pJ6CbVWuJWsNV9NuIinlbepf6J680jzuF2k v1FoYbMWMAjfeGK+HjoRdFdQXDFdJbllJJZEXyI8= Date: Wed, 24 Jul 2024 17:44:39 +0900 From: Tomoaki AOKI To: John Baldwin Cc: Shawn Webb , arch@freebsd.org Subject: Re: Default NO_CLEAN=yes in 15+ Message-Id: <20240724174439.2384fae6b9bb17760d04fbfd@dec.sakura.ne.jp> In-Reply-To: <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4WTSJ33v5Jz4GLk On Tue, 23 Jul 2024 17:29:12 -0400 John Baldwin wrote: > On 7/23/24 16:08, Shawn Webb wrote: > > On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: > >> The buildworld and buildkernel targets include a "clean" step before building > >> objects dating back before my time to 'make world' (I haven't looked to see > >> how far back it goes). To permit incremental builds, this step can be skipped > >> via NO_CLEAN=yes. This step is a bit unusual in build systems however. Most > >> build systems have separate commands for building vs cleaning (e.g. 'make all' > >> vs 'make clean') and over time FreeBSD's build system has gained dedicated > >> clean targets as well (cleanworld and cleankernel). For myself, I always > >> use NO_CLEAN=yes when building worlds and kernels. If I need a clean build > >> I use the dedicated clean targets (e.g. cleanworld) first. In particular, > >> cleanworld/cleankernel are far more efficient since they use a single > >> recursive 'rm' whereas the "clean" step involves a full tree walk with > >> nested make invocations of the 'cleandir' target. > >> > >> A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > >> WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To preserve > >> existing behavior this knob currently defaults to on, but I know Ed's goal > >> was to eventually flip the default so that NO_CLEAN builds would be the > >> default. I would like us to do that starting in 15. > > > > It would make sense to me to default MK_CLEAN=no in release branches. > > Perhaps stable branches, too. While I don't hold a strong opinion on > > the matter, I would prefer MK_CLEAN=yes to remain the default on the > > main branch. > > > > I can't give tangible examples, but I remember running into weird > > issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in > > main. I probably should do a better job at documenting those > > (infrequent) issues when they arise. > > To be clear, the suggestion is that when you hit an issue, just run > 'make cleanworld' rather than relying on the omission of NO_CLEAN=yes > to do this for you (and much slower at that). Have you used any other > build systems where 'make' does an implicit 'make clean' before it > builds? I have never encountered another where this is true. 'clean' is > always a separate target from 'all' in my experience. > > -- > John Baldwin +1. And IIRC, *.meta remains after cleanworld / cleankernel on META_MODE builds. If I'm correct, it should be properly cleaned, too. -- Tomoaki AOKI From nobody Wed Jul 24 14:33:41 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WTc2d2mW9z5S3RL for ; Wed, 24 Jul 2024 14:33:45 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTc2d1D69z4v5g; Wed, 24 Jul 2024 14:33:45 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721831625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aZ34eXulBp8gZO08Xr91T0Y30umf0zQs1zascuqjJ+Y=; b=vzg1WH69ZtRv1L8UsNQ587HApHwHIBZEYpl9xbfeEeAE5t+T+nDTI6yzelm5elP8lKgx67 UWZbcea4o+IqvHjY3Y5bq+3yhj6ja0ban00fJwDEqpYEE9OElwjH/aW1IMlwl1EH0NT8YS dtgWcJoQ98MHsi3dy0HajiPNLj+gj0Pu/7hzTfPuQ5IbFmlMqHZbhhx/nJhY6pOxeXzZui n8FixCmS3YoQKcz/eQirG5EKC705GhIXmgmgS5imjLKpF9Bg7k6HO+fVN+eX3j4NR+dUZX Mo5EBYMgd7CAfQuT/HsiDJZ/MKdwZQDvSU1R5bQBI0PG4GsMGi5Od6WWgPaO9w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721831625; a=rsa-sha256; cv=none; b=qLdOB5Ymzt/46k44TkgMA6tyEnfXflPN7sANDR/QZiw/O/AbyFUf0L/w4ZqHaQ1y1h7y6J ErgPBnMeUsN1wOFh/2GMQbpHjkIUSEicJVayDgyS7k7Thz3vOsqSssERXz/J7cPpaI6OlF xr5ARlyfKicPAjDxaircnhpKQdlarHgUm0KWXQ8B3Y/17fj4bt6m/qaQkS+lvjo0NEo1Ld ZPMxKeto1Z5b5awAGYH07AgOWfpKt6PiM2OjjLkjyLSVnWCOEGbf0tKX+FRpZZukUAyTTl eJzWFtS+gk6OC3gdAri4H8gFAAHShWrXPwjj6gd8PFnOQrcb2UTE2A0NQalfNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721831625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aZ34eXulBp8gZO08Xr91T0Y30umf0zQs1zascuqjJ+Y=; b=l+fAXUIJRbTPXaM/ihKK8j7ODxkXCnMCBTo9ydZLK2yBfMi3NkhmBx4naB+yNthqJu8Dvg ucE15r9gdai748YNT4n5sOOOeWuXiqoYlRkCFJ04+S4eu0EHZrjnV9URdz1nuqftReElE8 EHFywNTkxLUbE3Gp7h4m+wykXPtJ+Vuk08CU+RbOC1du462tbokQrJCrwYR6tsK4HiP7Gj ot9rEyb0ooJn1X2zXKgvfIpV/9AsJrGpb/JL6W2I2KjNgfSkuHSSPX8xoLHfCp7QpvS9ba hKHIv3uJ1wekxCRP0tFYRU5olrRAcEnPmNfySqQnKxIZndxKivBMqH95yc7IzA== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WTc2c6y7Qzf31; Wed, 24 Jul 2024 14:33:44 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 3181EA64806; Wed, 24 Jul 2024 14:33:42 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 27E772D029D8; Wed, 24 Jul 2024 14:33:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id pCgF0qoLds8I; Wed, 24 Jul 2024 14:33:42 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C6D782D029D2; Wed, 24 Jul 2024 14:33:41 +0000 (UTC) Date: Wed, 24 Jul 2024 14:33:41 +0000 (UTC) From: "Bjoern A. Zeeb" To: John Baldwin cc: arch@freebsd.org Subject: Re: Default NO_CLEAN=yes in 15+ In-Reply-To: <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> Message-ID: References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Tue, 23 Jul 2024, John Baldwin wrote: > On 7/23/24 16:08, Shawn Webb wrote: >> On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: >>> The buildworld and buildkernel targets include a "clean" step before >>> building >>> objects dating back before my time to 'make world' (I haven't looked to >>> see >>> how far back it goes). To permit incremental builds, this step can be >>> skipped >>> via NO_CLEAN=yes. This step is a bit unusual in build systems however. >>> Most >>> build systems have separate commands for building vs cleaning (e.g. 'make >>> all' >>> vs 'make clean') and over time FreeBSD's build system has gained dedicated >>> clean targets as well (cleanworld and cleankernel). For myself, I always >>> use NO_CLEAN=yes when building worlds and kernels. If I need a clean >>> build >>> I use the dedicated clean targets (e.g. cleanworld) first. In particular, >>> cleanworld/cleankernel are far more efficient since they use a single >>> recursive 'rm' whereas the "clean" step involves a full tree walk with >>> nested make invocations of the 'cleandir' target. >>> >>> A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a >>> WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To >>> preserve >>> existing behavior this knob currently defaults to on, but I know Ed's goal >>> was to eventually flip the default so that NO_CLEAN builds would be the >>> default. I would like us to do that starting in 15. >> >> It would make sense to me to default MK_CLEAN=no in release branches. >> Perhaps stable branches, too. While I don't hold a strong opinion on >> the matter, I would prefer MK_CLEAN=yes to remain the default on the >> main branch. >> >> I can't give tangible examples, but I remember running into weird >> issues occasionally when using `make buildworld WITHOUT_CLEAN=yes` in >> main. I probably should do a better job at documenting those >> (infrequent) issues when they arise. > > To be clear, the suggestion is that when you hit an issue, just run > 'make cleanworld' rather than relying on the omission of NO_CLEAN=yes > to do this for you (and much slower at that). Have you used any other > build systems where 'make' does an implicit 'make clean' before it > builds? I have never encountered another where this is true. 'clean' is > always a separate target from 'all' in my experience. Can we (if not in 15 but then in 16) simply: (1) document clean builds as make cleanblah .. && make blah (2) document that if we do not run make cleanblah we'll get an incremental build (3) if an incremental build fails (CI will detect as well) -- do as Ed said (4) make sure re and so are aware of the extra make cleanblah needed? (5) remove NO_CLEAN and MK_CLEAN entirely (there's no point in flipping the default if you can choose to run a make step or not)? I think that is basically your suggestion? +101 for that from here. /bz -- Bjoern A. Zeeb r15:7 From nobody Wed Jul 24 14:56:41 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WTcYM4MDQz5S5bn for ; Wed, 24 Jul 2024 14:56:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WTcYM2VQVz3xtq for ; Wed, 24 Jul 2024 14:56:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2cb55418470so3654926a91.1 for ; Wed, 24 Jul 2024 07:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721833014; x=1722437814; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eU6kjgV5jd+CUR7tlJmA52G1a9SmZqygOM98E5hWGhY=; b=xVDxIUZ0iJtjy+YXtSMu5zZIB4c2v8iNGzWiV3i73KW5Ao+Q+x+zQfsNzq+mhmOewJ OWTUuKjQk8UO4ifLitOXB0m9KdMWj3T5ikJCgTfgVnYHecQhCbQ/3OcK3uPZLObxjRGi IwkDdTj2uVkMO85UzL9JO2B/T5qSMcpuADHUIWzpxgVxJKOs6+A1JrDsXYa+e0852jXb A3cU1VoxutPyknb1h6mfxBLiIOz1b1qNH79MDIsXu3atJRdrpP9yIPBACcKgvoLm/zIw eHTyyX3p2QL69KOBJzDyQeaoYi/qhWRzKWWtTL7RympXznpLZTBrbu/e2JpvDzg+3vuY HQjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721833014; x=1722437814; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eU6kjgV5jd+CUR7tlJmA52G1a9SmZqygOM98E5hWGhY=; b=aHDrk1jVXT1BkMR5zPIMk5eQQpIPev3T0R1Ej4Jl7crdl7cIIDeENcaO2qXbDocTCW N4J62l2tp2WKarXLqthmJvIZ7ZMauKXHKOICG3Cy6j2pC91i0YJuWbppoSJWB5Izfw1n Bn/knTpJ4Y00l9/9xoHTidtKY0Bdv64vo9ju2Hjp06FnIy/lkMLSHbmEjgnOwmdWsaY5 Qa1hN3DqYghqYtcY+ude3DJLT/vDcodLGEAaQfo7BOT+pMOZWyqB14R0nIe4v13T4//0 M1QwFA2AkZ8Kple+bZ5nDUD7i1djne2XZPDt5UABzxivUwVOosNuV4H7TgfGJV9lv1QS vBdQ== X-Forwarded-Encrypted: i=1; AJvYcCUQF1E2l2vw6gwv1V3tX8FCuo1MpCzvXXSFO9YmoamTRxozkph2hoyVvrZiaFiZ8oNwNqt70r1JRHDBc9MQpPwo X-Gm-Message-State: AOJu0YxyR/6RsEF5hlO3nQKhPZ1wyZEvAQAHQOkbBH7c0ziT1nbVF0RH +hZAFsD0iHIqciXz6ub9i8KQkRdtTd32n0f0bAqD0udv3WWIGo+Z6HJ7pYm0c2h8UCBSnXq0+15 6NUHvxJ6WBWmjefNBmnyMjqHyUwmsP69V2b7Ame2Iv83miyyx X-Google-Smtp-Source: AGHT+IEWrLFllaZJeZTxdFWorb/J3FW4ktVt801aU6pgNcMKs5opMm7oLN5e0LhixT+2qIruDf/ZYvBS9JhuSfJ18SU= X-Received: by 2002:a17:90a:4889:b0:2cb:4c06:8f11 with SMTP id 98e67ed59e1d1-2cdae472535mr3371703a91.22.1721833013614; Wed, 24 Jul 2024 07:56:53 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> <71d28fd9-7679-4aaa-981e-81fa70c5da71@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Wed, 24 Jul 2024 08:56:41 -0600 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: "Bjoern A. Zeeb" Cc: John Baldwin , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000023b8ea061dff7d3a" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WTcYM2VQVz3xtq --00000000000023b8ea061dff7d3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2024, 8:33=E2=80=AFAM Bjoern A. Zeeb wrote= : > On Tue, 23 Jul 2024, John Baldwin wrote: > > > On 7/23/24 16:08, Shawn Webb wrote: > >> On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote: > >>> The buildworld and buildkernel targets include a "clean" step before > >>> building > >>> objects dating back before my time to 'make world' (I haven't looked > to > >>> see > >>> how far back it goes). To permit incremental builds, this step can b= e > >>> skipped > >>> via NO_CLEAN=3Dyes. This step is a bit unusual in build systems > however. > >>> Most > >>> build systems have separate commands for building vs cleaning (e.g. > 'make > >>> all' > >>> vs 'make clean') and over time FreeBSD's build system has gained > dedicated > >>> clean targets as well (cleanworld and cleankernel). For myself, I > always > >>> use NO_CLEAN=3Dyes when building worlds and kernels. If I need a cle= an > >>> build > >>> I use the dedicated clean targets (e.g. cleanworld) first. In > particular, > >>> cleanworld/cleankernel are far more efficient since they use a single > >>> recursive 'rm' whereas the "clean" step involves a full tree walk wit= h > >>> nested make invocations of the 'cleandir' target. > >>> > >>> A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to > as a > >>> WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=3Dyes. To > >>> preserve > >>> existing behavior this knob currently defaults to on, but I know Ed's > goal > >>> was to eventually flip the default so that NO_CLEAN builds would be t= he > >>> default. I would like us to do that starting in 15. > >> > >> It would make sense to me to default MK_CLEAN=3Dno in release branches= . > >> Perhaps stable branches, too. While I don't hold a strong opinion on > >> the matter, I would prefer MK_CLEAN=3Dyes to remain the default on the > >> main branch. > >> > >> I can't give tangible examples, but I remember running into weird > >> issues occasionally when using `make buildworld WITHOUT_CLEAN=3Dyes` i= n > >> main. I probably should do a better job at documenting those > >> (infrequent) issues when they arise. > > > > To be clear, the suggestion is that when you hit an issue, just run > > 'make cleanworld' rather than relying on the omission of NO_CLEAN=3Dyes > > to do this for you (and much slower at that). Have you used any other > > build systems where 'make' does an implicit 'make clean' before it > > builds? I have never encountered another where this is true. 'clean' = is > > always a separate target from 'all' in my experience. > > Can we (if not in 15 but then in 16) simply: > > (1) document clean builds as make cleanblah .. && make blah > (2) document that if we do not run make cleanblah we'll get an > incremental build > (3) if an incremental build fails (CI will detect as well) -- do as Ed > said > No. It won't. Or only sometimes. I've had several times when tree A builds just fine whole tree B won't. 90% of the time it is an accumulation of changes that cause B (the older) to fail. The rest of the time it's build settings differences. We can get a lot of it from CI, but we will miss about 10% or so of the issues. There's maybe one breakage in 20 or 30 that will be some kind of judgement call, so we likely should establish sone guidance. Like how old is too old? On current, this is likely 6-9 months. On stable it's likely the branch point for the oldest supported release on the branch (also 6-9 months), though a good case could be made for one additional release prior since the cost is likely small, though the testing logistics get complicated. Likewise for build options. And for everything there's always a "too hard" reset available, though maybe that should be decided with the forthcoming srcmgr of current and maybe with re too for stable. (4) make sure re and so are aware of the extra make cleanblah needed? > They already start with an empty /usr/obj. (5) remove NO_CLEAN and MK_CLEAN entirely (there's no point in flipping > the default if you can choose to run a make step or not)? > > I think that is basically your suggestion? > Basically, yes. Warner +101 for that from here. > > /bz > > -- > Bjoern A. Zeeb r15:7 > > --00000000000023b8ea061dff7d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 24, 2024, 8:33=E2=80=AFAM Bjoern A. Zeeb &= lt;bz@freebsd.org> wrote:
On Tue, 23 Jul 2024, John Baldwin wrote:
> On 7/23/24 16:08, Shawn Webb wrote:
>> On Tue, Jul 23, 2024 at 03:58:13PM -0400, John Baldwin wrote:
>>> The buildworld and buildkernel targets include a "clean&q= uot; step before
>>> building
>>> objects dating back before my time to 'make world' (I = haven't looked to
>>> see
>>> how far back it goes).=C2=A0 To permit incremental builds, thi= s step can be
>>> skipped
>>> via NO_CLEAN=3Dyes.=C2=A0 This step is a bit unusual in build = systems however.
>>> Most
>>> build systems have separate commands for building vs cleaning = (e.g. 'make
>>> all'
>>> vs 'make clean') and over time FreeBSD's build sys= tem has gained dedicated
>>> clean targets as well (cleanworld and cleankernel).=C2=A0 For = myself, I always
>>> use NO_CLEAN=3Dyes when building worlds and kernels.=C2=A0 If = I need a clean
>>> build
>>> I use the dedicated clean targets (e.g. cleanworld) first.=C2= =A0 In particular,
>>> cleanworld/cleankernel are far more efficient since they use a= single
>>> recursive 'rm' whereas the "clean" step invo= lves a full tree walk with
>>> nested make invocations of the 'cleandir' target.
>>>
>>> A few years ago, Ed Maste added a MK_CLEAN option to src= .opts.mk to as a
>>> WITH/WITHOUT knob for the "clean" step similar to NO= _CLEAN=3Dyes.=C2=A0 To
>>> preserve
>>> existing behavior this knob currently defaults to on, but I kn= ow Ed's goal
>>> was to eventually flip the default so that NO_CLEAN builds wou= ld be the
>>> default.=C2=A0 I would like us to do that starting in 15.
>>
>> It would make sense to me to default MK_CLEAN=3Dno in release bran= ches.
>> Perhaps stable branches, too. While I don't hold a strong opin= ion on
>> the matter, I would prefer MK_CLEAN=3Dyes to remain the default on= the
>> main branch.
>>
>> I can't give tangible examples, but I remember running into we= ird
>> issues occasionally when using `make buildworld WITHOUT_CLEAN=3Dye= s` in
>> main. I probably should do a better job at documenting those
>> (infrequent) issues when they arise.
>
> To be clear, the suggestion is that when you hit an issue, just run > 'make cleanworld' rather than relying on the omission of NO_CL= EAN=3Dyes
> to do this for you (and much slower at that).=C2=A0 Have you used any = other
> build systems where 'make' does an implicit 'make clean= 9; before it
> builds?=C2=A0 I have never encountered another where this is true.=C2= =A0 'clean' is
> always a separate target from 'all' in my experience.

Can we (if not in 15 but then in 16) simply:

(1) document clean builds as make cleanblah .. && make blah
(2) document that if we do not run make cleanblah we'll get an
=C2=A0 =C2=A0 =C2=A0incremental build
(3) if an incremental build fails (CI will detect as well) -- do as Ed
=C2=A0 =C2=A0 =C2=A0said

=
No. It won't. Or only= sometimes. I've had several times when tree A builds just fine whole t= ree B won't. 90% of the time it is an accumulation of changes that caus= e B (the older) to fail. The rest of the time it's build settings diffe= rences. We can get a lot of it from CI, but we will miss about 10% or so of= the issues.

There's= maybe one breakage in 20 or 30 that will be some kind of judgement call, s= o we likely should establish sone guidance. Like how old is too old? On cur= rent, this is likely 6-9 months. On stable it's likely the branch point= for the oldest supported release on the branch (also 6-9 months), though a= good case could be made for one additional release prior since the cost is= likely small, though the testing logistics get complicated.=C2=A0

Likewise for build options.

And for everything there'= ;s always a "too hard" reset available,=C2=A0 though maybe that s= hould be decided with the forthcoming srcmgr of current and maybe with re t= oo for stable.



They a= lready start with an empty /usr/obj.

(5) remove NO_CLEAN and MK_CLEAN entirely (there's no point in flipping=
=C2=A0 =C2=A0 =C2=A0the default if you can choose to run a make step or not= )?

I think that is basically your suggestion?

Basically, yes.

Warner

<= div dir=3D"auto">
+101 for that from here.

/bz

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7

--00000000000023b8ea061dff7d3a-- From nobody Thu Jul 25 19:41:06 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVLq50LSvz5R9Hk for ; Thu, 25 Jul 2024 19:41:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVLq40jH4z42w1 for ; Thu, 25 Jul 2024 19:41:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=HNwNTiYE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102e) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2cb55418470so165929a91.1 for ; Thu, 25 Jul 2024 12:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721936478; x=1722541278; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3qmU6tmToMmrhV/YRZ1fuGs6bGjrVhCSQNtXTQDYPtE=; b=HNwNTiYEDkxFbMFexHqlaBTVe1Wd9WmK4iUNoA6KFyxjTshqJn8bEuKXjPbgyaRlZd Sk55nauFJCr9ppZOAy72IL8u8V7cpPwUNrSyG0edbBsSboCflfcwzqHjiOW5AZkoLGi/ lUpLW4l1g+EaH6rffY9+/E8KmJSd8mY08U7vpxfxTrdbg8V84lcUc66JQFZd5G8arou0 mj4XvLjrf9mnTpe17QLueCKWh72X+gwkV7pUtYmeVCIr6J7Q8Iu+g744CSHazZnaxhiH 3nY16ioQzYSz+fCi/r7SspgomSe0D5/7LhVkTl7mU/CWeBkJdKsFb/WKrlNl7QrrWRNA TUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721936478; x=1722541278; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3qmU6tmToMmrhV/YRZ1fuGs6bGjrVhCSQNtXTQDYPtE=; b=bXYdi9cC2yo++ngy5FjAcsxWtnbVL+Chl0VeM4u5qskdpZSUs5NbQQSDYo6fjse7nn Yc7T+dYJph3WZfkzUX4nxt3hinc6IkJNUfNXmk0Ir25QFADPTuLJhnqXWhwItgHQFBoz GMYN74xTf/ivP2Z8cxmC+c69bcmxIxGRQtuDoTh/Bbd5jGf5RMNj8di7DG80AQZqJrzq vnmu14YzS3tjyzcQd2/R5GnoIx2aB3sUTAMoroXfXUI27hd74Eh0qWqW+32Ifg8xLvMF 9jQv7TUavKACt8ybPA65WPh1qyB8meZu/CVYyQ8K0toAX3bG8Q4OeO9fLxtnNEPrMCN4 YMrQ== X-Gm-Message-State: AOJu0YwNJabOarBJBYFMNUUKxRr6wAHWOY3m7HAvJ612DmPDfEdkAo3B zVh5kZRnqTR6s4u5UCuGNP7jgUmdkO3ZF6Cim3HOhwSUMa5ELtiBLr2mS7o4hgQjcr3MGnRRnuY wTlSjwMw/Flx+dbXjpB4bPe5UyDTRdO8twaXgd6362oKLQKQLuuMyvA== X-Google-Smtp-Source: AGHT+IFLaYNZRxKpgVMsLmeZF0HCFREQD3IP0nSe1iZH3bS4WtBGxGQL57+41H8A50ayvEYY2fqU91hM8GTd+Hn2IdM= X-Received: by 2002:a17:90a:b118:b0:2c6:ee50:5af4 with SMTP id 98e67ed59e1d1-2cf2e9ab0b7mr3233820a91.6.1721936477806; Thu, 25 Jul 2024 12:41:17 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 From: Warner Losh Date: Thu, 25 Jul 2024 13:41:06 -0600 Message-ID: Subject: Towards __deprecated in cdefs.h To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000160092061e17946f" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4WVLq40jH4z42w1 --000000000000160092061e17946f Content-Type: text/plain; charset="UTF-8" There's often times we want to mark interfaces as allowed, but please stop using it. C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. It would be nice to start using it. The question is how. Linux adopted, then effectively abandoned, __deprecated as a decorator. At first, it would produce warnings, but water was changed to be just ornamental because too many warnings were thrown during a kernel build. So position [1] is to do what Linux did. Make iit a #define that does nothing. Position [2] is do what Linux did originally: make it a warning to use deprecated interfaces (but likely a -Wno-error warning). However, it would be nice sometimes to have a message that goes along with the use. Sadly, there's no way to have a macro in C or C++ that either takes an argument or doesn't. You either get pure replacement, or you get parameterized replacement, but never both. So, we'd need __deprecated_str or __deprecated_msg that took an optional message to give. This form would always warn, but could be paired with either [1] or [2] as [3] and [4]. Since we're talking about a macro that's slightly different than Linux, should it have a different name, in which case we'd have __dep and __dep_msg(x) as [5] and [6]. There's likely more crazy, but that's likely too crazy to contemplate. Personally, I think that option [4] is best: have __deprecated and __deprecated_msg(x), both of which always warn. We don't need a __deprecated_error, I don't think. We get the same effect by removing it entirely, or removing its declaration from the .h file while keeping ot global. So before I spend a ton of time on implementing the various options, I thought I'd poll on arch@ to see if there's agreement that [4] is likely best, and if not, which other option I should put my weight behind. I realized I needed a wider discussion when I did [2] in https://reviews.freebsd.org/D46137 and the ensuing conversation in IRC didn't have 'no-brainer yes' written all over it. The down side of doing [4] is we'll have to also change OpenZFS... but we likely should do that anyway since OpenZFS opted to use a copy of the linuxkpi compiler.h file rather than #include it and make minor mods :(. Maybe I'll make a patch for that too, or maybe I'll fix up https://github.com/openzfs/zfs/pull/16388 Warner --000000000000160092061e17946f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's often times we want to mark interfaces=C2=A0as= allowed, but please stop using it.

C23 has a new, fancy= [[deprecated]] and [[deprecated("msg")]] forms. It would be nice= to start using it.

The question is how.

Linux adopted, then effectively abandoned, __deprecated as = a decorator. At first, it would produce warnings, but water was changed to = be just ornamental=C2=A0because too many warnings were thrown during a kern= el build.

So position [1] is to do what Linux did.= Make iit a #define that does nothing.

Position [2= ] is do what Linux did originally: make it a warning to use deprecated inte= rfaces (but likely a -Wno-error warning).

However,= it would be nice sometimes to have a message that goes along with the use.= Sadly, there's no way to have a macro in C or C++ that either takes an= argument or doesn't. You either get pure replacement, or you get param= eterized replacement, but never both. So, we'd need
__depreca= ted_str or __deprecated_msg that took an optional message to give. This for= m would always warn, but could be paired with either [1] or [2] as [3] and = [4].

Since we're talking about a macro that= 9;s slightly different than Linux, should it have a different name, in whic= h case we'd have __dep and __dep_msg(x) as [5] and [6].

<= /div>
There's likely more crazy, but that's likely too crazy to= contemplate.

Personally, I think that option [4] = is best: have __deprecated and __deprecated_msg(x), both of which always wa= rn.

We don't need a __deprecated_error, I don&= #39;t think. We get the same effect by removing it entirely, or removing it= s declaration from the .h file while keeping ot global.

So before I spend a ton of time on implementing the various options, = I thought I'd poll on arch@ to see if there's agreement that [4] is= likely best, and if not, which other option I should put my weight behind.= I realized I needed a wider discussion when I did [2] in=C2=A0https://reviews.freebsd.org/D46137 a= nd the ensuing conversation in IRC didn't have 'no-brainer yes'= written all over it.

The down side of doing [4] i= s we'll have to also change OpenZFS... but we likely should do that any= way since OpenZFS opted to use a copy of the linuxkpi=C2=A0compiler.h file = rather than #include it and make minor mods :(. Maybe I'll make a patch= for that too, or maybe I'll fix up=C2=A0https://github.com/openzfs/zfs/pull/16388
=

Warner
--000000000000160092061e17946f-- From nobody Thu Jul 25 21:12:40 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVNrS6WT8z5RKRY for ; Thu, 25 Jul 2024 21:12:40 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVNrS5jy8z4HNM; Thu, 25 Jul 2024 21:12:40 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721941960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XWvKKfGIqWZZAelPc7B1umaL+oz5rn2CRNJQ1yO5ATI=; b=VMDf+rXW18vuxBVfY4GLyj0pGdb9wGU1aCabrpMlejrVS5zOYLqQV5eVUXL2n3nva2o2na aU+uy47NVf3nMQUOSMwTzop9qbAaB2b5LT4PJ2O1nlJyT9ofAKYRftBN2e0yEaUs8zkLkA V7sL/jSlP/hwD7MCpGJ+bxmdwHbdPxqFYn4tpKSb4y2ndXNHwd21j5h9DfNXcOZ/KxPaeI DekQsEqo0+hGR2ek02TXvoBiOKBIdDvmID2ve5tD6C3nAykkP61/ayB0aopS+vIiNbyfmu oLF3nEmh3C/PWB7TUMS3Ugp8/TBKqeBDEXeRBeMGLXfm3pt6/eTfp9hYatZI+g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721941960; a=rsa-sha256; cv=none; b=uQ1Kdxj0+YCPBg54/ZCpOlFJmr9c43Zy8u3kja/s5CHdrk1y1RQIraKf+JXlwwprfBcoI5 /BU9Z/I2L1NDGQ17F0RiS7NB51dhRX3c5D/HKpPYm89esbXQ8gaA86UY2lBkSEBv2BXyiN QJxCqSf/CYDopn+IZXvVVasbwoVhUrFrjt2sPxAr5x6mkS6dYxYmkWP+8o+sXXAVvmyXi0 14fy3AsqqqpIETp4x9ulYIfjeBbvYHWjUmBdBJyVUVT0DF5XAdl/QKsuYie6UB0dH1XedN G78u0qcKrmyZIpv3mphAgnsZNVLBW8aPEM9o2niEFtOL93QXvdRFrpBd/Y1TIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721941960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XWvKKfGIqWZZAelPc7B1umaL+oz5rn2CRNJQ1yO5ATI=; b=SELotdKQM4/P4SNEYv6/qXgpjRn1MxZOBXOMusriIGByCllu8o8oSFpmNqIln2+OfnmyxY WbPtQlwD1ATIN51sjkU/lyllsBkM/kwadQM96z/NBewnHBlsgERqrFjhdkxLFz5thZsAqZ Mtu5Uh6Wq6UEDourDBUWW2f6X/l3PlxdvGfdVyChsJAEvhEigEm7KIsF1fyITSZrG6EO7L XPcd6kBALc8UEoeM14bv2357LgKg6St5djIBUCVDGhNOX253kf1rhlPG7WWurOW+Rw2pEX ZbBMKq3CHEIqy0wvArOlaiGiboKxVOWP40vunRwP3hbSsJujZI16dngRWGvPpA== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WVNrS5BXmzHDv; Thu, 25 Jul 2024 21:12:40 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 0F00B3C019B; Thu, 25 Jul 2024 21:12:40 +0000 (UTC) Date: Thu, 25 Jul 2024 21:12:40 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Towards __deprecated in cdefs.h Message-ID: References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote: > There's often times we want to mark interfaces as allowed, but please stop > using it. > > C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. It > would be nice to start using it. > > The question is how. > > Linux adopted, then effectively abandoned, __deprecated as a decorator. At > first, it would produce warnings, but water was changed to be just > ornamental because too many warnings were thrown during a kernel build. > > So position [1] is to do what Linux did. Make iit a #define that does > nothing. > > Position [2] is do what Linux did originally: make it a warning to use > deprecated interfaces (but likely a -Wno-error warning). > > However, it would be nice sometimes to have a message that goes along with > the use. Sadly, there's no way to have a macro in C or C++ that either > takes an argument or doesn't. You either get pure replacement, or you get > parameterized replacement, but never both. So, we'd need > __deprecated_str or __deprecated_msg that took an optional message to give. > This form would always warn, but could be paired with either [1] or [2] as > [3] and [4]. > > Since we're talking about a macro that's slightly different than Linux, > should it have a different name, in which case we'd have __dep and > __dep_msg(x) as [5] and [6]. > > There's likely more crazy, but that's likely too crazy to contemplate. > > Personally, I think that option [4] is best: have __deprecated and > __deprecated_msg(x), both of which always warn. > > We don't need a __deprecated_error, I don't think. We get the same effect > by removing it entirely, or removing its declaration from the .h file while > keeping ot global. > > So before I spend a ton of time on implementing the various options, I > thought I'd poll on arch@ to see if there's agreement that [4] is likely > best, and if not, which other option I should put my weight behind. I > realized I needed a wider discussion when I did [2] in > https://reviews.freebsd.org/D46137 and the ensuing conversation in IRC > didn't have 'no-brainer yes' written all over it. [4] with a message variant works for me. It's close to the standard thing and makes it easy to see what you should be doing. > The down side of doing [4] is we'll have to also change OpenZFS... but we > likely should do that anyway since OpenZFS opted to use a copy of the > linuxkpi compiler.h file rather than #include it and make minor mods :(. > Maybe I'll make a patch for that too, or maybe I'll fix up > https://github.com/openzfs/zfs/pull/16388 IMO this file should be pared down to only things OpenZFS uses in shared code (__deprecated is not). It looks typical of the ZoL -> FreeBSD port in that overly broad shims where copied and hacked until the thing compiled, but then no effort was made to slim them down. See ecbf02791f9 in OpenZFS for another example. -- Brooks From nobody Thu Jul 25 23:57:12 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVSVY5hS8z5Rb26 for ; Thu, 25 Jul 2024 23:57:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVSVY1vZpz4d4K for ; Thu, 25 Jul 2024 23:57:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-7a0c6ab3354so359226a12.0 for ; Thu, 25 Jul 2024 16:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721951844; x=1722556644; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tsP6XiipwBOIHo38kUPLlkjSb7jS47Q3UJ27zNv2vEg=; b=hftlfh3wpHiDcsD9AzrEf7MNnV1/TqVhlUiR9Uu5VwaJpffk95eLJ0zM83D1zywV6N VZDZMT4MDk4WYBs3pmo2KyPxxMp7lSY+UXTYCsdgeJvPaDgwpWLrPQ4XVUGnduH8BdGA i4lf21N8ChpWVs88/vS8o0Qt0fQcqYN1fYG416oLRAwsk2jiSEdBT9K3bxKRiWfEyL3x jlKVb7R4p/FNTrjTorYGpxxRdSiK0+rpJacDL9oQPjr79zkb+Nm/lgb/7QVhjkAdIkVb tJ0E/vmdGsZKPlpBAhRmNp/N0YQniRWfmUPBvvFjpqlY+9LFM5mihSDz8FwhjRwWycbA 26Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721951844; x=1722556644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tsP6XiipwBOIHo38kUPLlkjSb7jS47Q3UJ27zNv2vEg=; b=TRa21ass+a2Ozsz8W1I9PprWO92S+qoEtmxN7DKtaOQYZgnnD5ggJT3Gz/LHLGy4UZ QKj+qhbLqSJ+Qs2kACM4GD66t9Xpac9nLPUiiPiyDyWn3dvmIgqCrr+DF7Q+qBZYZc1y rqoWip+LxEEzNxvnGL4OnH57VTV3rS2fXjZMnqGdtM4SpbS3Qt0TzeSW+ZVB/PBJ0CIl tc479h61qOhEOzMzAyhn96YeU07TeoPSCwOZiv1lotrkhpCcBxf2S3e1rYOqGWfpJxaJ sv+73iFC/dBoZ0mY3JxtXXQluG566+FwZY7Zly4iRuMDKzS+1bpmt47OXU0jgCRAa4Yy /4/w== X-Gm-Message-State: AOJu0Yw6vcKxu15yC/hX8RGHLO4+PlICC1KO5NSsYwqGq0P44/wT9Wkb v3P6lSttOHNkay2Msq9ocEXhYiyKdQ1jOWDNbDcs5hznJREE9F8II8TXlhv9R6HjDhPjLFaEokh FckaSoo80mkJZ/MZhQDwyriLiqStMgznsBOI8zvEWgBRM7xWV6yJEXg== X-Google-Smtp-Source: AGHT+IE0PMgHIX2cjj1z5zOGLxvUqeOOgIL5lEEyWVJpE18dNN235pEQkNna6zUS2B8qLHAYOJkJiGgbgBkI5XcrZm0= X-Received: by 2002:a17:90a:f48f:b0:2cd:b938:770b with SMTP id 98e67ed59e1d1-2cf2e9b30a2mr3877026a91.5.1721951843713; Thu, 25 Jul 2024 16:57:23 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 25 Jul 2024 17:57:12 -0600 Message-ID: Subject: Re: Towards __deprecated in cdefs.h To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f72425061e1b27f6" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WVSVY1vZpz4d4K --000000000000f72425061e1b27f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brooks Davis w= rote: > On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote: > > There's often times we want to mark interfaces as allowed, but please > stop > > using it. > > > > C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. It > > would be nice to start using it. > > > > The question is how. > > > > Linux adopted, then effectively abandoned, __deprecated as a decorator. > At > > first, it would produce warnings, but water was changed to be just > > ornamental because too many warnings were thrown during a kernel build. > > > > So position [1] is to do what Linux did. Make iit a #define that does > > nothing. > > > > Position [2] is do what Linux did originally: make it a warning to use > > deprecated interfaces (but likely a -Wno-error warning). > > > > However, it would be nice sometimes to have a message that goes along > with > > the use. Sadly, there's no way to have a macro in C or C++ that either > > takes an argument or doesn't. You either get pure replacement, or you g= et > > parameterized replacement, but never both. So, we'd need > > __deprecated_str or __deprecated_msg that took an optional message to > give. > > This form would always warn, but could be paired with either [1] or [2] > as > > [3] and [4]. > > > > Since we're talking about a macro that's slightly different than Linux, > > should it have a different name, in which case we'd have __dep and > > __dep_msg(x) as [5] and [6]. > > > > There's likely more crazy, but that's likely too crazy to contemplate. > > > > Personally, I think that option [4] is best: have __deprecated and > > __deprecated_msg(x), both of which always warn. > > > > We don't need a __deprecated_error, I don't think. We get the same effe= ct > > by removing it entirely, or removing its declaration from the .h file > while > > keeping ot global. > > > > So before I spend a ton of time on implementing the various options, I > > thought I'd poll on arch@ to see if there's agreement that [4] is likel= y > > best, and if not, which other option I should put my weight behind. I > > realized I needed a wider discussion when I did [2] in > > https://reviews.freebsd.org/D46137 and the ensuing conversation in IRC > > didn't have 'no-brainer yes' written all over it. > > [4] with a message variant works for me. It's close to the standard thin= g > and makes it easy to see what you should be doing. > Yea. It also follows a few other things done as well... > > The down side of doing [4] is we'll have to also change OpenZFS... but = we > > likely should do that anyway since OpenZFS opted to use a copy of the > > linuxkpi compiler.h file rather than #include it and make minor mods :(= . > > Maybe I'll make a patch for that too, or maybe I'll fix up > > https://github.com/openzfs/zfs/pull/16388 > > IMO this file should be pared down to only things OpenZFS uses in > shared code (__deprecated is not). It looks typical of the ZoL -> > FreeBSD port in that overly broad shims where copied and hacked until > the thing compiled, but then no effort was made to slim them down. See > ecbf02791f9 in OpenZFS for another example. > Yea... The other way is to share better: https://reviews.freebsd.org/D46144 and https://reviews.freebsd.org/D46145 so we share the fixes... I haven't thought about going the other direction... I'll have to see what that looks like. I had the same problems with the original OpenZFS boot loader integration: It barely compiled, but was super fragile and tiny changes would break it again and again while I was testing (eg rebase forward a few weeks while testing). So I rewrote it to make it way simpler... Warner --000000000000f72425061e1b27f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 25, 2024 at 3:12=E2=80=AF= PM Brooks Davis <brooks@freebsd.or= g> wrote:
On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote:
> There's often times we want to mark interfaces as allowed, but ple= ase stop
> using it.
>
> C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]= ] forms. It
> would be nice to start using it.
>
> The question is how.
>
> Linux adopted, then effectively abandoned, __deprecated as a decorator= . At
> first, it would produce warnings, but water was changed to be just
> ornamental because too many warnings were thrown during a kernel build= .
>
> So position [1] is to do what Linux did. Make iit a #define that does<= br> > nothing.
>
> Position [2] is do what Linux did originally: make it a warning to use=
> deprecated interfaces (but likely a -Wno-error warning).
>
> However, it would be nice sometimes to have a message that goes along = with
> the use. Sadly, there's no way to have a macro in C or C++ that ei= ther
> takes an argument or doesn't. You either get pure replacement, or = you get
> parameterized replacement, but never both. So, we'd need
> __deprecated_str or __deprecated_msg that took an optional message to = give.
> This form would always warn, but could be paired with either [1] or [2= ] as
> [3] and [4].
>
> Since we're talking about a macro that's slightly different th= an Linux,
> should it have a different name, in which case we'd have __dep and=
> __dep_msg(x) as [5] and [6].
>
> There's likely more crazy, but that's likely too crazy to cont= emplate.
>
> Personally, I think that option [4] is best: have __deprecated and
> __deprecated_msg(x), both of which always warn.
>
> We don't need a __deprecated_error, I don't think. We get the = same effect
> by removing it entirely, or removing its declaration from the .h file = while
> keeping ot global.
>
> So before I spend a ton of time on implementing the various options, I=
> thought I'd poll on arch@ to see if there's agreement that [4]= is likely
> best, and if not, which other option I should put my weight behind. I<= br> > realized I needed a wider discussion when I did [2] in
> https://reviews.freebsd.org/D46137 and the ensuing conver= sation in IRC
> didn't have 'no-brainer yes' written all over it.

[4] with a message variant works for me.=C2=A0 It's close to the standa= rd thing
and makes it easy to see what you should be doing.
Yea. It also follows a few other things done as well...
=C2=A0
> The down side of doing [4] is we'll have to also change OpenZFS...= but we
> likely should do that anyway since OpenZFS opted to use a copy of the<= br> > linuxkpi compiler.h file rather than #include it and make minor mods := (.
> Maybe I'll make a patch for that too, or maybe I'll fix up
> https://github.com/openzfs/zfs/pull/16388

IMO this file should be pared down to only things OpenZFS uses in
shared code (__deprecated is not).=C2=A0 It looks typical of the ZoL -><= br> FreeBSD port in that overly broad shims where copied and hacked until
the thing compiled, but then no effort was made to slim them down.=C2=A0 Se= e
ecbf02791f9 in OpenZFS for another example.

=
=C2=A0Yea...=C2=A0 The other way is to share better:=C2=A0https://reviews.freebsd.org/D46144
and=C2=A0https://re= views.freebsd.org/D46145 so we share the fixes... I haven't thought=
about going the other direction...=C2=A0 I'll have to see wh= at that looks like.

I had the same problems with t= he original OpenZFS boot loader integration:
It barely compiled, = but was super fragile and tiny changes would break
it again and a= gain while I was testing (eg rebase forward a few weeks
while tes= ting). So I rewrote it to make it way simpler...

W= arner
--000000000000f72425061e1b27f6-- From nobody Fri Jul 26 00:18:43 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVSzQ2W3Mz5RcVv for ; Fri, 26 Jul 2024 00:18:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVSzP0d9zz4fb9 for ; Fri, 26 Jul 2024 00:18:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=peliWtGD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1032) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2cb57e25387so322817a91.3 for ; Thu, 25 Jul 2024 17:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721953135; x=1722557935; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oE99sWS8vvNXHPXiTsy/TQ3gMk6mMeLzwtCj89inl7M=; b=peliWtGDXploa4+JcvggMfAM1ZghcXAPPJaQRiMrSc6dGwzUYL2lelem1Z5VoYZhJ0 3nAt5hW9ZxUsJvS0CMoc7b8ItbU+1HnOTSYMkb9mBaY1cKdNjjso4jlAQSAS/tWF51A0 5WJJrqu6JmnK/3xwESWFU3DyGndWcOa/SVKHVdQRmkRGd4ilmTqYoLPc5PRT4s5N6tsg QB8VyihkZDsyVpPK4nYDW3h//dJ1CQoIADqCHIoQi3ZrhEP2FR4BtcRuU/gK5vVqKAEt 5FMwZw4ep+zEqf0Mhu6ALJTJB9o5Unjd/dw/FZvhkR1oE63ucDbn0oE+6STVbJ5Q5YqI oiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721953135; x=1722557935; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oE99sWS8vvNXHPXiTsy/TQ3gMk6mMeLzwtCj89inl7M=; b=aDTzP94CONhhkn7/hl6Zkrk7TAnGLdv/iNbsHb9jveWHNmyrbgsGqB03MaFgnHTv9P QzA0nhFyMJujhgk8h2pUjaY1uDRETrSvKnWwZm2fa1iBBzSmgsReuw6Chmd6F3ykEtXA AVxJd9uIe7dXk6rtzqdZ71PKwLGwAsz+6IXnVkqgalCKFACdZWFlnL7FUvpZYqXHgLJw FaVGbQs/enl4jEkWYAK+Pl/FI7qETx7/ydzqzkRD5wuCimAICuxWDMmSC/vILx4Q3rFX cL1cjnpmUkkDr1wZY+NjwdrJWAXySNCzA1V5vm96wHGuoBUKIt81C72vlmZKnq19uCaN oE0A== X-Gm-Message-State: AOJu0YyoDGh5vlR370m5joATxjT2tI7QK9vGP6XbeGV2/SVMTub+sDmu Y3EX621L4k76SGaUQNsdHYVCBYMFYmf8YyiSNVYW3ZHaalwEXXkL52EwSZ7MmoeYmxS8G1vAO1Y bpZnMfXcfb5gO17db2a5UaTQym7o9R96haxAcyVH3D02UbEYF3e1Kng== X-Google-Smtp-Source: AGHT+IEis/kDmFXtvtWeiv7FfUcHUCz/ZPHoykVKyNH9dMHeWGrYHRdLnxg/addsv5pnJl1A4lN0OznhZQetzADDCOw= X-Received: by 2002:a17:90b:274c:b0:2ca:7636:2214 with SMTP id 98e67ed59e1d1-2cf2e9cfe3fmr4274462a91.4.1721953135117; Thu, 25 Jul 2024 17:18:55 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 25 Jul 2024 18:18:43 -0600 Message-ID: Subject: Re: Towards __deprecated in cdefs.h To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f06c21061e1b7489" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4WVSzP0d9zz4fb9 --000000000000f06c21061e1b7489 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2024 at 5:57=E2=80=AFPM Warner Losh wrote: > > > On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brooks Davis = wrote: > >> On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote: >> > There's often times we want to mark interfaces as allowed, but please >> stop >> > using it. >> > >> > C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. I= t >> > would be nice to start using it. >> > >> > The question is how. >> > >> > Linux adopted, then effectively abandoned, __deprecated as a decorator= . >> At >> > first, it would produce warnings, but water was changed to be just >> > ornamental because too many warnings were thrown during a kernel build= . >> > >> > So position [1] is to do what Linux did. Make iit a #define that does >> > nothing. >> > >> > Position [2] is do what Linux did originally: make it a warning to use >> > deprecated interfaces (but likely a -Wno-error warning). >> > >> > However, it would be nice sometimes to have a message that goes along >> with >> > the use. Sadly, there's no way to have a macro in C or C++ that either >> > takes an argument or doesn't. You either get pure replacement, or you >> get >> > parameterized replacement, but never both. So, we'd need >> > __deprecated_str or __deprecated_msg that took an optional message to >> give. >> > This form would always warn, but could be paired with either [1] or [2= ] >> as >> > [3] and [4]. >> > >> > Since we're talking about a macro that's slightly different than Linux= , >> > should it have a different name, in which case we'd have __dep and >> > __dep_msg(x) as [5] and [6]. >> > >> > There's likely more crazy, but that's likely too crazy to contemplate. >> > >> > Personally, I think that option [4] is best: have __deprecated and >> > __deprecated_msg(x), both of which always warn. >> > >> > We don't need a __deprecated_error, I don't think. We get the same >> effect >> > by removing it entirely, or removing its declaration from the .h file >> while >> > keeping ot global. >> > >> > So before I spend a ton of time on implementing the various options, I >> > thought I'd poll on arch@ to see if there's agreement that [4] is >> likely >> > best, and if not, which other option I should put my weight behind. I >> > realized I needed a wider discussion when I did [2] in >> > https://reviews.freebsd.org/D46137 and the ensuing conversation in IRC >> > didn't have 'no-brainer yes' written all over it. >> >> [4] with a message variant works for me. It's close to the standard thi= ng >> and makes it easy to see what you should be doing. >> > > Yea. It also follows a few other things done as well... > > >> > The down side of doing [4] is we'll have to also change OpenZFS... but >> we >> > likely should do that anyway since OpenZFS opted to use a copy of the >> > linuxkpi compiler.h file rather than #include it and make minor mods := (. >> > Maybe I'll make a patch for that too, or maybe I'll fix up >> > https://github.com/openzfs/zfs/pull/16388 >> >> IMO this file should be pared down to only things OpenZFS uses in >> shared code (__deprecated is not). It looks typical of the ZoL -> >> FreeBSD port in that overly broad shims where copied and hacked until >> the thing compiled, but then no effort was made to slim them down. See >> ecbf02791f9 in OpenZFS for another example. >> > > Yea... The other way is to share better: > https://reviews.freebsd.org/D46144 > and https://reviews.freebsd.org/D46145 so we share the fixes... I haven't > thought > about going the other direction... I'll have to see what that looks like= . > > I had the same problems with the original OpenZFS boot loader integration= : > It barely compiled, but was super fragile and tiny changes would break > it again and again while I was testing (eg rebase forward a few weeks > while testing). So I rewrote it to make it way simpler... > vs https://reviews.freebsd.org/D46146 which just starts to scratch the surface. There's a lot of other stuff that can likely be trimmed. Warner --000000000000f06c21061e1b7489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 25, 2024 at 5:57=E2=80=AF= PM Warner Losh <imp@bsdimp.com>= wrote:


On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brook= s Davis <brooks@= freebsd.org> wrote:
On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote:
> There's often times we want to mark interfaces as allowed, but ple= ase stop
> using it.
>
> C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]= ] forms. It
> would be nice to start using it.
>
> The question is how.
>
> Linux adopted, then effectively abandoned, __deprecated as a decorator= . At
> first, it would produce warnings, but water was changed to be just
> ornamental because too many warnings were thrown during a kernel build= .
>
> So position [1] is to do what Linux did. Make iit a #define that does<= br> > nothing.
>
> Position [2] is do what Linux did originally: make it a warning to use=
> deprecated interfaces (but likely a -Wno-error warning).
>
> However, it would be nice sometimes to have a message that goes along = with
> the use. Sadly, there's no way to have a macro in C or C++ that ei= ther
> takes an argument or doesn't. You either get pure replacement, or = you get
> parameterized replacement, but never both. So, we'd need
> __deprecated_str or __deprecated_msg that took an optional message to = give.
> This form would always warn, but could be paired with either [1] or [2= ] as
> [3] and [4].
>
> Since we're talking about a macro that's slightly different th= an Linux,
> should it have a different name, in which case we'd have __dep and=
> __dep_msg(x) as [5] and [6].
>
> There's likely more crazy, but that's likely too crazy to cont= emplate.
>
> Personally, I think that option [4] is best: have __deprecated and
> __deprecated_msg(x), both of which always warn.
>
> We don't need a __deprecated_error, I don't think. We get the = same effect
> by removing it entirely, or removing its declaration from the .h file = while
> keeping ot global.
>
> So before I spend a ton of time on implementing the various options, I=
> thought I'd poll on arch@ to see if there's agreement that [4]= is likely
> best, and if not, which other option I should put my weight behind. I<= br> > realized I needed a wider discussion when I did [2] in
> https://reviews.freebsd.org/D46137 and the ensuing conver= sation in IRC
> didn't have 'no-brainer yes' written all over it.

[4] with a message variant works for me.=C2=A0 It's close to the standa= rd thing
and makes it easy to see what you should be doing.
Yea. It also follows a few other things done as well...
=C2=A0
> The down side of doing [4] is we'll have to also change OpenZFS...= but we
> likely should do that anyway since OpenZFS opted to use a copy of the<= br> > linuxkpi compiler.h file rather than #include it and make minor mods := (.
> Maybe I'll make a patch for that too, or maybe I'll fix up
> https://github.com/openzfs/zfs/pull/16388

IMO this file should be pared down to only things OpenZFS uses in
shared code (__deprecated is not).=C2=A0 It looks typical of the ZoL -><= br> FreeBSD port in that overly broad shims where copied and hacked until
the thing compiled, but then no effort was made to slim them down.=C2=A0 Se= e
ecbf02791f9 in OpenZFS for another example.

=
=C2=A0Yea...=C2=A0 The other way is to share better:=C2=A0https://reviews.freebs= d.org/D46144
and=C2=A0https://reviews.freebsd.org/D46145 so we shar= e the fixes... I haven't thought
about going the other direct= ion...=C2=A0 I'll have to see what that looks like.

I had the same problems with the original OpenZFS boot loader integra= tion:
It barely compiled, but was super fragile and tiny changes = would break
it again and again while I was testing (eg rebase for= ward a few weeks
while testing). So I rewrote it to make it way s= impler...


--000000000000f06c21061e1b7489-- From nobody Fri Jul 26 02:35:11 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVX0k4CJ5z5RpBF for ; Fri, 26 Jul 2024 02:35:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVX0k3gSsz4qG9; Fri, 26 Jul 2024 02:35:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721961318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6m9ucngEJ4F7wCAG4fQDIO6JqSUYprGkingNfNij1Vs=; b=MLBfRi3zper9DvRiIc/Z8l7dfnlN1FJbuIRCC47QzfflvlFunooC5Q6js8cMtT6cfUVW8W REplLHs9aZqvHVmYNwUm2ck5Nq3Xy6in1MVAr1HXDgpDqSI/ZnsnQMlrSl5Z+fyujOPKeZ C+6nYL7XacYIrBGRxOEJsyW68a3660NuPoQiJOEvDlfTXP7C6csznCYFgRD8/Oip/asRjE xPY81bgeaImszXBY/CnCy1lcnSFMVvIFhp+WVqS8AjpzliXEWqhfdCf3YmXVmFVXs6mdLc cROlwmM+C/9Xkt7Br4tRx/SPD0nB0StyOQJzQ6eV95kYY+ZWpprP+FFSc1sf3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721961318; a=rsa-sha256; cv=none; b=kmt9f3CGM36xvqN23kIQAalxCZbZ0RG+l9vTMU6A3eFqpwqfq7IQZ/u6Sma+7ozN9QXY24 YPHf/iczNzPIIHoHDvCAL1pyvRaa1s5t4O+hVF6Uda2Op0dxw6Aex3BjnbiE+LTkebmPLa ADrwfsD9a1fe6YFZSejk4gmN8EQrxoNcw9HyXLcz2rKChUDj+O3e9Os5TY4+N3MVjBn/rs YN/mbgQnrJ93AjH5BgGDHS6YRNCBEdAQ7wu97UtEhXOXfMhphxy0QpJOwD6GKX5G8Lm6zu nuNgpsTWjSMhb/C8CQAll+zNmPyI3O1Apybq0cVnoYoZOBWZLBdZdOjnid1Zig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721961318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6m9ucngEJ4F7wCAG4fQDIO6JqSUYprGkingNfNij1Vs=; b=m6ZfyO04Ue3VgSQsQvt8InXneuHz2yb5LhD4O58VzkO47sC7h55hrBiNnoeQYoqOU6jOkP V9N6MUfqjc8iLITXvf8PvLuyE+eB8DsLUoPuSWb9fm1uJtyobdBHVsvQuVRxOTfW9Mh4aY u7PHVewRCG9ddJG7xwTnqv9J2IzYUTRraJ7cGxQ6rL1y46KMi8PUiNdld4qtdWN0p44wC2 KswVF4R7PRpdQxrBxGQb6Hgfz/Ors5RjRn8aMGqFyX25WRD49VKpAI2XxdwCFAOMdIL4/Z J9VYHBrD56hVUYNbXyMnalXNxGC49r22aqW5sBw+M/bJ6HnZoKPkjDybiGoJTw== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WVX0j4jYdzQ19; Fri, 26 Jul 2024 02:35:17 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <4480E3AA-106D-40C3-84FF-7C6A11EC2649@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610" List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: Towards __deprecated in cdefs.h Date: Fri, 26 Jul 2024 10:35:11 +0800 In-Reply-To: Cc: "freebsd-arch@freebsd.org" To: Warner Losh References: X-Mailer: Apple Mail (2.3696.120.41.1.8) --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 26, 2024, at 3:41 AM, Warner Losh wrote: >=20 > There's often times we want to mark interfaces as allowed, but please = stop using it. Also the userland libraries have some interfaces commented or documented = deprecated but persist for quite long time. It would be nice to have compiler warnings for the usage so we could = evolve fast. >=20 > C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. = It would be nice to start using it. >=20 > The question is how. >=20 > Linux adopted, then effectively abandoned, __deprecated as a = decorator. At first, it would produce warnings, but water was changed to = be just ornamental because too many warnings were thrown during a kernel = build. Yes. Too many warnings to be useful. I doubt if we can emit the warning for changed or new code only. I think = it would be nice to have CI to do that. A typical usage should be = pre-commit checks. Turn on flag of deprecated warnings only for the = changed files and filter out the changed lines. For existing code, if the migration is desired, developer could turn on = the flag manually to verify his / her work. >=20 > So position [1] is to do what Linux did. Make iit a #define that does = nothing. >=20 > Position [2] is do what Linux did originally: make it a warning to use = deprecated interfaces (but likely a -Wno-error warning). >=20 > However, it would be nice sometimes to have a message that goes along = with the use. Sadly, there's no way to have a macro in C or C++ that = either takes an argument or doesn't. You either get pure replacement, or = you get parameterized replacement, but never both. So, we'd need > __deprecated_str or __deprecated_msg that took an optional message to = give. This form would always warn, but could be paired with either [1] = or [2] as [3] and [4]. >=20 > Since we're talking about a macro that's slightly different than = Linux, should it have a different name, in which case we'd have __dep = and __dep_msg(x) as [5] and [6]. I think it is useful to always have a message to explain why and to = direct an alternative . >=20 > There's likely more crazy, but that's likely too crazy to contemplate. >=20 > Personally, I think that option [4] is best: have __deprecated and = __deprecated_msg(x), both of which always warn. >=20 > We don't need a __deprecated_error, I don't think. We get the same = effect by removing it entirely, or removing its declaration from the .h = file while keeping ot global. No. Technically not. It would always be bypassed if intended. Why not = turn __deprecated_error into ERROR or drop that definition ? If deprecations would globally be turned to errors, the proper approach = should a condition, either a macro, or compiler flag. >=20 > So before I spend a ton of time on implementing the various options, I = thought I'd poll on arch@ to see if there's agreement that [4] is likely = best, and if not, which other option I should put my weight behind. I = realized I needed a wider discussion when I did [2] in = https://reviews.freebsd.org/D46137 = and the ensuing conversation in IRC didn't have 'no-brainer yes' written = all over it. >=20 > The down side of doing [4] is we'll have to also change OpenZFS... but = we likely should do that anyway since OpenZFS opted to use a copy of the = linuxkpi compiler.h file rather than #include it and make minor mods :(. = Maybe I'll make a patch for that too, or maybe I'll fix up = https://github.com/openzfs/zfs/pull/16388 = >=20 > Warner Best regards, Zhenlei --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 26, 2024, at 3:41 AM, Warner Losh <imp@bsdimp.com> = wrote:

There's often times we want to mark = interfaces as allowed, but please stop using = it.

Also the = userland libraries have some interfaces commented or documented = deprecated but persist for quite long time.
It would be nice = to have compiler warnings for the usage so we could evolve = fast.

C23 has a new, fancy [[deprecated]] = and [[deprecated("msg")]] forms. It would be nice to start using = it.
The question is how.

Linux adopted, then = effectively abandoned, __deprecated as a decorator. At first, it would = produce warnings, but water was changed to be just = ornamental because too many warnings were thrown during a kernel = build.

Yes. = Too many warnings to be useful.

I = doubt if we can emit the warning for changed or new code only. I think = it would be nice to have CI to do that. A typical usage should be = pre-commit checks. Turn on flag of deprecated warnings only for the changed files and filter out the = changed lines.

For existing code, if the migration is = desired, developer could turn on the flag manually to verify his / her = work.

So position [1] is to do what Linux = did. Make iit a #define that does nothing.

Position [2] is do what Linux did = originally: make it a warning to use deprecated interfaces (but likely a = -Wno-error warning).

However, it would be nice sometimes to have a message that = goes along with the use. Sadly, there's no way to have a macro in C or = C++ that either takes an argument or doesn't. You either get pure = replacement, or you get parameterized replacement, but never both. So, = we'd need
__deprecated_str or __deprecated_msg that = took an optional message to give. This form would always warn, but could = be paired with either [1] or [2] as [3] and [4].

Since we're talking about a macro = that's slightly different than Linux, should it have a different name, = in which case we'd have __dep and __dep_msg(x) as [5] and = [6].

I = think it is useful to always have a message to explain why and to direct = an alternative .

There's likely more crazy, but that's = likely too crazy to contemplate.

Personally, I think that option [4] is = best: have __deprecated and __deprecated_msg(x), both of which always = warn.

We don't = need a __deprecated_error, I don't think. We get the same effect by = removing it entirely, or removing its declaration from the .h file while = keeping ot global.

No. Technically not. It would always be bypassed = if intended. Why not turn __deprecated_error into ERROR or drop = that definition ?

If deprecations = would globally be turned to errors, the proper approach should a = condition, either a macro, or compiler flag.


So before I spend a ton of time on implementing the various = options, I thought I'd poll on arch@ to see if there's agreement that = [4] is likely best, and if not, which other option I should put my = weight behind. I realized I needed a wider discussion when I did [2] = in https://reviews.freebsd.org/D46137 and the ensuing = conversation in IRC didn't have 'no-brainer yes' written all over = it.

The down = side of doing [4] is we'll have to also change OpenZFS... but we likely = should do that anyway since OpenZFS opted to use a copy of the = linuxkpi compiler.h file rather than #include it and make minor = mods :(. Maybe I'll make a patch for that too, or maybe I'll fix = up https://github.com/openzfs/zfs/pull/16388

Warner

Best regards,
Zhenlei

= --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610-- From nobody Fri Jul 26 07:58:58 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVgBM4Td2z5Rc2K for ; Fri, 26 Jul 2024 07:59:07 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVgBM2LMqz4GyK for ; Fri, 26 Jul 2024 07:59:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4BA0F892B4; Fri, 26 Jul 2024 07:58:59 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 46Q7wwPe097704; Fri, 26 Jul 2024 07:58:58 GMT (envelope-from phk) Message-Id: <202407260758.46Q7wwPe097704@critter.freebsd.dk> To: Warner Losh cc: "freebsd-arch@freebsd.org" Subject: Re: Towards __deprecated in cdefs.h In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97702.1721980738.1@critter.freebsd.dk> Date: Fri, 26 Jul 2024 07:58:58 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4WVgBM2LMqz4GyK -------- Warner Losh writes: > So before I spend a ton of time on implementing the various options, I > thought I'd poll on arch@ to see if there's agreement that [4] is likely > best, and if not, which other option I should put my weight behind. We have a history of warning that something will be removed, and then not remembering to do so until much later, so I think we should also have a grep-able "when" argument which can be surveyed during the run-up to a release. Maybe something like: __deprecated_msg(16, "foobar() is going away, use snafu() instead") With suitable macro-magic, that can also be used to run ports-surveys and other tests in a "pretend this is RELENG16" mode. If you want a word distinct from "deprecated" you could use "retired" ? -- 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 nobody Sat Jul 27 18:08:02 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WWXfq624tz5RQC5 for ; Sat, 27 Jul 2024 18:08:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWXfp63dCz4lrJ for ; Sat, 27 Jul 2024 18:08:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Q+BVXqM+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722103697; bh=+jjNqb4S+zCDavNKijDiyZ75jMzfUzFpjX0qA7piyVg=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=Q+BVXqM+MBw+qMUC0wVGllw7Ul600qaxYf6geDljnX5bFPZZ/uw6ZOVQ2GgWZmx8zncioTzVjKtqUHhCbTVoePZfEQGKCOqQGfE3d/x1yEQY7lOfDVA02SMb8ZxP9SHoPQ0BQ60bNX+KF9ldztBTm1yMUGkG9xakLXF4YZ3W+Y7bt4LqsA89VcGXb2D5woCLB+ScEiBYR690NYOkqIBEwzqKo4mhtZj3I6luTjcBBBgwaOJ7ABOEpJ2Lb66/6P9Gr0SwL+zcoUuKdf+xKYIB0Yaiw1t+JoArxjO3jmJbzsjUmsEUeX73hbnbsOdmtVyykM2YCvvOLAH1Mqd6GUfzQg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722103697; bh=1MR+u92U7i+6KOcGF7+5XUgZ4ecjB03zmmBpj78HjAw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=MOys+KIfJFik5J4AXrE8WFFyoJlJVK3MSyy6ed3GYjjxhbCuyXI94VhhsNeujjw0cBFyGn2kXIBMw7tieZ1/IQqUiAQVFGqy2HCcxINgxjFffh6CBV85Z/GunqTHtnGAaRL846O16d4olGSob7W8GbA5odyjF370oAOTu2Kd6yPvo78xfQoqCqxszV/U3VPpnjGm9QIi4rYDayYzXXFRGg83LAXhZ1d+pa88BpAIyZDUyb+jndfk8zQ8UAodRpNP/FT7sEiq+kexbTWSisT1mmDanU5NCBaKWru22eQriRa4jeQkLzEOPZlGAoHaM4Hhe3DSJNd9aoSaQlehK7IgDg== X-YMail-OSG: P2Qg2X4VM1n6uhs6Pjkw516mvYAV8df34JoHCgj0RQ1teig7UZQb_dDc.uIVUEe Py9BTsAkewK6WAJ1_vg7fszArWqu1ZC8_DG72cRzGHFoZbBgqUgKv5SML5Z3Ek5MZW1GwOu985kY vTiG5yFG5vP4ZlEblCBwL1VWbuj7fOuM_WG3j9I73ddAErDBP4J90pNPvSLddWqWPuVH6JEPUDPp 1LnK2Hs7TfEmX8gCd7y9lwjKXo3vmH8ygu2rZf3Gc3h9dBJ2w1yzPaXYIT9oXPIySjh8Fk6EcPWS yIYORI6a96Vanwr2dNycV8MPCsMOa_rGsYsZ4rGMpsZXuKjg0tsEBJcgAHlhGd60Z30TN2UikGh9 zO4Wy.kwU2ZdcoQiytQiyKY2Dt_FfrxgOD2gfYRzK03kgI7JMlSKyO4p1zc.ShqsAhUKibAAyhAQ yFgvQboYbu1UNBcz.lgv.GgHZ3A.vlfyunF.hV07mg20SK.D6w20tjHpP0zgrLyhMUwKzZOn3j0E MEsj6D.Ql6eAA2eUXnNuzhn_.l7w9YoQDhPZ0JzMyZMlQAhuVVGjF8PQs_3GQQ4qOT5S9EO6elTd FU0YhiuqMNUX2HNb_YojzI8ISlJBAHp3_Kgl2EEPeHmWsb5DPGMQXkkodh4VUnxY19ujnisvJJZY dZpHxFxt78q48w2MmiW9wjwpNyDkUNl6cgWrxnRIQduyjgdtO_rP6db3OrFSWcrR.0mhpq3VtHik 90ycff8mGISQuCEG4vuVHwIZFNokX6KZbt1CJRW45Wxe84rG5ss4RMp3.dxuvvyVCi1F_nXjLy_6 qJObwzEfAQy9RzQUJlW3RDCQUv9myKlAJHRqNcJhZ8tWXpdF_oz6OvXq8sGrJzrh83m9QyVkZJbh yYoZ02qjTJDSe8FXs_zYkwOwqjgYlg035uCQdCs0B6_301AoFHxQy7rtf8r0if2wK0THFYJ5fMLx hqIarvv9L0chIgWCCy5q4XSgtEesxvncUO9ZaZijUhS20UYGPMOJzclmAVEWc7uW6KtLV2VbpQJS gTG4HsJLJLQfBCMDvjX4M3voZhXv2MWtaSV9yWNdjf7ZfHU6nRZcugogh0DAhICMCMX0OyD3WEQN lxPQutDuK_pDlI8YnHRzVvudxlVTTBLn9ngWxwSyCfekCGQY3YehzLNlX6f_h0J2bYsXNMv6D.5C bMaQKE1BN8CXyWxd3TmOmrZxmKsiMqy672hvuuhcMpY47sro2QQ28VssjeSJIiTvp9XbbgEACUX5 fCc2r0TtLWlmG.jIhwL9NcehUuc3_mcUzrBLoQfUVwKn3hQR8UJrWmXELUO.eST_EwlRGw23FS8N 4yRS47TErRV7LGlgCPUe7kyc5qk9L1EIpzvlT00h8rF19CoWADPwfKZ2cz7.7iLeRV37N30u2XYv JMlLCyHmYFLwFyCD00yF88z2K3O.NF9p6XGc94OSzW.kZ9F4P3UYSnd4oMmuUceUqFnxEU6MkgPz YNP398SNfbU_spAkBIYzffcFBePYo.vN8tS9kY0aQEK6SsHR4.FqeHNnSnzTQ_9NGQH3oj8tQjny t9DUWU01E.GTZ7UgFfgnlAPlPZnmWo.3QmPwA7LbqLjpxkADNG0fZ6VGwn45MtdzXTg3Ew97bLz_ gvbkWcyoHrMH8jIyDu6ktnOCbq9oXM1O_w8wGBb1nMG1Hh7CnhfALmelgR3Ml5atvkgIN1wffTRc 1IBVUsQ4lj6Q_FJDe1invNY89unBwFLgnykS7AL4HOroSF3B4Lp7U5PN7vVBkJpJmiFvl1Wu6rEi pgba2oGl3NlYFbJSM8awQMmw6f2IPR2MYXwsSQjaRxMZfIHbgO8rAxZQDZelZpfTLZyI8cRhILsQ PZab5g92ixtKXaEjicOafsCtCqpqZEInqniBBCPeiECZdD4w.yMuFCIRxJdWpV_5s9KMReUeGVa. KRkIdtUT6iqlMonafgtKOObI8KlFnxf_S35zqaE2yBbBb515HVzVZ2tVmtyMVMgWkgYgv9NlEhIT fOSFS9mi.3yCRlmnsXyAUls6RdA0erzPWDySV1E68uqc4RvviO9KXa5KwoY2GMi7v8JBiJNIajPv Ey8s0ar9dNzcr3TAZ6uLB_cXReNUls9AlWO9Tfiw.z0OiXvEp6RGqMKwnUEtx3Nm_wpT9HDbiTAJ JTP.rdCTvDhyg4cRP0JBEgoeCL7DLJc.FZEy0H1Hf3XMKQfJc_JBDVWxcUpmZ8uhEjJzFcSofu6s VKaRO3GFeeOyj9QOdN4.XsoKxn1XbjPBEnLrD.ZrlXhNVBCm2Qn8dKA7EJ1fN6cnmeAKeM8UVZrq W X-Sonic-MF: X-Sonic-ID: 4871a0a4-c415-4268-b8f2-6d691e6f9ab0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jul 2024 18:08:17 +0000 Received: by hermes--production-gq1-799bb7c8cf-c9gcb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c06159e41002b02d83834e8175fb878d; Sat, 27 Jul 2024 18:08:13 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? Message-Id: <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> Date: Sat, 27 Jul 2024 11:08:02 -0700 Cc: FreeBSD Toolchain To: freebsd-arch X-Mailer: Apple Mail (2.3774.600.62) References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.887]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4WWXfp63dCz4lrJ This is more of an early-warning note than an immediate-action- required note. import std or import std.compat are reported to have the property of cutting build times vs. the historical use of headers. This could lead potential ports to needing to port things that are based on import std or import std.compat upstream, for example. FreeBSD has the property that the only implementation of (modern, clang based) libc++ is the one provided by the system. Having the ports environment have its devel/llvm* contexts use their own libc++ that might not match or be compatibile with the system libc++ is not provided for currently, as I understand. But, as far as I can tell, it looks unlikely that the system libc++ would be configured to allow import std or import std.compat : There looks to be extensive compiler options matching requirements for how the supplied std and std.compat were set up before they can be used. Building FreeBSD itself may have no intended use of the likes of import std or import std.compat . This leads me to wonder if FreeBSD will enable alternate libc++ usage for ports at some point in order to allow ports to use import std and/or import std.compat . Might that need, say, a lang/clang++* separate from the devel/llvm* ? Likely not intended for building FreeBSD itself? A problem here is avoiding he need for any process to have multiple libc++ implementations. This might be messy enough to block use of import std or import std.compat in ports fairly generally, needing a from scratch bulk -a run that is overall based on a specific alternate libc++ for example. (May be only those folks building there own packages/ports get to do such?) Has anyone been looking into the implications of attempting import std and/or import std.compat use for c++ use in a FreeBSD context (with the c++ library, not just the language)? === Mark Millard marklmi at yahoo.com From nobody Sun Jul 28 02:50:12 2024 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WWmFG4ym2z5RF4Q for ; Sun, 28 Jul 2024 02:50:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WWmFG01Rdz4djf; Sun, 28 Jul 2024 02:50:25 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-3dab336717fso1591584b6e.0; Sat, 27 Jul 2024 19:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722135024; x=1722739824; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o/sgjkF2cBuWOkdRf7Zd1UG1IS85xcoOOzTyMUcU4Fc=; b=nIJtLuikYA/66+jQw12gag2lTqwhGQPWhv9JN+imXe59/Ocr5wsLuIFcRUein0R3It AZ85idFOEqCm0v7k8UQLu24nADTbuh5IjariVb9FPId+8zZfNqeapJjCK01cbKVjXi7F 7YDc7HZddUG80AKkp+bo0r+ssA7Vkq2p8xCplgeCROBVIwJGugmXSuXsjkotsaaPF0Ow VIBaGpAJX+G8aDFuHBroxc2L5QzAoUdanTqLYncmnE2kFGBVOI9IAYVJyZYemTT1bepx GJv8xc9Xdkk2cOZ/4l58jzQGY3QdjEKtMO1FV5sD+1mFFWBdBQbF1hQmLGdujAE3BL+o Ftyg== X-Gm-Message-State: AOJu0Yw0yepaHyjFrzhKkUB73VtQ5RDyPIYIkV2PhQKQxQ7rnG87Bdmz bqU8MIWKbZYpkgVuV6o8Ry01TPNt5lr19iVVFV547clwRr+iaV8eT3lgAo7Z46HCCsDI02hsxZv 1eiRHa+H3n1vIZ0oQ0PZ/CIH7Ko1btU+9 X-Google-Smtp-Source: AGHT+IE+dlsfvZmH4V/mpEGeYWEVIeEBp9SR71gvebAsLdVErYQUHwH8E1kY4C8WHLSXo3gkgQwU6kEamoO/cg9nF5M= X-Received: by 2002:a05:6830:7004:b0:703:62f9:1aa7 with SMTP id 46e09a7af769-70940c0b306mr6081665a34.9.1722135023888; Sat, 27 Jul 2024 19:50:23 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> In-Reply-To: <9bbb12ee-d5e0-4e9c-a832-bbfe5eea0ba6@FreeBSD.org> From: Ed Maste Date: Sat, 27 Jul 2024 22:50:12 -0400 Message-ID: Subject: Re: Default NO_CLEAN=yes in 15+ To: John Baldwin Cc: arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.85 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; NEURAL_HAM_SHORT(-0.97)[-0.970]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEFALL_USER(0.00)[carpeddiem]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.175:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.175:from] X-Rspamd-Queue-Id: 4WWmFG01Rdz4djf On Tue, 23 Jul 2024 at 15:58, John Baldwin wrote: > > A few years ago, Ed Maste added a MK_CLEAN option to src.opts.mk to as a > WITH/WITHOUT knob for the "clean" step similar to NO_CLEAN=yes. To preserve > existing behavior this knob currently defaults to on, but I know Ed's goal > was to eventually flip the default so that NO_CLEAN builds would be the > default. I would like us to do that starting in 15. I've opened https://reviews.freebsd.org/D46172 for the change.