Re: [PATCH 04/12] perf debuginfo: Let the user skip and disable debuginfod fetches

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Wed, Sep 16, 2026 at 11:53:55AM -0700, Namhyung Kim wrote:
> On Wed, Sep 16, 2026 at 08:47:31AM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > When a fetch is in progress, the way it prints progress is how one
> > gets out of it: 's' aborts the current fetch via the debuginfod
> > client's progress callback protocol and remembers the build ID, so
> > that the rest of the session doesn't ask for it again, the user may
> > have skipped it for being too big; 'd' additionally disables debuginfod
> > for the rest of the session, clearing DEBUGINFOD_URLS so that libdwfl's
> > own client, that reads it in every query, stops fetching too, and, using
> > perf_config__set_variable(), moved to util/config.c in the previous
> > patch, writes core.debuginfod=false to the configuration file directly,
> > the user's ~/.perfconfig or the one named by PERF_CONFIG, the same
> > rewrite 'perf config' does -- the comments are not preserved, as the
> > config set carries just the key-value pairs -- and SIGINT, SIGQUIT and
> > SIGTERM are intercepted while the terminal is in raw mode, so that it is
> > restored and the signal is re-raised when the user interrupts a fetch.
> > 
> > In the TUI nothing is shown yet, printing to stderr would garble the
> > browser display and draining stdin would eat the keys the browser
> > wants, that comes in the next patch.
> > 
> > The interaction state -- the terminal settings, the signal dispositions
> > and the progress and cancellation state -- is process global, so the
> > fetches stay serialized: a second fetch resetting the cancellation
> > state would drop the 's'/'d' keypress that was meant for the fetch
> > already in progress, and the serialization the lookup state needs
> > already provides the lock the interaction state uses.
> > 
> > Since the debuginfo fetching this builds on is opt-out, a fetch that
> > the user asked to skip is not restarted by the next request for the
> > same build ID in the same session, it is remembered as a cancellation
> > on the misses list, where the debug message can tell it apart from a
> > plain miss.

> > Assisted-by: LLM
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > ---
> [SNIP]
> > +/*
> > + * The stdio fetch UI: the terminal is in raw mode, see
> > + * debuginfod__fetch(), so the keypresses are on stdin, drain them.
> > + */
> > +static void debuginfod__poll_cancel_keys(void)
> > +{
> > +	char ch;
> > +
> > +	while (read(STDIN_FILENO, &ch, 1) == 1)
> > +		debuginfod__cancel_key(ch);
 
> Isn't it block indefinitely when users don't press any key?  I'm curious
> how it can escape from the loop when it finishes to fetch.

With the help of AI:

it can't block — it's a drain, not a wait. set_term_quiet_input()
(util/term.c) puts the terminal in raw mode with VMIN = 0; VTIME = 0, so
read() returns 0 when there is nothing typed; the while (read(...) == 1)
loop drains what was typed and returns to the progress callback, which
returns to libdebuginfod, which carries on fetching and calls it again
at the next update. When the fetch finishes there are no more callbacks.

But then there are other issues in that series, from Ian, and from
myself, locally, I'll submit a new version soon.

- Arnaldo