public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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

  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).