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?
>
> 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 == 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
