Discussion:
Should changes in src/usr.sbin/bhyve/ trigger an llvm rebuild?
(too old to reply)
David Wolfskill
2024-01-28 11:50:44 UTC
Permalink
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 ***@freebeast.catwhisker.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 <***@FreeBSD.org>
| Date: Sun Jan 14 21:27:12 2024 +1000
|
| Fix issue with Linux guest XHCI tablet probing.
|
| 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.
|
| Linux kernels recently started validating this field, resulting in
| the table not being probed and the cursor not working in bhyve VNC.
|
| PR: 275760
|
| (cherry picked from commit 0c243cd4a3671bf728f33378ac593c08d8367bc2)
|
| 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 = {
| .bLength = sizeof(umouse_dev_desc),
| .bDescriptorType = UDESC_DEVICE,
| MSETW(.bcdUSB, UD_USB_3_0),
| - .bMaxPacketSize = 8, /* max packet size */
| + .bMaxPacketSize = 9, /* max pkt size, 2^9 = 512 */
| MSETW(.idVendor, 0xFB5D), /* vendor */
| MSETW(.idProduct, 0x0001), /* product */
| MSETW(.bcdDevice, 0), /* device version */
|
| commit 55210b704a056dfb2ea115edb3894efe16b7411b
| Author: Chuck Tuffli <***@FreeBSD.org>
| Date: Sat Jan 27 17:33:37 2024 -0800
|
| Revert "bhyve nvme: Add NQN value"
|
| This reverts commit 4bd4942ea70becc583246597b658f3dcdbffafde.
|
| 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 = &sc->ctrldata;
| - int ret;
|
| cd->vid = 0xFB5D;
| cd->ssvid = 0x0000;
| @@ -584,13 +583,6 @@ pci_nvme_init_ctrldata(struct pci_nvme_softc *sc)
| NVME_CTRLR_DATA_FNA_FORMAT_ALL_SHIFT;
|
| cd->vwc = NVME_CTRLR_DATA_VWC_ALL_NO << NVME_CTRLR_DATA_VWC_ALL_SHIFT;
| -
| - ret = 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);
| }
|
| static void
| @@ -3317,6 +3309,7 @@ pci_nvme_init(struct pci_devinst *pi, nvlist_t *nvl)
| pci_nvme_aen_init(sc);
|
| pci_nvme_reset(sc);
| +
| done:
| return (error);
| }
|
| commit 4bd4942ea70becc583246597b658f3dcdbffafde
| Author: Chuck Tuffli <***@FreeBSD.org>
| Date: Thu Oct 12 15:04:17 2023 -0700
|
| bhyve nvme: Add NQN value
|
| 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).
|
| This avoids a Linux kernel warning about a missing or invalid NQN.
|
| (cherry picked from commit 32557d16e2c3c24c04eccfafd895e1514dc65b35)
|
| 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 = &sc->ctrldata;
| + int ret;
|
| cd->vid = 0xFB5D;
| cd->ssvid = 0x0000;
| @@ -583,6 +584,13 @@ pci_nvme_init_ctrldata(struct pci_nvme_softc *sc)
| NVME_CTRLR_DATA_FNA_FORMAT_ALL_SHIFT;
|
| cd->vwc = NVME_CTRLR_DATA_VWC_ALL_NO << NVME_CTRLR_DATA_VWC_ALL_SHIFT;
| +
| + ret = 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);
| }
|
| static void
| @@ -3309,7 +3317,6 @@ pci_nvme_init(struct pci_devinst *pi, nvlist_t *nvl)
| pci_nvme_aen_init(sc);
|
| 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
--
David H. Wolfskill ***@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Mark Millard
2024-01-28 15:30:53 UTC
Permalink
David Wolfskill <david_at_catwhisker.org> wrote on
Post by David Wolfskill
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



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Wolfskill
2024-01-28 15:46:03 UTC
Permalink
Post by Mark Millard
...
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.
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.... :-)
Post by Mark Millard
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.
....
Hmm.... Thanks again.

Peace,
david
--
David H. Wolfskill ***@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Mark Millard
2024-01-28 22:34:21 UTC
Permalink
[Note: your email is rejecting my E-mail:
554: 5.7.1 ]
Post by David Wolfskill
Post by Mark Millard
...
Post by David Wolfskill
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.
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.
Post by Mark Millard
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".
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
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.
Post by David Wolfskill
Post by Mark Millard
(The below had to be written without understanding
of such things.)
Here is an example META_MODE line recording a
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 .
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.
Post by David Wolfskill
Post by Mark Millard
There are other examples of recorded paths to tools
in .meta file, such as (my old context example
/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk
So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file
....
Right; after some discussion with Simon and/or Bryan (back on 08 July
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
PORTS_MODULES+=x11/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?
===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Wolfskill
2024-01-29 00:05:03 UTC
Permalink
Post by Mark Millard
...
A) You built (META_MODE): 63a7e799b32c
B) You installed: 63a7e799b32c
C) You rebooted into: 63a7e799b32c
D) build again (still META_MODE): 63a7e799b32c
would have rebuilt llvm at that point, the
time-relationship cause(s) being set up
during (B).
As it happens, I rather fumble-fingered the (intended) reboot on the 2nd
laptop (and started another rebuild instead).

And I do these within script(1), as it's handy to have a record.

Note that this differes from the sequence you cite above, in that I
failed to do the reboot.

So I powered it back up and -- without updating sources (or the local
repo mirror, for that matter) -- did another rebuild.

Here is an extract of some salient lines from the typescript file:

g1-48(14.0-S)[4] egrep ' built in |Installing .* (started|completed)|Removing old libraries| stable/14-n' s1
Post by Mark Millard
World built in 2351 seconds, ncpu: 8, make -j16
Kernel(s) CANARY built in 898 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:25:27 UTC 2024
Installing everything started on Sun Jan 28 12:25:57 UTC 2024
Installing everything completed on Sun Jan 28 12:28:01 UTC 2024
World built in 116 seconds, ncpu: 8, make -j16
Kernel(s) CANARY built in 920 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:47:55 UTC 2024
Installing everything started on Sun Jan 28 12:48:25 UTC 2024
Installing everything completed on Sun Jan 28 12:50:01 UTC 2024
Removing old libraries
World built in 124 seconds, ncpu: 8, make -j16
Kernel(s) CANARY built in 901 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 23:34:39 UTC 2024
Installing everything started on Sun Jan 28 23:35:09 UTC 2024
Installing everything completed on Sun Jan 28 23:37:16 UTC 2024
Removing old libraries
g1-48(14.0-S)[5]

(The ">>> Removing old libraries" is an artifact from "make
delete-old-libs", which I do on the first reboot after a build.)
Post by Mark Millard
World built in 2351 seconds, ncpu: 8, make -j16
World built in 116 seconds, ncpu: 8, make -j16
World built in 124 seconds, ncpu: 8, make -j16
I suggest that -- within *this* "experiment's" error -- 116 sec is not
significantly different from 124 sec, but that 2351 sec is significantly
different from either.
Post by Mark Millard
....
Peace,
david
--
David H. Wolfskill ***@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
David Wolfskill
2024-01-29 01:33:49 UTC
Permalink
Post by Mark Millard
...
Post by David Wolfskill
As it happens, I rather fumble-fingered the (intended) reboot on the 2nd
laptop (and started another rebuild instead).
And I do these within script(1), as it's handy to have a record.
Note that this differes from the sequence you cite above, in that I
failed to do the reboot.
So I powered it back up and -- without updating sources (or the local
repo mirror, for that matter) -- did another rebuild.
I'm having trouble identifying the detailed sequencing
being reported below.
installworld
buidlworld
buildworld
buildworld
. .
Will only take large times for the first one
(potentially).
I have not done that.
Post by Mark Millard
installworld
buidlworld
installworld
buildworld
installworld
buildworld
. .
Can have each buildworld take large times
depending the the details involved.
As documented at https://www.catwhisker.org/~david/FreeBSD/upgrade.html,
each "build" is (essentially) the set of steps in src/UPDATING under "To
rebuild everything and install it on the current system." starting with
"make buildworld" up to (and including) "make delete-old" (without the
"<reboot in single user>" step).
Post by Mark Millard
I need to understand more about what happened
before each buildworld on each machine to know
what sort of timestamp relationships are
involved for files. installworld can
significantly change various timestamp
relationships.
I have placed a copy of the complete typescript at
https://www.catwhisker.org/~david/FreeBSD/stable_14/build_typescript.txt.
Post by Mark Millard
Post by David Wolfskill
g1-48(14.0-S)[4] egrep ' built in |Installing .* (started|completed)|Removing old libraries| stable/14-n' s1
World built in 2351 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c, with no other
buidlworlds after the installworld?
Yes; that's how stable/14-n266551-63a7e799b32c came to be the running
system.

Oh: perhaps of interest: I'm not using boot environments. All of this
is with UFS (well, UFS2+soft updates).
Post by Mark Millard
(I'm wording for major steps or my description
the possibilities would get rather complicated
and large.)
Post by David Wolfskill
Kernel(s) CANARY built in 898 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:25:27 UTC 2024
Installing everything started on Sun Jan 28 12:25:57 UTC 2024
Installing everything completed on Sun Jan 28 12:28:01 UTC 2024
World built in 116 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c, with no other
buidlworlds after the installworld?
Is the answer different here?
No reboots -- as mentioned, I intended to reboot, but instead initiated
the build sequence.
Post by Mark Millard
Post by David Wolfskill
Kernel(s) CANARY built in 920 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:47:55 UTC 2024
Installing everything started on Sun Jan 28 12:48:25 UTC 2024
Installing everything completed on Sun Jan 28 12:50:01 UTC 2024
Removing old libraries
World built in 124 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c with no other
buidlworlds after the, installworld?
Where you see ">>>> Removing old libraries", there was a reboot just
before that. And only then.
Post by Mark Millard
Post by David Wolfskill
Kernel(s) CANARY built in 901 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 23:34:39 UTC 2024
Installing everything started on Sun Jan 28 23:35:09 UTC 2024
Installing everything completed on Sun Jan 28 23:37:16 UTC 2024
Removing old libraries
g1-48(14.0-S)[5]
(The ">>> Removing old libraries" is an artifact from "make
delete-old-libs", which I do on the first reboot after a build.)
World built in 2351 seconds, ncpu: 8, make -j16
World built in 116 seconds, ncpu: 8, make -j16
World built in 124 seconds, ncpu: 8, make -j16
I suggest that -- within *this* "experiment's" error -- 116 sec is not
significantly different from 124 sec, but that 2351 sec is significantly
different from either.
....
===
Mark Millard
marklmi at yahoo.com
....
Peace,
david
--
David H. Wolfskill ***@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Mark Millard
2024-01-28 23:00:59 UTC
Permalink
Post by Mark Millard
554: 5.7.1 ]
Post by David Wolfskill
Post by Mark Millard
...
Post by David Wolfskill
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.
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.
Post by Mark Millard
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".
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
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.
Post by David Wolfskill
Post by Mark Millard
(The below had to be written without understanding
of such things.)
Here is an example META_MODE line recording a
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 .
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.
Post by David Wolfskill
Post by Mark Millard
There are other examples of recorded paths to tools
in .meta file, such as (my old context example
/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk
So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file
....
Right; after some discussion with Simon and/or Bryan (back on 08 July
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
PORTS_MODULES+=x11/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?
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.

===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mark Millard
2024-01-29 01:13:24 UTC
Permalink
Post by David Wolfskill
Post by Mark Millard
...
A) You built (META_MODE): 63a7e799b32c
B) You installed: 63a7e799b32c
C) You rebooted into: 63a7e799b32c
D) build again (still META_MODE): 63a7e799b32c
would have rebuilt llvm at that point, the
time-relationship cause(s) being set up
during (B).
As it happens, I rather fumble-fingered the (intended) reboot on the 2nd
laptop (and started another rebuild instead).
And I do these within script(1), as it's handy to have a record.
Note that this differes from the sequence you cite above, in that I
failed to do the reboot.
So I powered it back up and -- without updating sources (or the local
repo mirror, for that matter) -- did another rebuild.
I'm having trouble identifying the detailed sequencing
being reported below.

Doing on one machine:
installworld
buidlworld
buildworld
buildworld
. .

Will only take large times for the first one
(potentially).

But doing:
installworld
buidlworld
installworld
buildworld
installworld
buildworld
. .

Can have each buildworld take large times
depending the the details involved.

I need to understand more about what happened
before each buildworld on each machine to know
what sort of timestamp relationships are
involved for files. installworld can
significantly change various timestamp
relationships.
Post by David Wolfskill
g1-48(14.0-S)[4] egrep ' built in |Installing .* (started|completed)|Removing old libraries| stable/14-n' s1
Post by Mark Millard
World built in 2351 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c, with no other
buidlworlds after the installworld?

(I'm wording for major steps or my description
the possibilities would get rather complicated
and large.)
Post by David Wolfskill
Post by Mark Millard
Kernel(s) CANARY built in 898 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:25:27 UTC 2024
Installing everything started on Sun Jan 28 12:25:57 UTC 2024
Installing everything completed on Sun Jan 28 12:28:01 UTC 2024
World built in 116 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c, with no other
buidlworlds after the installworld?

Is the answer different here?
Post by David Wolfskill
Post by Mark Millard
Kernel(s) CANARY built in 920 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 12:47:55 UTC 2024
Installing everything started on Sun Jan 28 12:48:25 UTC 2024
Installing everything completed on Sun Jan 28 12:50:01 UTC 2024
Removing old libraries
World built in 124 seconds, ncpu: 8, make -j16
Was a prior step (ignoring reboots, say) an
installworld of 63a7e799b32c with no other
buidlworlds after the, installworld?
Post by David Wolfskill
Post by Mark Millard
Kernel(s) CANARY built in 901 seconds, ncpu: 8, make -j16
Installing kernel CANARY completed on Sun Jan 28 23:34:39 UTC 2024
Installing everything started on Sun Jan 28 23:35:09 UTC 2024
Installing everything completed on Sun Jan 28 23:37:16 UTC 2024
Removing old libraries
g1-48(14.0-S)[5]
(The ">>> Removing old libraries" is an artifact from "make
delete-old-libs", which I do on the first reboot after a build.)
Post by Mark Millard
World built in 2351 seconds, ncpu: 8, make -j16
World built in 116 seconds, ncpu: 8, make -j16
World built in 124 seconds, ncpu: 8, make -j16
I suggest that -- within *this* "experiment's" error -- 116 sec is not
significantly different from 124 sec, but that 2351 sec is significantly
different from either.
....
===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mark Millard
2024-01-29 04:55:43 UTC
Permalink
[I cut out the history to start clean.]

So 63a7e799b32c was already built and installed as of here, from what
I can tell. This example does not show the 1c090bf880bf -> 63a7e799b32c
transition, only after 63a7e799b32c is already built and installed.

So, up to this point:

buildworld 63a7e799b32c
installworld 63a7e799b32c
NOTE: As of here various tools and such no loner have the
timestamps they had from 1c090bf880bf.
reboot into 63a7e799b32c

~/Downloads/build_typescript.txt:10: 63a7e799b32c..2ee407b6068a stable/14 -> origin/stable/14

So all the following build activity is building of
2ee407b6068a, not 63a7e799b32c directly, but the
timestamp relationships changed as mentioned above
cause various things to rebuild, despite lack of
source code updates being involved.

~/Downloads/build_typescript.txt:45: FreeBSD g1-48.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #38 stable/14-n266551-63a7e799b32c: Sat Jan 27 11:40:05 UTC 2024 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400506 1400506

I'll note that without a reboot the notation will stay
"stable/14-n266551-63a7e799b32c", even after 2ee407b6068a
is installed: it reports the operating kernel's hash, not
the installed kernel's hash.

~/Downloads/build_typescript.txt:51: >>> World build started on Sun Jan 28 11:30:47 UTC 2024
~/Downloads/build_typescript.txt:19709: >>> World built in 2351 seconds, ncpu: 8, make -j16

So, up to this point (extending the prior list):

buildworld 63a7e799b32c
installworld 63a7e799b32c
NOTE: As of here various tools and such no loner have the
timestamps they had from 1c090bf880bf.
reboot into 63a7e799b32c
Update source to 2ee407b6068a
buildworld 2ee407b6068a
NOTE: As of here more than just the changes for
2ee407b6068a have rebuilt. But it need not
be everything that built originally for
63a7e799b32c. The details will matter
later for the consequences.

I claim that without the "Update source to"
this would still have taken around 2000 sec
because of the installworld of the 63a7e799b32c
materials: the things are reinstalled that
caused the original (not shown) llvm rebuild
and such that took the original (not shown)
time.

Installworld of 2ee407b6068a will be very
different for what is not changed at all
(and so does not get new timestamps from
the install). But at this point a subset
of 63a7e799b32c also got rebuilds and, so,
new timestamps for the next installworld
to put in place.

I'll note that, while 2351 sec is a lot of
activity, the number of files that will be
installed is not likely to be in direct
proportion to the build time. For example,
large files from llvm.

I'll note that without the -dM option, the make
is not explicit about the timestamp relationships
that it used to pick what to rebuild. No specific
evidence for that is present.

~/Downloads/build_typescript.txt:39267: >>> Kernel(s) CANARY built in 898 seconds, ncpu: 8, make -j16
~/Downloads/build_typescript.txt:39274: >>> Installing kernel CANARY on Sun Jan 28 12:24:57 UTC 2024
~/Downloads/build_typescript.txt:42089: >>> Installing kernel CANARY completed on Sun Jan 28 12:25:27 UTC 2024

installkernel does not change notable timestamp relationships of
tools and such vs. other files.

~/Downloads/build_typescript.txt:42988: >>> Installing everything started on Sun Jan 28 12:25:57 UTC 2024
~/Downloads/build_typescript.txt:81798: >>> Installing everything completed on Sun Jan 28 12:28:01 UTC 2024

This is going to get new timestamps based on 2ee407b6068a
changes and based on the partial rebuild of 63a7e799b32c,
so more than just what 2ee407b6068a would update on its own.
But it is not obvious how many of the partial rebuild of
63a7e799b32c material would touch something that leads to
future rebuilds: likely far less but possibly not zero.

~/Downloads/build_typescript.txt:82482: To remove old libraries run 'make delete-old-libs'.
~/Downloads/build_typescript.txt:82483: >> make delete-old OK
~/Downloads/build_typescript.txt:82537: FreeBSD g1-48.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #38 stable/14-n266551-63a7e799b32c: Sat Jan 27 11:40:05 UTC 2024 ***@g1-r8.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400506 1400506

No reboot, so it did not report 2ee407b6068a, despite it
being built and installed (along with rebuilding and
reinstalling some 63a7e799b32c material).

~/Downloads/build_typescript.txt:82543: >>> World build started on Sun Jan 28 12:30:11 UTC 2024
~/Downloads/build_typescript.txt:100102: >>> World built in 116 seconds, ncpu: 8, make -j16

The timestamps from the partial 63a7e799b32c rebuild and
the 2ee407b6068a build activity are involved in determining
what gets rebuilt above. 2ee407b6068a does not contribute
much here. It is unclear how much the partial rebuild of
63a7e799b32c contributes to timestamps that would cause
more rebuilds. The 116 sec indicates: not much gets new
timestamps this time.

~/Downloads/build_typescript.txt:119629: >>> Kernel(s) CANARY built in 920 seconds, ncpu: 8, make -j16
~/Downloads/build_typescript.txt:119636: >>> Installing kernel CANARY on Sun Jan 28 12:47:27 UTC 2024
~/Downloads/build_typescript.txt:122450: >>> Installing kernel CANARY completed on Sun Jan 28 12:47:55 UTC 2024

installkernel does not change notable timestamp relationships of
tools and such vs. other files.

~/Downloads/build_typescript.txt:123346: >>> Installing everything started on Sun Jan 28 12:48:25 UTC 2024
~/Downloads/build_typescript.txt:162156: >>> Installing everything completed on Sun Jan 28 12:50:01 UTC 2024

This install's both the partial-63a7e799b32c-rebuild material
and the 2ee407b6068a material. The 116 sec figure suggests that
there is not man files with updated timestamps.

A reboot is involved here (or just below), so 2ee407b6068a will show up.

~/Downloads/build_typescript.txt:162840: To remove old libraries run 'make delete-old-libs'.
~/Downloads/build_typescript.txt:162841: >> make delete-old OK
~/Downloads/build_typescript.txt:162895: FreeBSD g1-48.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #40 stable/14-n266554-2ee407b6068a: Sun Jan 28 12:39:17 UTC 2024 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400506 1400506

The 2ee407b6068a kernel now shows as being in operation.

~/Downloads/build_typescript.txt:162897: >>> Removing old libraries
~/Downloads/build_typescript.txt:162932: FreeBSD g1-48.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #40 stable/14-n266554-2ee407b6068a: Sun Jan 28 12:39:17 UTC 2024 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400506 1400506

Still 2ee407b6068a.

~/Downloads/build_typescript.txt:162938: >>> World build started on Sun Jan 28 23:17:05 UTC 2024
~/Downloads/build_typescript.txt:180497: >>> World built in 124 seconds, ncpu: 8, make -j16

It is possible here that little or no 63a7e799b32c related
timestamp changes that lead to rebuild activity were involved
in the above buildworld . It depends on the details of what
was rebuilt. the 116 sec and 124 sec figures both suggest:
no much overall.

~/Downloads/build_typescript.txt:200023: >>> Kernel(s) CANARY built in 901 seconds, ncpu: 8, make -j16
~/Downloads/build_typescript.txt:200030: >>> Installing kernel CANARY on Sun Jan 28 23:34:11 UTC 2024
~/Downloads/build_typescript.txt:202844: >>> Installing kernel CANARY completed on Sun Jan 28 23:34:39 UTC 2024

installkernel does not change notable timestamp relationships of
tools and such vs. other files.

~/Downloads/build_typescript.txt:203743: >>> Installing everything started on Sun Jan 28 23:35:09 UTC 2024
~/Downloads/build_typescript.txt:242553: >>> Installing everything completed on Sun Jan 28 23:37:16 UTC 2024

2ee407b6068a will still show up after the the reboot.

~/Downloads/build_typescript.txt:243237: To remove old libraries run 'make delete-old-libs'.
~/Downloads/build_typescript.txt:243238: >> make delete-old OK
~/Downloads/build_typescript.txt:243292: FreeBSD g1-48.catwhisker.org 14.0-STABLE FreeBSD 14.0-STABLE #41 stable/14-n266554-2ee407b6068a: Sun Jan 28 23:26:10 UTC 2024 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400506 1400506

Yep, still 2ee407b6068a.

~/Downloads/build_typescript.txt:243294: >>> Removing old libraries


Overall this sequence fits what I expect. The above wording is
more detailed than my earlier quick summaries.


===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mark Millard
2024-01-28 18:20:30 UTC
Permalink
Post by David Wolfskill
Post by Mark Millard
...
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.
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.
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/usr/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/usr/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/usr/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.html

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.)
Post by David Wolfskill
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.
Post by David Wolfskill
So if "make installworld" messes with anything that META_MODE cares
about ... that would appear to be somewhat surprising.
See above.
Post by David Wolfskill
Mind, I've been wrong before, and I do intend to live long enough to be
wrong again.... :-)
Post by Mark Millard
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.
....
Hmm.... Thanks again.
===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Wolfskill
2024-01-28 22:06:01 UTC
Permalink
Post by Mark Millard
...
Post by David Wolfskill
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.
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.
Post by Mark Millard
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".
Post by Mark Millard
(The below had to be written without understanding
of such things.)
Here is an example META_MODE line recording a
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 .
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.
Post by Mark Millard
There are other examples of recorded paths to tools
in .meta file, such as (my old context example
/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk
So if /usr/obj/. . ./tmp/legacy/usr/sbin/awk is newer than the file
....
Right; after some discussion with Simon and/or Bryan (back on 08 July
2017), I augmented /etc/src.conf on the laptops to include:

.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d

because I (also) had:

PORTS_MODULES+=x11/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
--
David H. Wolfskill ***@catwhisker.org
Do these ends really justify those means?

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Mark Millard
2024-01-29 18:07:18 UTC
Permalink
Post by Alexander Leidinger
Post by Mark Millard
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.
Not -stable, but -current
Sequence going back to where a commit change was involved and
installed/booted? That older commit was what? The newer one?
The content of that change contributes to what range of "is
newer than" stuff shows up in the first buildworld after the
first installworld-then-reboot to the newer commit.

A limiting case is doing a buildworld into an empty /usr/obj/
like area so that its later install has everything freshly
built (new timestamps) compared to the prior context. Then
doing a installworld buildworld sequence may have more "is
newer than" notices. (Some cases of updates approximate
such a "largely rebuilt" status, others do not.)

The list is illustrative as is, just possibly not definitive.
Post by Alexander Leidinger
# grep newer buildworld_debug.log | grep -E 'amd64.amd64/tmp/(usr|legacy)/' | cut -d : -f 3 | sort -u
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/include/roken.h' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/asn1_compile' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/awk' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/basename' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cap_mkdb' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cat' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/clang-tblgen' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/compile_et' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cp' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchgen' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchide' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/dd' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/env' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/file2c' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gencat' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/grep' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gzip' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/jot' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lex' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lldb-tblgen' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-min-tblgen' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-tblgen' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/ln' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/m4' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/make-roken' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkcsmapper' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkesdb' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mv' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/rm' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sed' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sh' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/touch' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/truncate' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uudecode' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uuencode' is newer than the target...
file '/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/usr/bin/objcopy' is newer than the target...
There is no dependency to outside the obj tree.
Would it make sense to exclude the tmp/legacy/usr/sbin/... dependencies? Or a subset? The tmp/usr/bin/objcopy is probably in the middle of a rebuild, but the name legacy gives the impression that not a lot of features are needed from those (basics to build our own version?).
Note, grep for "newer" gives >12000 hits.
For awk, basename, cat, dd, env, grep, gzip, lex, ln, m4, mv, rm,
sed, sh, touch, truncate, uudecode, and uuenncode (for example):

The "is newer than" status is both real and highly likely to be
irrelevant. META_MODE is based on just the "real" status of "is
newer than".

There are other items in the list that I'd be less sure of if
they are likely to always be irrelevant. Possibly.

As I remember, I did get example "is newer than" notices that
were not from /usr/obj/ like areas, not that I remember the
details any more. (So I could be misremembering.)

===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Alexander Leidinger
2024-01-30 06:56:19 UTC
Permalink
On Jan 29, 2024, at 01:50, Alexander Leidinger
Post by Alexander Leidinger
Post by Mark Millard
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.
Not -stable, but -current
Sequence going back to where a commit change was involved and
installed/booted? That older commit was what? The newer one?
The content of that change contributes to what range of "is
newer than" stuff shows up in the first buildworld after the
first installworld-then-reboot to the newer commit.
The sequence was:
- make update
- make buildworld buildkernel
- create new BE
- make installworld installkernel into the new BE
- boot the new BE
- do nothing with src for some days
- read your mail
- make -Dm buildworld
A limiting case is doing a buildworld into an empty /usr/obj/
like area so that its later install has everything freshly
built (new timestamps) compared to the prior context. Then
doing a installworld buildworld sequence may have more "is
newer than" notices. (Some cases of updates approximate
such a "largely rebuilt" status, others do not.)
The list is illustrative as is, just possibly not definitive.
Post by Alexander Leidinger
# grep newer buildworld_debug.log | grep -E
'amd64.amd64/tmp/(usr|legacy)/' | cut -d : -f 3 | sort -u
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/include/roken.h'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/asn1_compile'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/awk'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/basename'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cap_mkdb'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cat'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/clang-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/compile_et'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cp'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchide'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/dd'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/env'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/file2c'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gencat'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/grep'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gzip'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/jot'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lex'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lldb-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-min-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/ln'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/m4'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/make-roken'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkcsmapper'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkesdb'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mv'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/rm'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sed'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sh'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/touch'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/truncate'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uudecode'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uuencode'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/usr/bin/objcopy'
is newer than the target...
There is no dependency to outside the obj tree.
Would it make sense to exclude the tmp/legacy/usr/sbin/...
dependencies? Or a subset? The tmp/usr/bin/objcopy is probably in the
middle of a rebuild, but the name legacy gives the impression that not
a lot of features are needed from those (basics to build our own
version?).
Note, grep for "newer" gives >12000 hits.
For awk, basename, cat, dd, env, grep, gzip, lex, ln, m4, mv, rm,
The "is newer than" status is both real and highly likely to be
irrelevant. META_MODE is based on just the "real" status of "is
newer than".
There are other items in the list that I'd be less sure of if
they are likely to always be irrelevant. Possibly.
The lldvm/lldb/clang ones may be related to a rebuild of llvm triggered
by irrelevant time changes according to your description. I haven't
found "is newer than" evidence in the debug output why those legacy ones
are newer. If I assume those are touched by installworld, we could do
maybe some kind of check if checksums are equal and not install into
legacy if they are. This would then require more work on install, but
may result in less work on buildworld.
As I remember, I did get example "is newer than" notices that
were not from /usr/obj/ like areas, not that I remember the
details any more. (So I could be misremembering.)
Maybe in the installworld stage /usr/sbin/sh newer than
OBJDIR/..../legacy/usr/sbin/sh?

Bye,
Alexander.
--
http://www.Leidinger.net ***@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org ***@FreeBSD.org : PGP 0x8F31830F9F2772BF
Alexander Leidinger
2024-01-29 09:50:18 UTC
Permalink
Post by Mark Millard
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.
Not -stable, but -current (no change to src, buildworld after
installworld to a new BE and booting this new BE):
# grep newer buildworld_debug.log | grep -E
'amd64.amd64/tmp/(usr|legacy)/' | cut -d : -f 3 | sort -u
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/include/roken.h'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/asn1_compile'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/awk'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/basename'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cap_mkdb'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cat'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/clang-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/compile_et'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/cp'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/crunchide'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/dd'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/env'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/file2c'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gencat'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/grep'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/gzip'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/jot'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lex'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/lldb-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-min-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/llvm-tblgen'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/ln'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/m4'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/make-roken'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkcsmapper'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mkesdb'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/mv'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/rm'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sed'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/sh'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/touch'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/truncate'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uudecode'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/legacy/usr/sbin/uuencode'
is newer than the target...
file
'/space/system/usr_obj/space/system/usr_src/amd64.amd64/tmp/usr/bin/objcopy'
is newer than the target...

There is no dependency to outside the obj tree.

Would it make sense to exclude the tmp/legacy/usr/sbin/... dependencies?
Or a subset? The tmp/usr/bin/objcopy is probably in the middle of a
rebuild, but the name legacy gives the impression that not a lot of
features are needed from those (basics to build our own version?).

Note, grep for "newer" gives >12000 hits.

Bye,
Alexander.
--
http://www.Leidinger.net ***@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org ***@FreeBSD.org : PGP 0x8F31830F9F2772BF
Loading...