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