Re: [Valgrind-developers] [LTP] Proposal for new LTP config knob: LTP_QUIET

[Martin C. <mc...@re...>]

On  Wed  2025-09-17  13:30 , Petr Vorel wrote:
> > On  Wed  2025-09-17  12:37 , Petr Vorel wrote:
> > > Hi Martin,
> 
> > > > Hi folks,
> 
> > > > some time back, LTP_REPRODUCIBLE_OUTPUT was introduced in LTP.
> > > > I'd like to propose a new, related LTP knob for our Valgrind
> > > > test automation purposes: LTP_QUIET.  See attached patch.
> 
> > > > LTP_QUIET is supposed to suppress certain types of test output
> > > > messages, such as: TCONF, TWARN, TINFO, and TDEBUG.  This would
> > > > help us keep our test logs briefer, while still keeping the
> > > > information we need in the logs.
> 
> > > > Please, consider merging upstream.
> 
> > > Thanks for contributing this. So the point is to have only the final summary
> > > printed, right? (summary of TCONF/TWARN/TBROK/...).
> 
> > > I'm ok for merging this + to introduce the same for shell API (tst_test.sh),
> > > although you in valgrind don't use it.  And we could even introduce '-q' getopt
> > > (easier for manual debugging).
> 
> > > Do we then want to keep the "reproducible output" part? Or should it quiet
> > > replace it?
> 
> > Hi Petr,  you are right that these two knobs (LTP_QUIET and
> > LTP_REPRODUCIBLE_OUTPUT) partly overlap.  In my proposal, LTP_QUIET
> > doesn't silence everything.  It does silence TCONF, TWARN, TINFO,
> > and TDEBUG messages.  But it keeps TPASS, TFAIL, and TBROK.
> 
> Ah, correct (I was wrong). If there were users who need to separate these (i.e.
> using just single of these) I would keep it separate. But IMHO you valgrind
> folks are the only ones who use it, therefore feel free to modify it to fix your
> needs. OTOH, if you're ok to using 2 variables, I guess we are ok to have both.
> Let's see what others think (Andrea already acked).
> 
> > Suppressing everything except the final summary seemed too
> > aggressive to me initially.  But as we speak, it would work for
> > Valgrind testing purposes just fine.
> 
> If you compare whole output mismatch in Summary would catch a difference.
> 
> OTOH you're right that it's safer to keep at least TFAIL and TBROK.
> I'd personally add also TWARN (not that many messages).

Right.  Agreed re TWARN.

> 
> Kind regards,
> Petr
> 
> > > @Cyril, if you agree, do we dare to have it before the release?
> 
>