From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Li Wang" <liwang@redhat.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 2/2] lib: Extend LTP_ENABLE_DEBUG to support verbosity levels
Date: Tue, 03 Mar 2026 10:28:24 +0000 [thread overview]
Message-ID: <69a6b7c9.df0a0220.2ea96.efef@mx.google.com> (raw)
In-Reply-To: <20260303032311.38988-2-liwang@redhat.com>
Hi Li,
I ran a review with my LLM config and obtained the following report.
I thought it was interesting to share how the LTP review agent I'm
developing is growing. Tested with Claude Sonnet 4.6
Issues Found
1. "Enabling debug info" printed for level 0 — misleading message
(still unaddressed from v1)
Both -D0 and LTP_ENABLE_DEBUG=0 print "Enabling debug info (level 0)",
which is the opposite of what is happening. Level 0 means disable all
debug output. This was raised in the v1 review and remains unfixed.
$ ./getpid01 -D0
tst_test.c:833: TINFO: Enabling debug info (level 0)
Additionally, LTP_ENABLE_DEBUG=0 is a behavior regression: previously
it was silently ignored (no output), now it prints a misleading "Enabling"
message. The fix for the -D path is to guard the message:
if (context->tdebug)
tst_res(TINFO, "Enabling debug info (level %d)", context->tdebug);
Same fix needed in the env var path.
2. LTP_ENABLE_DEBUG still silently overrides a more specific -D flag
— core ordering issue unfixed from v1
The env var check runs after parse_opts(), so LTP_ENABLE_DEBUG always
wins over the command-line -D flag:
$ LTP_ENABLE_DEBUG=1 ./getpid01 -D2
tst_test.c:833: TINFO: Enabling debug info (level 2) ← from -D2
tst_test.c:1457: TINFO: Enabling debug info (level 1) ← env var overrides!
And even disabling via the env var overrides an explicit command-line enable:
$ LTP_ENABLE_DEBUG=0 ./getpid01 -D2
tst_test.c:833: TINFO: Enabling debug info (level 2) ← from -D2
tst_test.c:1457: TINFO: Enabling debug info (level 0) ← env var kills it
Command-line should take precedence over environment variables. The
fix is to skip the env var assignment when -D was already used:
if (tdebug_env && !context->tdebug) { /* only if -D wasn't passed */
...
}
Or, more robustly, check the env var before parse_opts() so the
command-line naturally wins.
Point 1. is clearly true, the Point 2. might be a design choice. I don't
mind the priority of command line or env variable, but it's actually
correct to assume that env should be skipped if -D is defined.
Kind regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-03 10:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 3:23 [LTP] [PATCH v2 1/2] lib: Extend -D flag to support multiple debug levels Li Wang via ltp
2026-03-03 3:23 ` [LTP] [PATCH v2 2/2] lib: Extend LTP_ENABLE_DEBUG to support verbosity levels Li Wang via ltp
2026-03-03 10:28 ` Andrea Cervesato via ltp [this message]
2026-03-03 14:02 ` Li Wang via ltp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69a6b7c9.df0a0220.2ea96.efef@mx.google.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=liwang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.