From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.connected.by.freedominter.net [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id A940B385840B for ; Tue, 5 Oct 2021 14:29:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A940B385840B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 5037830007DF; Tue, 5 Oct 2021 16:28:59 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id E78C8413CEBD; Tue, 5 Oct 2021 16:28:56 +0200 (CEST) Message-ID: Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Tue, 05 Oct 2021 16:28:56 +0200 In-Reply-To: <20210929212847.GA11484@redhat.com> References: <20210805165402.GD4195@redhat.com> <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> <20210806185459.GE4195@redhat.com> <9ac621fee207ef233873c40843b3d34ced9019cc.camel@klomp.org> <20210922203331.GC13236@redhat.com> <599234fd5a36629b580d0a615ac069835295111f.camel@klomp.org> <20210929212847.GA11484@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 05 Oct 2021 14:29:02 -0000 Hi Frank, On Wed, 2021-09-29 at 17:28 -0400, Frank Ch. Eigler wrote: > The problem with what we have now, with $DEBUGINFOD_VERBOSE, is that > the amount of output is huge. It is a debugging level trace. It's > not consumable by non-expert users OR by software. OK, but that seem two separate issues. The first is making generic verbose/debug output usable by non-expert users. The second is providing a software interface to probe whether an artifact can be retrieved from a remote server (and whether it already is available in cache and if now how many resources it might take to get it). Or do you imagine some kind of "diagnostics" interface that programs use to provide non-experts users with the http headers to analyze? > > But if the program needs to make any policy decisions then what do > > we guarantee about the provided header strings? >=20 > The simplest thing to do is simply to save whatever we fetched and > present it verbatim. Parsing one-line "key: value" HTTP headers is > not that difficult. We could -add- a few headers in order to provide > guarantees, but that's not necessary. (We should catch up with > documenting the headers that debuginfod is known to send.) OK, so I would assume that is for the non-expert user case. When/where would these headers be shown? > But "programs making policy decisions" is not the only use case: what > about where a user would like to get a glance at that metadata, and > not all the other $DEBUGINFOD_VERBOSE firehose? They could ALMOST do > it themselves via "% curl -I -i $URL", except $URL is synthesized and > competitively tie-broken between $DEBUGINFOD_URLS. So, for the above you would want some debuginfod-find --info flag that spits out just the http headers but doesn't retrieve the actual file? What I had in mind for a software interface would not include the actual headers, but just used them to provide the program with information. e.g. /* Get info about an debuginfod artifact. Used to know whether the target is already in local cache or whether it can be retrieved from one if the urls contained in $DEBUGINFOD_URLS. If build_id_len =3D=3D 0, the build_id is supplied as a lowercase hexadecimal string; otherwise it is a binary blob of given length. If the requested resource is in cache, return a file descriptor which an be used as is. If the requested resource can be found through one of the DEBUGINFOD_URLS then -1 is returned and file_size and transfer_size are set to the number of bytes of the target file and the number if bytes that need to be transferred from the server (file_size is the uncompressed size, transfer_size might be the compressed size). Otherwise return -2 to indicate the requested artifact cannot be found. If the file wasn't in cache, but can be retrieved from a remote server, then debuginfod_get_url () will return where the target can be found. A successive debuginfod_find_* call will retieve the resource (unless a network error occurs). */ int debuginfod_info_debuginfo (debuginfod_client *client, const unsigned char *build_id, int build_id_len, size_t *size, size_t *transfer_size); If we want to combine both use cases we could add an optional char **headers argument? Cheers, Mark