From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 98DC43858CDB for ; Wed, 1 Mar 2023 23:32:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 98DC43858CDB 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: by gnu.wildebeest.org (Postfix, from userid 1000) id BB84530067B2; Thu, 2 Mar 2023 00:32:19 +0100 (CET) Date: Thu, 2 Mar 2023 00:32:19 +0100 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: PATCH: Bug debuginfod/29472 followup Message-ID: <20230301233219.GI12496@gnu.wildebeest.org> References: <20221101142306.GL16441@redhat.com> <20221110171217.GD9668@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221110171217.GD9668@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3031.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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