From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 989AD3858CDA for ; Thu, 10 Nov 2022 17:12:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 989AD3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668100342; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2y4LgEnsUXUlEHAFOliyjEpgsjvj/HoHMLG7Os5Jy+8=; b=QW+JiW5XobUus5IpSmzh+16DjqVD7vxyKmMQRXJJ4WA4Bn+auCuuY4OBglo34siUAGUyEs 8cDiHZB1yw7a8mf+lTczY+V40Zq/THtAZ1rS/r/8jRytSSROhIQPS7JF0Nfn9UNymV6vb7 NQCgFGx99y4mEOUIPzpH3P11SUHCzng= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-458-fyM4t6f3Muab3-_2h7r16Q-1; Thu, 10 Nov 2022 12:12:18 -0500 X-MC-Unique: fyM4t6f3Muab3-_2h7r16Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 58262833AEC; Thu, 10 Nov 2022 17:12:18 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 485A040C83DD; Thu, 10 Nov 2022 17:12:18 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1otB69-0003p5-9r; Thu, 10 Nov 2022 12:12:17 -0500 Date: Thu, 10 Nov 2022 12:12:17 -0500 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: PATCH: Bug debuginfod/29472 followup Message-ID: <20221110171217.GD9668@redhat.com> References: <20221101142306.GL16441@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham 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 - > 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. 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). > Is the sqlite "glob" pattern standardized? Yes. > Can it be provided if the underlying server database isn't sqlite? Yeah, in that unlikely case we undertake this someday. glob expressions can be translated to regular expressions, which are themselves supported in postgres & mysql. > I haven't read the whole diff yet. There are several refactorings > which would be nice to see a separate patch. One such part that occurs to me is the debuginfod_query_server() -> init_handles() / perform_queries() subdivision. Are there others? > 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. - FChE