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--