t0213: skip ancestry tests under user-mode emulation
PATCH 1/1 t0213: skip ancestry tests under user-mode emulation
From: Jamie Magee <[email protected]>
The tests added in 3c8c638df6 (t0213: add trace2 cmd_ancestry tests, 2026-02-13) expect the cmd_ancestry event to name "test-tool" and "git". On Linux those names come from the "comm" field of /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc reports the emulator ("qemu-riscv64") instead, so the event is still emitted, the TRACE2_ANCESTRY probe enables the tests, and tests 2-5 fail even though they pass on native riscv64.
Require the probe to see "test-tool" in the ancestry of a test-tool spawned from test-tool, so the tests skip when the names are unreliable.
---
t0213: skip ancestry tests under user-mode emulation
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2168%2FJamieMagee%2Ft0213-skip-under-emulation-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2168/JamieMagee/t0213-skip-under-emulation-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2168
t/t0213-trace2-ancestry.sh | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
t/t0213-trace2-ancestry.sh +6 -3
@@ -31,12 +31,15 @@ PATH="$TTDIR:$PATH" && export PATH # no cmd_ancestry event is emitted. We detect this at runtime and # skip the format-specific tests accordingly. -# Determine if cmd_ancestry is supported on this platform. +# Enable these tests only when cmd_ancestry reports real process names. +# The procinfo stub emits no event; under user-mode emulation (e.g. +# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool +# from test-tool and require "test-tool" in the child's ancestry. test_expect_success 'detect cmd_ancestry support' ' test_when_finished "rm -f trace.detect" && GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \ - test-tool trace2 001return 0 && - if grep -q "^cmd_ancestry" trace.detect + test-tool trace2 004child test-tool trace2 001return 0 && + if grep -q "^cmd_ancestry.*test-tool" trace.detect then test_set_prereq TRACE2_ANCESTRY fi
base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc
Signature · 1 line
gitgitgadget
t/t0213-trace2-ancestry.sh PATH="$TTDIR:$PATH" && export PATH · line 37
Quoted 5 lines · Jamie Magee via GitGitGadget
t/t0213-trace2-ancestry.sh +4
-1-# Determine if cmd_ancestry is supported on this platform. +# Enable these tests only when cmd_ancestry reports real process names. +# The procinfo stub emits no event; under user-mode emulation (e.g. +# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool +# from test-tool and require "test-tool" in the child's ancestry.
T.r.i.c.k.y. ;-)
t/t0213-trace2-ancestry.sh PATH="$TTDIR:$PATH" && export PATH · line 42
Quoted 7 lines
test_expect_success'detectcmd_ancestrysupport' 't/t0213-trace2-ancestry.sh +2
-2test_when_finished "rm -f trace.detect" && GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \ - test-tool trace2 001return 0 && - if grep -q "^cmd_ancestry" trace.detect + test-tool trace2 004child test-tool trace2 001return 0 && + if grep -q "^cmd_ancestry.*test-tool" trace.detect
This will be happy even if "test-tool-trash" that happens to have "test-tool" as its prefix appears on a cmd_ancestry line (for that matter, things like "cmd_ancestry-not-quite" that has "cmd_ancestry" as its prefix would be accepted). I guess that is OK because we are testing this in a fairly tightly controlled environment (trace keys are taken from known vocabulary, not arbitrary strings, for example).
Will queue. Thanks.
Quoted 5 lines
t/t0213-trace2-ancestry.sh +0
-0then test_set_prereq TRACE2_ANCESTRY fibase-commit:
e9019fcafe0040228b8631c30f97ae1adb61bcdc
Quoted 25 lines · Junio C Hamano
t/t0213-trace2-ancestry.sh PATH="$TTDIR:$PATH" && export PATH · line 37
Quoted 5 lines · Jamie Magee via GitGitGadget
t/t0213-trace2-ancestry.sh +4
-1-# Determine if cmd_ancestry is supported on this platform. +# Enable these tests only when cmd_ancestry reports real process names. +# The procinfo stub emits no event; under user-mode emulation (e.g. +# qemu-user) /proc reports the emulator, not the guest. Spawn test-tool +# from test-tool and require "test-tool" in the child's ancestry.T.r.i.c.k.y. ;-)
t/t0213-trace2-ancestry.sh PATH="$TTDIR:$PATH" && export PATH · line 42
Quoted 7 lines
test_expect_success'detectcmd_ancestrysupport' 't/t0213-trace2-ancestry.sh +2
-2test_when_finished "rm -f trace.detect" && GIT_TRACE2_BRIEF=1 GIT_TRACE2="$(pwd)/trace.detect" \ - test-tool trace2 001return 0 && - if grep -q "^cmd_ancestry" trace.detect + test-tool trace2 004child test-tool trace2 001return 0 && + if grep -q "^cmd_ancestry.*test-tool" trace.detectThis will be happy even if "test-tool-trash" that happens to have "test-tool" as its prefix appears on a
cmd_ancestryline (for that matter, things like "cmd_ancestry-not-quite" that has "cmd_ancestry" as its prefix would be accepted). I guess that is OK because we are testing this in a fairly tightly controlled environment (trace keys are taken from known vocabulary, not arbitrary strings, for example).
Quoted 1 line
Will queue. Thanks.
Just to clarify, 'Will queue' simply means that the patch will appear in 'seen'. It does not imply that I have personally reviewed the change and found it acceptable to merge into 'next'.
I would appreciate a review from someone familiar with the trace2 facility.
Thanks.
Quoted 10 lines · Jamie Magee via GitGitGadget
From: Jamie Magee <[email protected]>
The tests added in
3c8c638df6(t0213: add trace2cmd_ancestrytests, 2026-02-13) expect thecmd_ancestryevent to name "test-tool" and "git". On Linux those names come from the "comm" field of /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc reports the emulator ("qemu-riscv64") instead, so the event is still emitted, theTRACE2_ANCESTRYprobe enables the tests, and tests 2-5 fail even though they pass on native riscv64.
Quoted 6 lines
Require the probe to see "test-tool" in the ancestry of a test-tool spawned from test-tool, so the tests skip when the names are unreliable.
Cc Matthew John Cheetham <[email protected]>Signed-off-by Jamie Magee <[email protected]>---
Very sorry to say something completely outside the patch.
But may I ask what's the point of writting the line started with "Cc:"? I know that Linux kernel has something about writting Cc in the commit message, while I don't see much from Git's documentation about trailers, including MyFirstContribution and SubmittingPatches. Although I know that "git send-email" and "git interpret-trailers" could use "Cc:", I still wonder whether using this trailer is encouraged or not. If so, adding some decriptions about it would be nice, I guess, since I was confused when reading kernel docs about using Cc trailers in the commit message sometime ago.
Sorry in advance if I missed any context.
Thanks very much.
Quoted 5 lines · Weijie Yuan
Quoted 4 lines
...
Cc Matthew John Cheetham <[email protected]>Signed-off-by Jamie Magee <[email protected]>---
Quoted 7 lines
Very sorry to say something completely outside the patch.
But may I ask what's the point of writting the line started with "Cc:"?
...
I know that Linux kernel has something about writting Cc in the commit message, while I don't see much from Git's documentation about trailers, including MyFirstContribution and SubmittingPatches.
If you ask me, 'Cc:' belongs in e-mail headers, not in commit messages, though the Linux kernel community has a different convention.
GitGitGadget collects 'Cc:' lines from the commit message and, when sending e-mails on behalf of the author, copies the recipients listed there, if I am not mistaken. Thus, it is not surprising that contributors use the trailer for that purpose.
We do not use the 'Cc:' trailer to allow a commit author to say, "As the commit object indicates, I CC'd this change to that expert. I am no longer solely responsible for any bugs in this commit. That expert should have caught my mistake!" ;-)
Thanks.
Quoted 15 lines · Junio C Hamano
Quoted 5 lines · Weijie Yuan
Quoted 4 lines
...
Cc Matthew John Cheetham <[email protected]>Signed-off-by Jamie Magee <[email protected]>---
Quoted 7 lines
Very sorry to say something completely outside the patch.
But may I ask what's the point of writting the line started with "Cc:"?
...
I know that Linux kernel has something about writting Cc in the commit message, while I don't see much from Git's documentation about trailers, including MyFirstContribution and SubmittingPatches.
Quoted 8 lines
If you ask me, 'Cc:' belongs in e-mail headers, not in commit messages, though the Linux kernel community has a different convention.
GitGitGadget collects 'Cc:' lines from the commit message and, when sending e-mails on behalf of the author, copies the recipients listed there, if I am not mistaken. Thus, it is not surprising that contributors use the trailer for that purpose.
Yeah, I noticed that this patch was sent bt GGG. But since he has already added "Cc" at the end of the commit message, yet in the actual email header, there is no "Matthew John Cheetham", which was confusing? This is something I forgot to mention in the previous email, sorry.
I may have to take a closer look at GGG later.
Quoted 4 lines
We do not use the 'Cc:' trailer to allow a commit author to say, "As the commit object indicates, I CC'd this change to that expert. I am no longer solely responsible for any bugs in this commit. That expert should have caught my mistake!" ;-)
;-) I agree!
Thanks!
Quoted 10 lines · Jamie Magee via GitGitGadget
From: Jamie Magee <[email protected]>
The tests added in
3c8c638df6(t0213: add trace2cmd_ancestrytests, 2026-02-13) expect thecmd_ancestryevent to name "test-tool" and "git". On Linux those names come from the "comm" field of /proc/<pid>/stat. Under user-mode emulation (e.g. qemu-user) /proc reports the emulator ("qemu-riscv64") instead, so the event is still emitted, theTRACE2_ANCESTRYprobe enables the tests, and tests 2-5 fail even though they pass on native riscv64.
Quoted 7 lines
Require the probe to see "test-tool" in the ancestry of a test-tool spawned from test-tool, so the tests skip when the names are unreliable.
Cc Matthew John Cheetham <[email protected]>Signed-off-by Jamie Magee <[email protected]>---
t0213: skip ancestry tests under user-mode emulation
While nobody with similar environment that would benefit from this change has stepped up since this patch was posted almost a month ago (and I do not have such an environment to test it on, either), this seems low impact enough to cause regressions in environments where the change does not intend to affect (i.e., native environments where process names are trustworthy).
So I am tempted to merge this down, only if it is to shrink the number of in-flight topics I have to carry and watch out for updates, as nobody seems to be motivated enough to recruit testers or reviewers to move the topic forward.
Those who are not in the user-mode emulation environment and are negatively affected because this patch drops TRACE2_ANCESTRY from your envionment should block me with a real review on the patch, preferrably with suggested improvements.
Thanks.