From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: PATCH: Bug debuginfod/29472 followup
Date: Thu, 2 Mar 2023 00:32:19 +0100 [thread overview]
Message-ID: <20230301233219.GI12496@gnu.wildebeest.org> (raw)
In-Reply-To: <20221110171217.GD9668@redhat.com>
Hi Frank,
The patch as posted (users/fche/try-pr29472) doesn't apply anymore,
have you tried to rebase it to the current git master branch?
On Thu, Nov 10, 2022 at 12:12:17PM -0500, Frank Ch. Eigler via Elfutils-devel wrote:
> > Are you sure the interface is correct?
>
> Hard to be sure, so it's left generalized. The APIs would be
> unchanged if future search strategies are added (or subtracted);
> they'd affect the choice of acceptable KEY strings.
OK, so the interfaces added are:
New debuginfod-client interface:
/* Query the urls contained in $DEBUGINFOD_URLS for metadata
with given query key/value.
If successful, return 0, otherwise return a posix error code.
If successful, set *metadata to a malloc'd json array
with each entry being a json object of metadata for 1 file.
Caller must free() it later. metadata MUST be non-NULL. */
int debuginfod_find_metadata (debuginfod_client *client,
const char *key, const char* value,
char** metadata);
Might need an explanation of which characters are allowed in key and
value. In particular is '=' allowed? Any other special chars? What
encoding is used (utf8)?
New server query: metadata?key=KEY&value=VALUE
Same as above, plus maybe explictly descibe the URL encoding?
New debuginfod-find command arguments:
debuginfod-find [OPTION]... metadata KEY VALUE
Where:
KEY VALUE DESCRIPTION
file path match exact path, including in archives
glob pattern sqlite glob match pattern, including in archives
And as output a json array with objects that might contain the
following:
NAME TYPE DESCRIPTION
buildid string hexadecimal buildid associated with the file
type string one of debuginfo or executable or source
file string matched file name, outside or inside the archive
Having the associated buildid with every result object might be a lot,
especially when listing source files, is there a representation where
the buildid is only listed one for a group of results?
Is file here the full path?
> We know we want glob patterns over executable file names. I've seen
> cases where an exact match query produces a different sqlite query
> plan from the glob one, but not sure how much performance difference
> that implies. Searching for source files by glob/match is removed
> from today's version because it doesn't run fast enough (without a new
> large index).
Aha, that wasn't really clear from the above description.
Maybe the key name "glob" is a but generic then?
> > Is the sqlite "glob" pattern standardized?
>
> Yes.
Could you add a reference or description?
I believe globs include the ? (single char) and * (zero or many)
wildcards. Does it include (negative!) [..] ranges?
> > Why does debuginfod-client.c use json-c? Can't the server sent the
> > json object as a normal char string? Why does the string from the
> > server need to be interpreted as a json object and then turned into a
> > string again?
>
> Use of the library allows robust processing (checking & merging) of
> incoming json data from multiple upstream servers. Luckily, json-c is
> a small & self-contained library.
aha, I see, the metadata query is different from other queries. It
"merges" the replies from all servers instead of picking the first one
that gives an answer.
Does it really merge the results? It looks like it just adds all
elements to the array whether or not they are there.
Should the result also contain the server URL from which the entry
came?
Cheers,
Mark
next prev parent reply other threads:[~2023-03-01 23:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 14:43 [Bug debuginfod/29472] New: Support querying the debuginfod-server for metadata rgoldber at redhat dot com
2022-08-12 9:05 ` [Bug debuginfod/29472] " mliska at suse dot cz
2022-08-12 9:05 ` mliska at suse dot cz
2022-08-22 18:24 ` rgoldber at redhat dot com
2022-08-31 14:52 ` rgoldber at redhat dot com
2022-09-02 17:25 ` rgoldber at redhat dot com
2022-11-01 14:23 ` PATCH: Bug debuginfod/29472 followup Frank Ch. Eigler
2022-11-01 22:20 ` Mark Wielaard
2022-11-10 17:12 ` Frank Ch. Eigler
2023-03-01 23:32 ` Mark Wielaard [this message]
2023-02-28 22:21 ` [Bug debuginfod/29472] Support querying the debuginfod-server for metadata mark at klomp dot org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230301233219.GI12496@gnu.wildebeest.org \
--to=mark@klomp.org \
--cc=elfutils-devel@sourceware.org \
--cc=fche@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).