Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]

[Milian Wolff <mail@milianw.de>]

On Mittwoch, 6. Juli 2022 20:40:09 CEST Frank Ch. Eigler wrote:
> Hi -
> 
> > > Thus my proposal, and RFC:
> > > 
> > > ```
> > > /* Let us mirror the debuginfod progressfn for dwfl and forward it to
> > > 
> > >    the internal debuginfod client, if available.
> > >    This way, dwfl's usage of debuginfod can stay optional and we would
> > >    not
> > >    need to link to debuginfod directly from code using dwfl.
> > >  
> > >  */
> > > 
> > > typedef int (*dwfl_debuginfod_progressfn_t)(Dwfl *dwfl, long a, long b);
> > > extern void dwfl_set_debuginfod_progressfn(Dwfl *dwfl,
> > > 
> > > 			           dwfl_debuginfod_progressfn_t fn);
> > > 
> > > ```
> 
> (Don't quite see how this extension would let you disable or enable
> debuginfod support on a given dwfl.  By the time a progressfn is
> called, some debuginfod traffic would be attempted.)n
> 
> > Alternately:
> > [...]
> > 
> > > /* We could just give full access to the internal client
> > > 
> > >    but doing so may clash with future usages of e.g.
> > >    debuginfod_{set,get}_user_data in dwfl and users of dwfl.
> > >    Otherwise, this is obviously easiest and gives most flexibility.
> > >    We just need to forward get_client from debuginfod-client.c
> > >  
> > >  */
> > > 
> > > extern debuginfod_client *dwfl_debuginfod_client (Dwfl *);
> > > ```
> > > What do you all think?
> 
> In order to -influence- things, would you not need to -change- the
> client somehow?  We don't have debuginfod-client apis to disable or
> reconfigure any particular client object.  Such an API wouldn't let
> you replace it with a hook object of your own either.
> 
> 
> So, dunno, could you perhaps remind us what your current usage
> interests are?
> 
> To enable/disable it on a per-dwfl basis?  If yes, and if statically,
> maybe a new Dwfl_Callbacks option for .find_debuginfo() could be your
> ticket: a dwfl_standard_find_debuginfo variant sans debuginfod at the
> end.

I have two goals:

a) Notifying the user that a download is ongoing. Right now, it feels like the 
tool is frozen as no feedback is given to the user.

b) Allow to disable debuginfod. But that is already doable by unsetting the 
DEBUGINFOD_URLS env var, and as such I don't necessarily need any additional 
API for that?

As such, only a) is something that needs immediate attention imo, and what my 
API proposal is covering.

Thanks

-- 
Milian Wolff
http://milianw.de