From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id BEED53858D28 for ; Wed, 6 Jul 2022 18:40:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BEED53858D28 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-483-djEotIPWOjWyQoXJUymMPg-1; Wed, 06 Jul 2022 14:40:11 -0400 X-MC-Unique: djEotIPWOjWyQoXJUymMPg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BF247101A595; Wed, 6 Jul 2022 18:40:10 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF65AC2811A; Wed, 6 Jul 2022 18:40:10 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1o99wX-0003Fc-7O; Wed, 06 Jul 2022 14:40:09 -0400 Date: Wed, 6 Jul 2022 14:40:09 -0400 From: "Frank Ch. Eigler" To: Milian Wolff Cc: elfutils-devel@sourceware.org Subject: Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API] Message-ID: <20220706184009.GD9702@redhat.com> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <15044726.Ck1BFTr2H8@milian-workstation> <2782414.8Vx5aUIOYe@milian-workstation> <5959578.lOV4Wx5bFT@agathemoarbauer> MIME-Version: 1.0 In-Reply-To: <5959578.lOV4Wx5bFT@agathemoarbauer> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 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 18:40:15 -0000 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. - FChE