From nobody Sun Jan 28 11:50:44 2024 X-Original-To: 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 4TN8rs3g6Fz58R98 for ; Sun, 28 Jan 2024 11:50:53 +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 4TN8rr1qsnz4mS5 for ; Sun, 28 Jan 2024 11:50:52 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.17.1/8.17.1) with ESMTP id 40SBoi1I029576 for ; Sun, 28 Jan 2024 11:50:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40SBoiVN029575 for stable@freebsd.org; Sun, 28 Jan 2024 03:50:44 -0800 (PST) (envelope-from david) Date: Sun, 28 Jan 2024 03:50:44 -0800 From: David Wolfskill To: stable@freebsd.org Subject: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? Message-ID: Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org 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="s/c0DemtXUGN5bt2" Content-Disposition: inline X-Spamd-Bar: / X-Spamd-Result: default: False [0.61 / 15.00]; REPLYTO_EQ_TO_ADDR(5.00)[]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[catwhisker.org]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_REPLYTO(0.00)[stable@freebsd.org] X-Rspamd-Queue-Id: 4TN8rr1qsnz4mS5 --s/c0DemtXUGN5bt2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Context for this is in-place source-based updates using META_MODE, amd64 arch. In the specific case that catalyzed this note, the systems are running: freebeast(14.0-S)[4] uname -aUK FreeBSD freebeast.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #40 stable= /14-n266551-63a7e799b32c: Sat Jan 27 11:33:52 UTC 2024 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400506 = 1400506 freebeast(14.0-S)[5] and sources were updated to stable/14-n266554-2ee407b6068a this morning. The difference between the two in the stable/14 branch is: | freebeast(14.0-S)[8] git -C /usr/src show 63a7e799b32c..2ee407b6068a | cat | commit 2ee407b6068a994bba45597c995c5ea76eec9cf3 | Author: Peter Grehan | Date: Sun Jan 14 21:27:12 2024 +1000 |=20 | Fix issue with Linux guest XHCI tablet probing. |=20 | The USB3 spec mandates that the device-descriptor max packet size | be 512 bytes, which requires a field size of 9 since it is a | power-of-2. |=20 | Linux kernels recently started validating this field, resulting in | the table not being probed and the cursor not working in bhyve VNC. |=20 | PR: 275760 |=20 | (cherry picked from commit 0c243cd4a3671bf728f33378ac593c08d8367bc2) |=20 | diff --git a/usr.sbin/bhyve/usb_mouse.c b/usr.sbin/bhyve/usb_mouse.c | index 80f79980a98e..a37941c0cd9d 100644 | --- a/usr.sbin/bhyve/usb_mouse.c | +++ b/usr.sbin/bhyve/usb_mouse.c | @@ -154,7 +154,7 @@ static struct usb_device_descriptor umouse_dev_desc = =3D { | .bLength =3D sizeof(umouse_dev_desc), | .bDescriptorType =3D UDESC_DEVICE, | MSETW(.bcdUSB, UD_USB_3_0), | - .bMaxPacketSize =3D 8, /* max packet size */ | + .bMaxPacketSize =3D 9, /* max pkt size, 2^9 = =3D 512 */ | MSETW(.idVendor, 0xFB5D), /* vendor */ | MSETW(.idProduct, 0x0001), /* product */ | MSETW(.bcdDevice, 0), /* device version */ |=20 | commit 55210b704a056dfb2ea115edb3894efe16b7411b | Author: Chuck Tuffli | Date: Sat Jan 27 17:33:37 2024 -0800 |=20 | Revert "bhyve nvme: Add NQN value" |=20 | This reverts commit 4bd4942ea70becc583246597b658f3dcdbffafde. |=20 | diff --git a/usr.sbin/bhyve/pci_nvme.c b/usr.sbin/bhyve/pci_nvme.c | index 2fd49a84c768..d1b15d6f3a3c 100644 | --- a/usr.sbin/bhyve/pci_nvme.c | +++ b/usr.sbin/bhyve/pci_nvme.c | @@ -514,7 +514,6 @@ static void | pci_nvme_init_ctrldata(struct pci_nvme_softc *sc) | { | struct nvme_controller_data *cd =3D &sc->ctrldata; | - int ret; |=20 | cd->vid =3D 0xFB5D; | cd->ssvid =3D 0x0000; | @@ -584,13 +583,6 @@ pci_nvme_init_ctrldata(struct pci_nvme_softc *sc) | NVME_CTRLR_DATA_FNA_FORMAT_ALL_SHIFT; |=20 | cd->vwc =3D NVME_CTRLR_DATA_VWC_ALL_NO << NVME_CTRLR_DATA_VWC_ALL= _SHIFT; | - | - ret =3D snprintf(cd->subnqn, sizeof(cd->subnqn), | - "nqn.2013-12.org.freebsd:bhyve-%s-%u-%u-%u", | - get_config_value("name"), sc->nsc_pi->pi_bus, | - sc->nsc_pi->pi_slot, sc->nsc_pi->pi_func); | - if ((ret < 0) || ((unsigned)ret > sizeof(cd->subnqn))) | - EPRINTLN("%s: error setting subnqn (%d)", __func__, ret); | } |=20 | static void | @@ -3317,6 +3309,7 @@ pci_nvme_init(struct pci_devinst *pi, nvlist_t *nvl) | pci_nvme_aen_init(sc); |=20 | pci_nvme_reset(sc); | + | done: | return (error); | } |=20 | commit 4bd4942ea70becc583246597b658f3dcdbffafde | Author: Chuck Tuffli | Date: Thu Oct 12 15:04:17 2023 -0700 |=20 | bhyve nvme: Add NQN value |=20 | Add a NVMe Qualified Name (NQN) to the Controller Data structure using | the "first format" (i.e., "... used by any organization that owns a | domain name" Section 7.9 NVM-Express 1.4c 2021.06.28 Ratified). |=20 | This avoids a Linux kernel warning about a missing or invalid NQN. |=20 | (cherry picked from commit 32557d16e2c3c24c04eccfafd895e1514dc65b35) |=20 | diff --git a/usr.sbin/bhyve/pci_nvme.c b/usr.sbin/bhyve/pci_nvme.c | index d1b15d6f3a3c..2fd49a84c768 100644 | --- a/usr.sbin/bhyve/pci_nvme.c | +++ b/usr.sbin/bhyve/pci_nvme.c | @@ -514,6 +514,7 @@ static void | pci_nvme_init_ctrldata(struct pci_nvme_softc *sc) | { | struct nvme_controller_data *cd =3D &sc->ctrldata; | + int ret; |=20 | cd->vid =3D 0xFB5D; | cd->ssvid =3D 0x0000; | @@ -583,6 +584,13 @@ pci_nvme_init_ctrldata(struct pci_nvme_softc *sc) | NVME_CTRLR_DATA_FNA_FORMAT_ALL_SHIFT; |=20 | cd->vwc =3D NVME_CTRLR_DATA_VWC_ALL_NO << NVME_CTRLR_DATA_VWC_ALL= _SHIFT; | + | + ret =3D snprintf(cd->subnqn, sizeof(cd->subnqn), | + "nqn.2013-12.org.freebsd:bhyve-%s-%u-%u-%u", | + get_config_value("name"), sc->nsc_pi->pi_bus, | + sc->nsc_pi->pi_slot, sc->nsc_pi->pi_func); | + if ((ret < 0) || ((unsigned)ret > sizeof(cd->subnqn))) | + EPRINTLN("%s: error setting subnqn (%d)", __func__, ret); | } |=20 | static void | @@ -3309,7 +3317,6 @@ pci_nvme_init(struct pci_devinst *pi, nvlist_t *nvl) | pci_nvme_aen_init(sc); |=20 | pci_nvme_reset(sc); | - | done: | return (error); | } | freebeast(14.0-S)[9] And to the best of my knowledge, I do not use Bhyve at all. But llvm is now being rebuilt. Why? Thanks. 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. --s/c0DemtXUGN5bt2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbY/lF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5QZaAP4rhYbnV/vOYXGKj2VLLDKUqdlcWBIxdkpp8ne1gyxHeAEA6JTvOicKdpCe u7Jwwl24p6p7GgsSTc6pL569N8igIAE= =9rxD -----END PGP SIGNATURE----- --s/c0DemtXUGN5bt2-- From nobody Sun Jan 28 15:30:53 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 4TNFl50vNnz58mk0 for ; Sun, 28 Jan 2024 15:31:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (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 4TNFl331cCz46f3 for ; Sun, 28 Jan 2024 15:31:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jPaz8tKq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706455868; bh=Lk/fK2FYQeZqpSn8txBpBsozTIs60CROB+kPq96IOYU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=jPaz8tKqj/PDkYP9YPfwbnQjgIhIm28RoVBbqQJV9aaf52hukGgQHUIevKiZxt8XBnI+506cN4bEiINzRh0aEoECC3psY9EK1e2YjTVhzx0QYsS3K2SEu1bx/+puWZKvwxh6xmRBLvYUr30xCg7SlVoxvhs4A5XSFIYi8IauJcgoM4IQ0KQTRNwT0Ug+/+wAEyHLChjvCvJpz4hgExmCRGl1141FNaQjMzlEwP5V6799mFObXtYMt0DUFIQywndNq3WWRC0Mli8j2y2kESSSldO9ndnUNXUOVpYlG2zW9vIVAjHwJzagF5spUWUyHiu6HOwz+/7X6ZyGarC7qREa/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706455868; bh=BUrsj28AwmwZsGnMe/fusG6Z5YML4zoWORwjsU3zPIr=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VBx4sJAqKno+R/wXr+tKSVjLwcGweHPEMOuqgBXtJjBQ7C3Q5MNKaUpS0kQ6vUOn0rnILVnEGVUH3Fcelj6FCPwlvdqMtUVRnqMS7iIfieGWuK1bweGWcnePZh0GQSDR/Lq9IFJiIMCZZam8RyFfFIZ0YHGlE680u3Fg6wHh40u9ONUG2BSooVE0lrvxJtdxrMjQUQqi1+U3CGrgmHSokmRlQnhaO+H6pTU8FjcPENqKaRo+JIp4U/AwRvxI1PDIHe2/jlgawvue4ONV2rokHXYgByEZFyLJ3SfGCi9uQ5u1EhDMTioberFoPvf/PhPXxhM/SSUQJ2fbZZMs3d+CUQ== X-YMail-OSG: NEQP5zIVM1m1.QZloIRGyuaFAV6w9T1_rDp5zc_tXXaNEwLJpmVo_JtW9XKLCGu lqxkropWxxDmYiBrK4larAzQZPMIFqTqkmX950MCo31MZzCgEoeUh2EcwFXswO5jVRxj7SU8nPw_ vVrw9T4t6JvxyeIl8wOmNFxpH2LOCl_6kAtu95XoVX8i8b58.29CLVlbXcHuEFfBXxXTlCXJf7RQ QuMroIh0BaDBg9082svj0veciuwDq40Bxa3IfUoZ5rvsZECigCDNBn4F9IM4x0vmvPP9KeLa893. I8jJ4B06V5OtUBiFw0Q0qR1KxOUtjgaCzBB07JOONPhZ5C3joPwEXtqejKzyX5_ba7kdpGJ_MDyN tauw5Tr6Fjq1Bfb6LKfiasJhmVN6VDfNaNge_iz3oTLi6KphPZNN6MCo21PGvj9kiUHRLY449KTp QizBC6ECFaQ2nAJIXzEO5ZXeWOkAgHyRv0LcNG9fEG36KcGEfRCz5OnFAyAEsfQlLXCiK9h3iWaH xYsu22eiwziiF5AdA9oQXuLmlgSHSqHTaM31TApSfZhpuueZBvGUAUrGDlRmyqInQCJoaZ505hrH 3Gz9t_YXINgz8h3Tbc2wei5NZAmsj6np2NbEjybBUXzQtCgv0_3eFWO69GYDhoR6a1t5_vX2YTWO tR.rMhlo2wQXDPqlIouY0GSS9fwVxaC1HSjv7BArpm47PNVUnnEFuz8lxyk5NkdMKpNOO3m6kB8h Te2WI_NM4JpbBkc1fd8olcfzS0HUptXXqgpER1JkRcKcppPx7kMC_W2tF1U_cxv46LMNj07CZC6w SV.LqjZ604i1xx3ztkI7ImrJTn8RW7_2AAHzXxp15XnkYp_0PMvVoSS.PaBN5GJ4kBGkVENip0Qa HCgA64.z2eCAKeNAgpHp06Z0t6ckDBO5RfoQcmK.BTFe.QJotg6.f8u.u0PIBWQFzS4cdEJg13H. KOZjNXY3zvswuHoHl3LYnvEl._VlXcxI5iqAYM3GneiUSUg1KkNVvH2qagu1ZwnhIiPvCUXyKAeJ 2YGhdBauhnJF0W..EDcGXI2cNh.il8jgZlIK.6YWwGFdgwsIArkjmxKYUDjprP0VO4Xu89Q_ZrDO Lhu_uc1Q0VMe8Fm1Q92S1_XWmHT.dv6DUJkKvmp1BPAyQVMeFaf5rTtb5qhx4udNdS.BgjeW0tqg n7j6y67R8Zsc6kU6GPQ404PGHwJrWrnsk7vNL7dN.dkv4jfGMVobTYGg94bWgnEKsvDAKlKK5xP1 TSK0Efsyei64.XafHot7AC5zl5rKLaf7wO17R8VLNuBUeHDEZBLV4M6VqRDuUFWPKZWJVM9NtX_B 9gKtcb2n7K7DXAFoRifjcSveI08JhMQkQEg.GVCK6Rr7UoUJcLSJdiHT1peEjIEYvSEUOECkLxL1 dDyu_xYx3o6gHD9EbaqEuF84Kqx2rF8.qLGKMtoi_0pGT4Es1WgWz2w5NsVWl.HGRufbrSWlOhRq CAoHbAU3ds5eALrw7x2KlqDHzc17XWdCU6Rahm_CLAqbxVPilbIX_ypVjDOyAEKYdJ44u.uHP6e7 AhKD9Q3.ikFODEzACCc1YnIwQjHC4hz_UZJmCjrgziLqYiQwj1sICoHwqIthu2p88tfxUXyLoyh_ Z10FGjux6t_L6pI4V5BAzTVI94nk.VkHvObXt0d69_iFs4FqRykkbxQD1bDhS30y0ZNLwA1dKYqm BqAGeyvp0HFCdKk1Q32Cb3U_vwRhfX4rjd5tEtZ2047PeEXGqu.mO_HMrpcudvOzc8bxjceS6l.m E_QfdId_TtUEWQoLZyFEBqad6PodazmTb_HRl2HIf0X4gZRFariMKkLGjn9qCWOEzSwbJaeT7iKc VPan_UNjUdfSZMqLyTVssLO89_5jriePkDknZdaLskBfsDcvQ2u1zoNPLXA87SrSI8YW4.7U7HKH wGq_ZoPBPpwpXEJaFXpaqimXxuO_jPeEM8MCL9uZ7U2Mp5KSsYauovWmMTUUiEndJfUskcKnbm96 QgE4k3ivw_X8CxfNzl4nVWmYSkrnOAoLlTjx8.Cf_lOuGopfZxxPjT1.m6dhQncnUm9qwyBQUYZR zmc7n3nRnIMGLwHRfHkOzaEiIcXVzqy5N9S6QXb3NH4lZq5qW7vky1grbSkjwCV2oe42jmkFrB1I AgWbN7Fup6fkwTdL.8DZgaSXP.KJ55bG7pbK71gmr4oqEwzBEDheu12LESEdRAId9cF8nJrwXVfK tqAjjfbkoYfAde2Hiz5g8e69B7qKiD_wBoOOH4u3NzbKfbApck4bwiptBI6i2ULEGoeiu5GTa12. O X-Sonic-MF: X-Sonic-ID: 0c1f79f5-878a-4777-aa67-bbdffd371d4b Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Jan 2024 15:31:08 +0000 Received: by hermes--production-gq1-5c57879fdf-c7xks (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cee05f3bcb99ac22386185dcffb57f20; Sun, 28 Jan 2024 15:31:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: RE: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? Message-Id: Date: Sun, 28 Jan 2024 07:30:53 -0800 To: david@catwhisker.org, FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3774.300.61.1.2) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; MV_CASE(0.50)[]; 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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from] X-Rspamd-Queue-Id: 4TNFl331cCz46f3 David Wolfskill wrote on Date: Sun, 28 Jan 2024 11:50:44 UTC : > Context for this is in-place source-based updates using META_MODE, amd64 > arch. > . . . > But llvm is now being rebuilt. > > Why? The following two sequences are very different: make buildworld make buildworld vs. make buildworld make installworld make buildworld The installworld can update a lot of non-source files that were used to do the first build world. META_MODE notices such updates and does rebuild activity because of them. One more sequence: make buildworld make installworld update some sources make buildworld For that the installworld may be the larger change compared to the source updates as far as contributions to rebuild activity go. This sort of thing is likely what you had happen. === Mark Millard marklmi at yahoo.com From nobody Sun Jan 28 15:46:03 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 4TNG4G00Pvz58nry for ; Sun, 28 Jan 2024 15:46:06 +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 4TNG4F3c0Gz4Ck6 for ; Sun, 28 Jan 2024 15:46:05 +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 40SFk350033482; Sun, 28 Jan 2024 15:46:03 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.17.1/8.17.1/Submit) id 40SFk32g033481; Sun, 28 Jan 2024 07:46:03 -0800 (PST) (envelope-from david) Date: Sun, 28 Jan 2024 07:46:03 -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: 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="1wjfacJ6P90MXJft" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4TNG4F3c0Gz4Ck6 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] --1wjfacJ6P90MXJft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 28, 2024 at 07:30:53AM -0800, Mark Millard wrote: > ... > The following two sequences are very different: >=20 > make buildworld > make buildworld >=20 > vs. >=20 > make buildworld > make installworld > make buildworld >=20 > The installworld can update a lot of non-source > files that were used to do the first build world. > META_MODE notices such updates and does rebuild > activity because of them. First: Thank you for replying & suggesting the above. 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). And for that case, the production machines mount the builder's /usr/src and /usr/obj (via NFS) read-only. And without complaints of attempts to scribble on read-only stuff. :-} So if "make installworld" messes with anything that META_MODE cares about ... that would appear to be somewhat surprising. Mind, I've been wrong before, and I do intend to live long enough to be wrong again.... :-) > One more sequence: >=20 > make buildworld > make installworld > update some sources > make buildworld >=20 > For that the installworld may be the larger > change compared to the source updates as far > as contributions to rebuild activity go. >=20 > This sort of thing is likely what you had > happen. > .... Hmm.... Thanks again. 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. --1wjfacJ6P90MXJft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZbZ2u18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5dOlAQCQQxjhSZyzyluI14dDh8cv/Gx5QgiKNtmJbP9txJxuFQEArNBI6IQ+Dno3 BQAQaI1hP/W2nQaVJ+BuWt+XQdnkigg= =gBjP -----END PGP SIGNATURE----- --1wjfacJ6P90MXJft-- From nobody Sun Jan 28 18:20:30 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 4TNKVn5b34z5937y for ; Sun, 28 Jan 2024 18:20:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4TNKVm5nXzz4dXT for ; Sun, 28 Jan 2024 18:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fZ2yECrD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706466046; bh=Xtd+ldEFHqaNgaRU8s9z5QDt4ZTghsOoCfK/7BK9KTk=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=fZ2yECrDGMxKz1MtgClwfcFRc7uVM8MM5N0SpZYzYkYvl3hjo8eUvRTDgmYRdlyhtjlpst2+0t2KZ9LAhMa9diMz1m7c5M9UnHwvkCEyGLElD0u+P9ucVQXarLHO858lbTbVuYZam5CJ9UsW/m8GjkeYijQAtZKNPfFraz03EM3hDxWi60nDkiCCt6MvPtNUJSDKxjuH4yUMYt/3+ccNnWSqLOmzgmTQ1tAaNUGpsLpjIFPwhiCWlUeEtMJwr2VhLZigBVArhEiACcHkfITRLFkX3GawrcPdEnOVK4Q9haZv0Nzo2nnSOWu67yIgmjoCebhmZbWGVHIJd+JJEYJ4Lw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706466046; bh=ivFxbQnwDi6qjur377UoVucqbrKaG33+bvI0y0DZ5zR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ml+FNw8esY6xJAR3zCPhvnAPprD8faU0W9Si3Czx1VCNofyZajuUKhG3VyvH/E16FtscgyGnP7kR+axWVoS7VL79YAW6cPHMepj6fpz2pmTV0rt+ZfJRCVWyp5T086joB6lzYmE+wGn9KMG4pCX7ljyBE/kGP25OzRaybJYYP//78PHnSDpfSsS6jqAgiWqxuYrJvwdOyPMHbFzW4W7KasPXsMSia6+M3yq5HSu6cu8M1ZjDwo+bfNTuEA62QmpDw1MOyPJt/GYS9uFIBXo6zpv1bsufXpwlk3itFQ35wrMCK9UGAsXR5xoMvZEvvA7J+a9lCOsPnRgkrBalRVFlUg== X-YMail-OSG: 5u4IT1kVM1nOtg7C.liy4nvcTBIaGl1oS8HhFjySOncUYS0qy5FJSW.V0C8UKrP rW22r1m_sJ3sIYqvXY8b8gGIfzdubk0Snh_zWR02hqeEf.bCNUEEffqwcuRAYw5msfiNGsolzfhy Vv1E9360xk_5hh2P_UuMS5HW9k9hqLoriCnyNYFIr_BhQD9e2rsrF3bAyWtyQP.rs8YKAr2sz79. hoxaNVn096HumCMlGWNyHVSqzfZdi0_agpRTtPcwxBaqILzWoK1Q9HNEhSAJLOvdHogJy5oOfdGx 0Nt6cw3StlivSUF3._C4_W2IQiIfGE1oygEymK_VpuG_pwOZS2agw3pVpgfNYCvWyN1IIqQs5B3o k1LpQxWATzU151IxJz1v2x5foIwR_sJba9kQR10Pyt3djcYuhWf1Np_dfPef_IkgIKEHPn6CKPl3 _veEQJ4og6Q1Ov4p8a31HE4z0QRqhh34BGdu0cMOTWoXlJCF4RoJ5u8ntS7uBw9DW5X6vCTryCL8 twnoucVlQ3sf.e5w_Mhke8OtxdfCZ0RTGv3yF5ceF2yIxBxncgNF4s1c1zGrU3L_tbpWMfoJw22J cIG2gqubKKV3gY9Tal6qh0THcYlVJrJ_QinsZUcBMJ4RlpgZ52TiobnfMk_BKLpBkR0k3as0LhN. nJ5W0MzHCRiBxNrmW33QeMHh8JH5oq0WTid4o3frpu5oid0zqN6oFv4tFJ_UpD.Pnm0kCRj9SfND 79bi4Pb3NSyWg2XKl.WroDVvAaLEp0eBcVhAuHLzHfsB0f6THCJGXnl_ZTUSuLRLqXBDdk0Kh5Kd 8mW4W2QLWnYpDXMCVzuwSksoIBB_fdix2CyRnue_m3Ir6YKzWUcOZkt9Sq_ygqyYtJcDGIzInyc7 hZK1W92h.fy9AWvNmwdORRNGmq7dk7eJMbgzKpx1SJJBALLZZ.BFWLCy_R8KxAbRR75ZWf6yKNvj zSSPRoWOifWoxo_3QV2jYj_AL9BpORGX4fOYcAwEgF.LE1yofG1uWAmo7gjvPfJX26bm4IneliKT xgtCcDP6.yZZyH62aQfcABsdYRUpChdQb_llFugxyjvrF2k0RWd.LG8iK6ZObequkFU_lxEs1bdj nj0QbZyvcKvMxSwfykcU_3cMNjg4E8pocf7gfmh1mBO.zq1NdJ7Wfwgpa6YZdWWmNUF5SuA1gjvz 626_e_Tev9yWNzgyWOjQMZUlIIQyGcTdINZ0pPQdf1xpkD4OONAL0PJ75DjuhsGobWqama7e9Qny nN7RxcLUbWch3..vd2jUl.P7B59iY.rXxWdCaFTOK8acExIsn9cakFlY51i6Wrrv6wgsJXHInMxn _sM1qz7pmhkbt6KTHjz4gmJv.q.tYF8O_PblZmWJlThhLYRT3k2s842Z1xqAxe5RzQMKAhuPI30I bKXjFKeo_EqJJyZyhfQ06tFqWsAmUtr6VDXEbd0WrFbjP.NpwBSyPyD84h2qJJ6Pp.5QmekOLxG9 apYst3iqvubt.mXDw5Wl_2ch8Df0H7csODJOc9CS_Ab2Vb72VFR4vsXpQ_fUQUhTd8G6.P3rZZYK 7qlUcxzxJEacMtKca19WlboQyVB7WZd3hj3.19TAEztePzKw3nzXIYOYcDSXfg97KIyUP2iUWsUG E0Sv2coud241JT11HY_dlnpp0hemfCVO5GRLjq0BNSZWMflq1jo2z2ldOLNEOGPE09vnIktppZRF 4FEUA1wwLn9UhjC9KmM1XIlj2m17JanAUNJyevna3mflZDvONb52Mq6tZeWRTSyEiCLj6xa0jQ0J HNKuV7pvn13XjjO41jkflQ_2WHTTdfE3a_.pibw8B_0IzTWdtlkVH9Io45r9VV9vayao40b_QwCq cs2SMzhyh5N74ruM6nDX.hGWn0M_x8SfiOf3xqWx366a1UDkZ8bJ4HXoEoyO6mS2ueOR2twLQ7Ic 6izJ9W0DsQUQ.qSC5KBCg0F2W4fudJqPWwzZ3ltBh0SpUlngZY0vXnsiiaJYhJ92HcbU9CYWOqXp X6hz13dS_Rp1Qq6HOJP2nz_J9BXiX9W65OI31UGxTKWXvfmnh6Bg5mOWdvcprWFy2KLx6U_kKX31 cPr31UMldVdAXdAHuXYdmruQsBLlgLYzkLpJ6jb7IeSXybmYhCtAwjzyM6UrLJrheAF_OLM4qdZ1 yv82LPzd8zoe96GGXM.FXV98D4.Bfpm8B0fXHBfnu2UuholBJtlFcGYcx_5s_Ms2jFdYYuBOHHl_ OkGwa3kUtYU.8PjegWcwk7rc1fgNbGFr5h7_QE9RE41Ae0LY6Y99WbcnhePNRM9qfGVoqsMyt.ZV E X-Sonic-MF: X-Sonic-ID: ebe9eaec-bfea-4188-9bd7-821edbc3f308 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Jan 2024 18:20:46 +0000 Received: by hermes--production-gq1-5c57879fdf-hjdnf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 06cf5c5e808cde9e5e699f6d04cc8602; Sun, 28 Jan 2024 18:20:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? Date: Sun, 28 Jan 2024 10:20:30 -0800 References: To: david@catwhisker.org, FreeBSD-STABLE Mailing List In-Reply-To: Message-Id: <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985]; MV_CASE(0.50)[]; 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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Rspamd-Queue-Id: 4TNKVm5nXzz4dXT On Jan 28, 2024, at 07:46, David Wolfskill wrote: > On Sun, Jan 28, 2024 at 07:30:53AM -0800, Mark Millard wrote: >> ... >> The following two sequences are very different: >>=20 >> make buildworld >> make buildworld >>=20 >> vs. >>=20 >> make buildworld >> make installworld >> make buildworld >>=20 >> The installworld can update a lot of non-source >> files that were used to do the first build world. >> META_MODE notices such updates and does rebuild >> activity because of them. >=20 > First: Thank you for replying & suggesting the above. >=20 > 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. Which machine(s) are doing the llvm rebuild that you were hoping would not happen? What was the context like for the history on that machine? (The below had to be written without understanding of such things.) Here is an example META_MODE line recording a tool used during a particular file's rebuild: E 22961 /bin/sh 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 . 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): = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/awk So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file potentially being rebuilt, make ends up with: file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... (make has a mode that reports such things. I used it to find out what all contributed to some rebuild activity in order to figure out the general type of thing that was happeneing. Then I used it to find all the "is newer than" material that I expected to be unlikely to contribute to build changes.) It does not matter if: = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/awk is read-only at the potential-rebuild-of-file time. Only if it is newer. Simon J. Gerraty and I had a long exchange about this in 2023-Feb, that was in turn based on a earlier 2021-Jan report of mine. There are also issues when symbolic links are involved, if I remember right. At the time (2023) I was doing experiments with making some of this "unlikely to cause build differences" material end up being ignored. Ultimately, Simon provided me a patch to share/mk/src.sys.obj.mk to help with my experiments. See "Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)", starting with the 2023-Feb material at: = https://lists.freebsd.org/archives/freebsd-current/2023-February/003239.ht= ml I will note that my activity did not involve NFS mounts, only completely self-hosted builds on directly connected media, the boot media. I've no evidence if such NFS involvement makes any additional differences. bectl use can be used to keep around an example "after the build but before the install" place from the most recent build. It can be used for doing the next build to avoid the later installworld consequences on time relationships for the likes of /bin/sh . (It is also a place to revert to if an install went badly.) > And without complaints of attempts to > scribble on read-only stuff. :-} Detailed time relationships are what matter. You may have to work out what those are. > So if "make installworld" messes with anything that META_MODE cares > about ... that would appear to be somewhat surprising. See above. > Mind, I've been wrong before, and I do intend to live long enough to = be > wrong again.... :-) >=20 >> One more sequence: >>=20 >> make buildworld >> make installworld >> update some sources >> make buildworld >>=20 >> For that the installworld may be the larger >> change compared to the source updates as far >> as contributions to rebuild activity go. >>=20 >> This sort of thing is likely what you had >> happen. >> .... >=20 > Hmm.... Thanks again. =3D=3D=3D Mark Millard marklmi at yahoo.com 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-- From nobody Sun Jan 28 22:34:21 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 4TNR7h46fYz59RDk for ; Sun, 28 Jan 2024 22:34:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4TNR7g4q17z4Z1g for ; Sun, 28 Jan 2024 22:34:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GP9Gk38+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706481277; bh=UN+dU7d9MNUAOuGCNql9IJnE1EkTAJG37d52kUeYcBw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GP9Gk38+7HfSPRYicl9A0Tk7hM1ORgmK3BgDnItd5WQYSeI3EYzWCVhfTzBQnFfri8ei4mpLLD69uYKXqXUUHco+Jtipg6eNMr2/ipCgd+GvS2O6oDVCTEpBEvpDwwMdfOBlIeDqNq0bRrs2e19C5GHkzG6EIk+By96cZuiib3oRTiNmq31ovLeZ5khC4vU+EsePAdeMypm90ph8ZYAyl137c2kl3Y5a1HKq5juedKFxMmkZ5DCcUFazueaX10TwwJKivFwQS+1aMMgR4UCme80vK1hEEFRjielS3EIhFQ7EcrIMU90ztCT7r6cc3uILa9W2CbUG7WlPPYv4AS9igQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706481277; bh=6Yx5I79fL78E7U36VrGoofH0y8AZjqGZH4FxZduD0hG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HYeNslEx2FDoCZZ31qzJA5mwUFBEv3oh/ejlT5rhO0vQ379GdfUkSfLetUW1bvYvFC/BJmjUghZl//1y6YOjBQOWylCOXKkpGp1Ap8ExG595a8QCGqqVRQNOgu1mwZR+97RQhWYchU6iMNKPb70wQEGeh8LDSaApr3pSe0rZvcV+aR15NfvSsNgON4r0UI7DSbtiJojwyoJB1taKpjlAo0EaWpvDnrl7j6Suat849zGv6QI+ujxUEEZrY9s37XfIVhpVRWxEkI5a/BKey3Iidxa2KDuG3zkYK9BC32OHGCEMshNxmomKXRM/wagtj3WReP19sHXlAuZjLNwzYXH21g== X-YMail-OSG: lu6zcpoVM1kuHmoJAFO8RUEsDrXADBSuF0DWOqRBqspQ3to4sCHOD6JdJJ3iUBE pEg8TYuVTGL0xgGu_8l6oN7J11IizhB_0.r1RBopJpTT6Rl_kUJH19d227AVhPxenVs48eLNMHQt 8zxOaxu5SoiPwP7At7iq.I8_vkQUKhxxMOKjS4qY0ULW9QMiSsb5yVuxhf84rDXwhLnClZm271w8 O9lFsyQCphPyrClAvF2q2lA4SKllp3sB7HAd0TSSMpF.4n.vXlvof5I90XbxAK0JwFjfngNaQPca TxZS2Et.YPkiET2dQMl2QpZRlJRYWCnMk263OzPvhiuR.zVNvnB7Zw9CMC7FUG5uFaLQBHxrQjA. 247gkLj9H0WIfYIMB7NKF5GWTcosp.L5huzv9huhRbNoGaoWAb2aktHxLjTUQxJ2o5jSZhXjUiug fUnzgMydDOIoZ9kJ4.AcM4P6JSssjNlnPgJXPqubuHFPGGf_Rwyb51V2qFV5cO5HipPhdMfug5IN jci7IKSSkV4YkKCgOGUBH8dTSBYX4bClhVMNYF8ZSkuHkXvpQogYDJdrSyUAYPUsTriGinL8DIQU b1gad7_6SEt0ZJ_HTvMxCDq7V_mOkubnJ57DMlhoJ8nEpGB_ySdPiX5zQ.W4oDGujJl77y2dghps 28QN1zX4RtRjP1BzWAZXJg6UpZwGTh5uuMlYKEuU0_TK6WbIjR_GxGujbpQ3KH8CWBYUAu_dQvhd iC3eA6bzyjHyk3DzZTNRZEdhIpFehjXYFKQMGq0Xv69DaWjWbbP.KwvyepOqm7XgAThTaoSM.mRi IHbjqAgTrd4rjLZ68xr7jWMFUwbx4igsF0olEpTKqnX9QSpIZp8luJokPkLO6V1ka7SrA6sKska3 sG1uk7FrCikhaB2IUduSZiSKe29w9V1s6o5BiW_WdYLG9S8bIFlKyCb34XQ9cI2Aq_7fz0SdVyxT 8JsMlsrJkWsq91HKdZ22Rq9r.DYfPJDy9k0uiBsbWhNMLvXGogLHOHrdeIC4F7a_ylmHyUyhCGGL 805Hh.nta2QY1f3F21FU06aQsjkAVGysEY0RzJPk7SyQtNBVBgSBiQpxczDX3UG2JB5ybThz.gQ1 wQS_VvRSKivOTIkNPq1niN41wlJcCLzsC9bFCxFmHQUEGk_lskHX.ZtNnOiZFNdjx5h6ZIqsHQMk XMxve6AknYOF_WUAKbCmNXE00vgsVopPjvHWxGXuMqr2fMZQbqdEvYkBCuwEfhTgUvPWr.fyW6a7 D4l3dirAsx1b_k_dznXZBKKdwjVl7QpumwLwGGkvLEhqHqySdsnl2bCKcq6jXZi06tOSIewjKcJV xlISLpWvgonxScBBZjRqfds6lx5sOcTRO5X.cIzmy5IIR.rVH8ZF5jfQ9sMuS.Z.Dt1_Gvnyl45g rjWulf5Hn.pxZxYwTa3QVpdslZMvuYOCVwYt5EXWwZJR4edXWHPmY9JHHnozZGe.5I9iAQXLoorJ GeITlDxSrNaO9XVvIu9XQuyb8saOS2u5R1fmqQU5tlBPBfpguOwSmx0rq_jtjRn8bvIhs7W_JzUo AcjUIdy7a7V5p67Yl1M9BOIsidSpsSH6J59Pjy6K_htj2TachR6KPBYdC8bdmt_8oInHnMWrlDNN HxgBhgDNWaHxL7_T1SuGBWE2fDrfHlGUclGk6aXiZK60D4QMu1ygBIVa7dZHd6HMrijFJ0z.hO6M Q23ym6EmucQCijPOPm9kuNHeFK49yEw2zTIynoy2PcWSfC5iv8UtMe62YnyVDAoWlyq1SM2j2BNB lHLEgf1sRXOTkxMY7uNVPoxLaEV4.m8mUijpaSBxQ3E0DrztvHy57HwRbmWV1yT3XqGAcs1EBTTr 1mJ2TSBMwfFPvQ0ZMVtPpcNZk71VLx.wmxZv_uaK7ZOrQPcSOhfGO.3o7coU9Z.Onj4_.3ZR3j7S dZrCS4RPep2uMC0OR5zYlC1a7.z6Qyr6lu.nJxdebqbnHsP3OFEOGz73XCLI2mZcfrz2s1NBd.qh QfpoMDU3Pxs9pY6i.3o_ZLZdUooYkxMv4dyLSUFJAQrPWOgoiebck2ikKoI383wVzVNPDT3Ai1cW vy1qe08lKQPZVGwELBztuhMwviFwSb67DY8GDSrDZOIePhEM1DKnAZ659SZBqP9FKRcDRcJUiN4A RrEHs_axzwwJK.6rOquU.HLF6udrqy5DSZSbbEoxtX9Lpk.7CHtPBbLJAE9K2gD5vvK1e8CQXu.U TidqTveg09ZaD4YqRJMJrMZN1IXVD_jGsVktLoqphFJX.VqEggEl0SCK7A9Hs4vQxS2xegU_VMuA - X-Sonic-MF: X-Sonic-ID: aed78134-7060-4297-b429-a56ac511ce7c Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Jan 2024 22:34:37 +0000 Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45ddce1e697cc4dfa9b07dd382e384a1; Sun, 28 Jan 2024 22:34:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? From: Mark Millard In-Reply-To: Date: Sun, 28 Jan 2024 14:34:21 -0800 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> To: david@catwhisker.org X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.920]; MV_CASE(0.50)[]; 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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Rspamd-Queue-Id: 4TNR7g4q17z4Z1g [Note: your email is rejecting my E-mail: 554: 5.7.1 ] On Jan 28, 2024, at 14:06, David Wolfskill wrote: > 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? >=20 > Each of the 3 machines that I update via in-place source updates: the > above-cited "buildl machine" and a couple of laptops. >=20 >> What was the context like for the history on that machine? >=20 > 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). >=20 > Update histories for the build machine and one of the laptops is > available at https://www.catwhisker.org/~david/FreeBSD/history/ >=20 > 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". When you built and then installed stable/14-n266551-63a7e799b32c if you had then simply started another build where you installed, it would have rebuilt llvm at that point --before=20 stable/14-n266554-2ee407b6068a updated source was even present. The install of 63a7e799b32c made various tools used to do builds newer than the files used to do the build of 63a7e799b32c. That is enough for META_MODE to initiate rebuild activity so that things end up synchronized to be based on the updated installed tools. (Some tools might not be updated, others might be. The details depend on which are updated with new timestamps used by makes "newer" checks.) Try running make with the debug mode turned on that reports the "newer than" notices for what leads to rebuild activity (make -dM) after a notable installworld but before any source code updates. You might not like the full range of things checked but you will see why things are rebuilt. META_MODE tests date relationships among more files than you are considering. >=20 >> (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 . >=20 > 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. Changes to src/usr.sbin/bhyve/pci_nvme.c are not a cause of the rebuild. The prior installworld of 63a7e799b32c is the cause of the rebuild. If you had tried the build before updating the source tree, it still would have rebuilt llvm. >=20 >> 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/us= r/sbin/awk >>=20 >> So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file >> potentially being rebuilt, make ends up with: >> .... >=20 > Right; after some discussion with Simon and/or Bryan (back on 08 July > 2017), I augmented /etc/src.conf on the laptops to include: >=20 > .MAKE.META.IGNORE_PATHS +=3D /usr/local/etc/libmap.d >=20 > because I (also) had: >=20 > PORTS_MODULES+=3Dx11/nvidia-driver-390 >=20 > 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. >=20 > The above .MAKE.META.IGNORE_PATHS line helped address that issue. >=20 > Perhaps something somewhat similar is wanted to prevent the situation > that catalyzed the initial message in this thread? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 28 23:00:59 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 4TNRkN4J5Vz59T4s for ; Sun, 28 Jan 2024 23:01:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4TNRkM5czyz4cFK for ; Sun, 28 Jan 2024 23:01:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pKenG2Ja; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706482872; bh=w8clXwp/HykKXwJYJ236tIZHCz3t3hl1oWNQMOnsRRA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pKenG2Jaj8kWRWmrDeMwgj1NZOclt8a+ZpUvRHLJZOZbcq0mxoSdGD8hC9KQro4fkFPmopDpNPuE2CEMdrjNoMM71goIX8k7j3AIOqDze6OfTFN1dCG8HW0Av+MejJYYdSrluEa8xRNSdd/yiwqzvzVHCqVho8lSQWfU6zhWKUnbFTPdhgj7y1U/scE8ke0O9rbz/+MljDohMJKa+HCjwt+eELfs7h/3aPzIq0CJdkM+Xu09ctemf+/tEvTrxyLVpy7DlX2F14LzwNcIKyIAqFX/LjrDOd5PzlmPRqfAaCdBvNZ4O6Rr/uZ1W6xLeM1mgKXLaLFFzaSzGYsTGRjeHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706482872; bh=kR4DcdY+KRPhs+kqmrtfvXyPfLAK2oLxP1CpqzZyfNg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PRdkpyiiTpWl2+lUtDR0fJLi76XQDT80ctEcUZaYBpvzVfI/WD1U+h3N3rlwy3q0JweYfgFDy7fS049VsCYG9nLuM1vXKm3kMjiWycM3z/tYTJZVf8oUUmcX9eON/cPTbX2GmXbd7h/LGhnieL5rnBzMawXiGZ5B08rtGMtNhzAyBZxEU0m8EAngdIw0nmIoCC8W4HdskNciYCEJMQKxeTuGvqdZt2wptuvSzh6xNs+bjFbGEINir5vO6eSGqrmXbYWZcXTfgNDzPdL/QSGXHeYu7fo1yAT4dCoduwjKH0sjTO7Z29hKM6kCp6nHTdcCzf5GSRQ82TjTC0X0YiMdlg== X-YMail-OSG: wiIY5WUVM1ntPpoPKDuWQeUl0tpvWQaPOf7zKDicZJ2VKqx_gBP5hBFEOqfgpm8 vg25E0a27XFzMltRi0VLnMyVAizPl2X06k051DzkROP793o4AT6Ldq7STOM1kbqrGaKLaAbHHZBH PqB6xjweGMoILPTAWQAGtI5mSsPX85aGsnMmCIqOA9qyPRwZFMZP8.qpyCi9jGaWlkG3xoqwERD0 dMhRFRVqR_LHFG2wu1JqnpRXacoHRIi8_GEJ7Jin7RfoDIlsbv7_dMj2J9lLmq3HGflT6.77mBS4 VPEz7iIWEQwUdjrrTTsLNgTp7Ghs.L00bpuhOlBTqNMPorBxXhn9zA.0IY0h1OiPnJ_krIyHzg5x DLeJYbP6AupzY26h.XDpVqyuW7Pi5aloxcV7JIbc_iKPjZX3fnUPeAN2H9VPMKvw2SC_RPacpgQN x.z1vKwDfYf7pfCE1XNBCqbAVbakmvKgty0WoToe69eSeHiDklz85mOGeqsVwpulhpTwcb75IMyZ SA4f7tO37Qi4Bcoae.OFJvPQ96W7cgEnqlwcVu2LRSNi0V1BFfd1D4_XShjUA3cYDEPKbgMosQqH ZiELvfozbJJNzRfLt3kO6jvi4vpFbxfo2WmMPu5_K38N0f3tWKf9hLU3sNrxckSZMJ8KsDk74RwM 5huIUG0RrRVa9m2j_05F.g8yzxNOZJHB.ZnbedyYBWKTZK7QDS0UrpqKSn9Dz54r0x2ZmCUdaLBa PIWHJtMe5Vz6wwM2I8Yt3g.f34wIcyzcAjtFnOPhAqpNLhwWrv6AMka1FPWfH38mUcNrEuAmVUcK Xqm0hrIeuHIDnABOARaXtivLRcsk1XvNqW9lujz89QH5MVHHtU3b5fUdjW5cGWZkuQAn209WO3f0 m30cqp6OOn3r4iMcz1GHwPoWsUJllffQnCZscwuy.UR11g6AefSeRFFeeXGgM0vpRFy_jAA4vgj. CbqWDmAAVZ.Xd2nlV7MCnynhwXTquAjGCag0YzuvbahqtEwU5bqO3YlXi4sRyRRFDAknj82vQJBw LWIclZwf.ZBDueZLW2euhASNNBR0q36vDA6OeZ9bGEtypOoEK_KCjoCQ9WsNF5ddHVvqfOUiFEik VEcHmd_omUwCiIfsDT7_N9hqt1nfISPpjg__gT259d53bsuuBLLDQapM3i3P6TXTe80iY3d6eXjh 5PDOmL3uQpanulEC1v9cT_tKia.hBWPhk_nGoEmZr00mmxYJUErLhf4HsVTGMB6pBNYx.UDKLYdU IKU6YJVYGJGoVKkKLiXhD1I0DJw.XJUnXvhyl5dzq3ee.yNvl2_h6jKIwRm701xlvlFEd3PbHB8B s2S1Fx4F8TvS_qLaNwoC7j69VR.jwRCF8LTOgnH4p0iGGYF9tMRX.a_hLtQLopG6vPSp3L4sAp.P n7Eagr42S2tBMbkeayjtY0q4Os7hEIR7G0moEu8TlO8qeiCtRhf2zWa302RaQjBAhYMmjBWcSoRl q0oBArkjzkrD7a0ExvBTBAUsNqYIvIRaPAqiBvvpbF9815xaFh58dnppU.cykRigsvQAsOAvFCTf ZJig.dBGPT0pX8w6Fq5J.xiYzmVPLo1RDRisYZ3jzOZDPHjjFB_c5PJlHNwwfeOMdj3dw7F3.RZS CxEQI2uSHInwaEhKomOpIkaTpGWVfVTnbypZJbWCOW2lGcZJyGAAkGyZiJSarNuYrVvxlfP__75T zBVXQwAMX2IHV9XHXB9ZZfT2XxyLSi1uA4ybaWY1DgYI0WBfSrjlC0U7r4KmfVYuuzmVbEOCtiQN 9fYUge5mO_ih4nGLeiaKVN7xblkUb.KURYOHYDAFkDKPm3FrlkGRBDP.oOG8FPJPp9j42Jyil79z ipqY2OfjHWlW1XaJO7YmGk1roih9lfB0qzODiShJ7M9rZ8RkR95VEkWdGOWzw1B2fTrhGq_i2Ixq hFtPBa_vJ0uTlV8NixjYmVyy_Bgyv1sppvtAILwphzF4y1dbO9neLZyZC4p4fHlwprK26kRNChg_ puPGFf4fisKGQ8Fipc5NmWc9Ho4q2WZ7t5M7hY6gqPempPQfTJeWaIUIrZLC15cZ5RziSmyJsmTT 5s8YVXEgdi6Ax1WO8HnxrYHsX8XpwRzRQc1k7P0YmR4dx9sBVRECAiohOnP6jmnoMuq.5Jq5ZUzs bMabXGwlgdqsuoIKchPXWSE3OK204VVAzy7PIZNhimcxFJ5C.6kDYA1Kh3M3qxABu9JktlUv37_v eDbacK4O68TpjbvBy2nvIp5AfGEpfYKQOaBo1qQLyjZvxeLkBw1stw3yFYCENT09faPIKY0y8pi4 - X-Sonic-MF: X-Sonic-ID: ec50023f-484e-437a-b1a7-27ebd768389d Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Jan 2024 23:01:12 +0000 Received: by hermes--production-gq1-5c57879fdf-27p5r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4699fbc06edf563eb75f74712293a22d; Sun, 28 Jan 2024 23:01:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild? From: Mark Millard In-Reply-To: Date: Sun, 28 Jan 2024 15:00:59 -0800 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8A79DE24-403E-4E73-82B6-0E5CF4F27604@yahoo.com> References: <5BCB8F1A-B5D5-4506-87E1-8B26E713C6F5@yahoo.com> To: david@catwhisker.org X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.950]; MV_CASE(0.50)[]; 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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4TNRkM5czyz4cFK On Jan 28, 2024, at 14:34, Mark Millard wrote: > [Note: your email is rejecting my E-mail: > 554: 5.7.1 ] >=20 > On Jan 28, 2024, at 14:06, David Wolfskill = wrote: >=20 >> 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? >>=20 >> Each of the 3 machines that I update via in-place source updates: the >> above-cited "buildl machine" and a couple of laptops. >>=20 >>> What was the context like for the history on that machine? >>=20 >> 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). >>=20 >> Update histories for the build machine and one of the laptops is >> available at https://www.catwhisker.org/~david/FreeBSD/history/ >>=20 >> 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". >=20 > When you built and then installed stable/14-n266551-63a7e799b32c > if you had then simply started another build where you installed, > it would have rebuilt llvm at that point --before=20 > stable/14-n266554-2ee407b6068a updated source was even present. >=20 > The install of 63a7e799b32c made various tools used to > do builds newer than the files used to do the build of > 63a7e799b32c. That is enough for META_MODE to initiate > rebuild activity so that things end up synchronized to > be based on the updated installed tools. (Some tools > might not be updated, others might be. The details > depend on which are updated with new timestamps used > by makes "newer" checks.) >=20 > Try running make with the debug mode turned on that > reports the "newer than" notices for what leads to > rebuild activity (make -dM) after a notable installworld > but before any source code updates. You might not like > the full range of things checked but you will see why > things are rebuilt. >=20 > META_MODE tests date relationships among more files > than you are considering. >=20 >>=20 >>> (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 . >>=20 >> 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. >=20 > Changes to src/usr.sbin/bhyve/pci_nvme.c are not a > cause of the rebuild. The prior installworld of > 63a7e799b32c is the cause of the rebuild. >=20 > If you had tried the build before updating the > source tree, it still would have rebuilt llvm. >=20 >>=20 >>> 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/us= r/sbin/awk >>>=20 >>> So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file >>> potentially being rebuilt, make ends up with: >>> .... >>=20 >> Right; after some discussion with Simon and/or Bryan (back on 08 July >> 2017), I augmented /etc/src.conf on the laptops to include: >>=20 >> .MAKE.META.IGNORE_PATHS +=3D /usr/local/etc/libmap.d >>=20 >> because I (also) had: >>=20 >> PORTS_MODULES+=3Dx11/nvidia-driver-390 >>=20 >> 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. >>=20 >> The above .MAKE.META.IGNORE_PATHS line helped address that issue. >>=20 >> Perhaps something somewhat similar is wanted to prevent the situation >> that catalyzed the initial message in this thread? To be clear, referencing details of your context: When you had the stable/14 machines at 1c090bf880bf: A) You built (META_MODE): 63a7e799b32c B) You installed: 63a7e799b32c C) You rebooted into: 63a7e799b32c I'm claiming that next doing: D) build again (still META_MODE): 63a7e799b32c would have rebuilt llvm at that point, the time-relationship cause(s) being set up during (B). I would have to see make -dM output from (D) to find the specific timing relationships that lead to that. There is way to much to analyze the specifics manually, especially because dependency chains have to be considered. I have at times deliberately done the likes of (D) before later updating source and rebuilding, shifting in time when the extra activity happens to earlier so there would be less of a wait later. Sometimes the likes of (D) does not have much to do, other times likes of (D) does have a lot to do. But this sequencing risks the source update also leading to a large rebuild and, so, spending more total time building. =3D=3D=3D Mark Millard marklmi at yahoo.com