From nobody Sun Jan 28 22:06:01 2024 X-Original-To: freebsd-stable@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 4TNQVh27lVz59Nwh for ; Sun, 28 Jan 2024 22:06:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4TNQVg46KTz4Tcn for ; Sun, 28 Jan 2024 22:06:03 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40SM622J005220; Sun, 28 Jan 2024 22:06:02 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40SM611d005219; Sun, 28 Jan 2024 14:06:01 -0800 (PST) (envelope-from david) Date: Sun, 28 Jan 2024 14:06:01 -0800 From: David Wolfskill To: Mark Millard Cc: FreeBSD-STABLE Mailing List Subject: Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? Message-ID: Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org, Mark Millard , FreeBSD-STABLE Mailing List References: <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TROfsdUfHCsaP0nm" Content-Disposition: inline In-Reply-To: <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> X-Rspamd-Queue-Id: 4TNQVg46KTz4Tcn 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:7018, ipnet:107.192.0.0/12, country:US] --TROfsdUfHCsaP0nm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 28, 2024 at 10:20:30AM -0800, Mark Millard wrote: > ... > > That said, one of the machines in question is my local "build machine" = -- > > and for it, in addition to in-place source updates, I also do (weekly) > > updates of my "production" machines (at home). > >=20 > > And for that case, the production machines mount the builder's /usr/src > > and /usr/obj (via NFS) read-only. >=20 > Which machine(s) are doing the llvm rebuild that > you were hoping would not happen? Each of the 3 machines that I update via in-place source updates: the above-cited "buildl machine" and a couple of laptops. >What was the context like for the history on that machine? Each of the machines is updated daily (except when I'm away and off-Net); each is updated to the same commit (as each has a local private mirror for the FreeBSD git repositories, and after updating the build machine's mirror, I use rsync to ensure that the laptops' mirrors are in sync with that). Update histories for the build machine and one of the laptops is available at https://www.catwhisker.org/~david/FreeBSD/history/ In each of the 3 cases this morning, the machine was running stable/14-n266551-63a7e799b32c and updated to stable/14-n266554-2ee407b6068a, which (as noted earlier) only changed src/usr.sbin/bhyve/pci_nvme.c. And each machine rebuilt llvm durng "make buildworld". > (The below had to be written without understanding > of such things.) >=20 > Here is an example META_MODE line recording a > tool used during a particular file's rebuild: >=20 > E 22961 /bin/sh >=20 > So installing an update to /bin/sh via isntallworld > would lead to the later META_MODE (re)build > indicating that the file needs to be rebuilt, just > because /bin/sh ends up being newer after the > installworld . Perhaps I should rephrase my query to "*Should* an update of (only) src/usr.sbin/bhyve/pci_nvme.c cause 'make buildworld' using META_MODE to rebuild llvm?" I seem to have empirical evidence that it does do that. > There are other examples of recorded paths to tools > in .meta file, such as (my old context example > used in an old E-mail exchange): >=20 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk >=20 > So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file > potentially being rebuilt, make ends up with: > .... Right; after some discussion with Simon and/or Bryan (back on 08 July 2017), I augmented /etc/src.conf on the laptops to include: =2EMAKE.META.IGNORE_PATHS +=3D /usr/local/etc/libmap.d because I (also) had: PORTS_MODULES+=3Dx11/nvidia-driver-390 in there, so x11/nvidia-driver-390 was being rebuilt every time the kernel was being rebuilt, and that caused /usr/local/etc/libmap.d to get an update. So META_MODE wasn't cutting down on the rebuilds in that case. The above .MAKE.META.IGNORE_PATHS line helped address that issue. Perhaps something somewhat similar is wanted to prevent the situation that catalyzed the initial message in this thread? Peace, david --=20 David H. Wolfskill david@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. --TROfsdUfHCsaP0nm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbbPyV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5RsbAQCSeIVNB3PnQD4hQx03150Uv5Q5L9wA55ao0UFs3onKMQEA/9VHPCbjjf4S UhsiOaXdrifcyu92wBUoCNXoEvXPQgg= =tjWN -----END PGP SIGNATURE----- --TROfsdUfHCsaP0nm--