From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 8C503385842C for ; Mon, 9 Aug 2021 09:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C503385842C 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 deer0x15.wildebeest.org (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 36A2030291A9; Mon, 9 Aug 2021 11:27:30 +0200 (CEST) Message-ID: <9ac621fee207ef233873c40843b3d34ced9019cc.camel@klomp.org> Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose From: Mark Wielaard To: "Frank Ch. Eigler" Cc: Noah Sanci , elfutils-devel@sourceware.org Date: Mon, 09 Aug 2021 11:25:15 +0200 In-Reply-To: <20210806185459.GE4195@redhat.com> References: <20210805165402.GD4195@redhat.com> <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> <20210806185459.GE4195@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Mon, 09 Aug 2021 09:27:35 -0000 Hi Frank, On Fri, 2021-08-06 at 14:54 -0400, Frank Ch. Eigler wrote: > > Yes, since the actual download might take a bit, it is nice to see > > the > > headers at the moment we commit to a server/download. aka here in > > the > > source: > > > > if (vfd >= 0 && !verbose_reported && committed_to >= 0) > > { > > bool pnl = (c->default_progressfn_printed_p && vfd == > > STDERR_FILENO); > > dprintf (vfd, "%scommitted to url %d\n", pnl ? "\n" : "", > > committed_to); > > if (pnl) > > c->default_progressfn_printed_p = 0; > > verbose_reported = true; > > } > > One could print it there, but verbose printing is so voluminous and > unstructured that mingling http headers there can only be for a > masochist human's consumption. But the verbose output up to now is also chronological. I would expect the headers to be shown before seeing verbose traces of other activity. > > Yes, I do think there is something there, but imho it is too vague > > and > > fragile to be useful as is, especially since it depends on what is > > in the cache. > > I believe you mean that these headers would only be available for > files fetched anew, not for queries previously cached. Yeah. A > person or tool can force a new fetch by using something like > DEBUGINFOD_CACHE_PATH=`mktemp -d`. Which IMHO is not a great interface, especially if it forces a full new download. > That in turn would require THREE new API functions or a stateful > > > set_HEAD_mode_and_return_dev_null one and modifying the three > > > main > > > lookup functions. > > > > Yes, it definitely is more work. > > So, is that your suggestion? We proceed with that sort of thing? Yes, separate the verbose printing of http headers (which I really do like) from providing an interface to query what needs to be done to get some file (is it in cache, can it be retieved from a remote server, how big is it?) I don't think providing raw http headers is that interface. Cheers, Mark