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