From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dd14210.kasserver.com (dd14210.kasserver.com [85.13.138.83]) by sourceware.org (Postfix) with ESMTPS id 97B21385828F for ; Wed, 6 Jul 2022 19:37:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97B21385828F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=milianw.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=milianw.de Received: from agathemoarbauer.localnet (p54a1bbed.dip0.t-ipconnect.de [84.161.187.237]) by dd14210.kasserver.com (Postfix) with ESMTPSA id 9F368240115; Wed, 6 Jul 2022 21:37:14 +0200 (CEST) From: Milian Wolff To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API] Date: Wed, 06 Jul 2022 21:37:14 +0200 Message-ID: <5731070.DvuYhMxLoT@agathemoarbauer> In-Reply-To: <20220706184009.GD9702@redhat.com> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <5959578.lOV4Wx5bFT@agathemoarbauer> <20220706184009.GD9702@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spamd-Bar: / X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 19:37:17 -0000 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