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.129.124]) by sourceware.org (Postfix) with ESMTPS id C96DE385740A for ; Mon, 24 Oct 2022 18:38:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C96DE385740A 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=1666636693; 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=SMbvuwkJ9wlPUXk7QsPsuC7S2bMfV0h27aAgsCANnN8=; b=euaAlh+jy0fK4zqHm9oFKypIef+1CB3iB19Ft84/rdoBSEW2N4awpXDbJ+B5NWyhlNkK1O Z5GN2zrq9ILRRtSSa4f7ZVbmade1GeFmwr4IeuBrk2UJXJwuieK2VRRK1XgWAFjnvXNNKx JHEa+zIUh+7sfrBcM36e6XeQnePaoxw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-441-yVoFoQP0Np-8IsTpMygKEg-1; Mon, 24 Oct 2022 14:38:11 -0400 X-MC-Unique: yVoFoQP0Np-8IsTpMygKEg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1CDBC380673C for ; Mon, 24 Oct 2022 18:38:11 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DEEB2024CCA; Mon, 24 Oct 2022 18:38:11 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1on2Kv-0007t9-SX; Mon, 24 Oct 2022 14:38:09 -0400 Date: Mon, 24 Oct 2022 14:38:09 -0400 From: "Frank Ch. Eigler" To: Aaron Merey Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH] debuginfod: Support queries for ELF/DWARF sections Message-ID: <20221024183809.GB16441@redhat.com> References: <20221021000651.413015-1-amerey@redhat.com> <20221022000916.58609-1-amerey@redhat.com> MIME-Version: 1.0 In-Reply-To: <20221022000916.58609-1-amerey@redhat.com> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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=-8.6 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 - Generally looks fine, thanks a lot. A few nits: - use of write(2) to put files onto disk is not quite right; write(2) can be partial, so you need a loop (or a macro wrapping a loop) - not sure I understand why the code worries about dots in or not in section names. Why not just pass them verbatim throughout the code base, and not worry about whether or not there's a dot? Does the ELF standard even require a dot? - not sure whether/why the I queries require a new _query_i view, as opposed to running the _query_d & _query_e views union'd together. I see an ORDER BY that's different here but not sure why bother; if anything, the server could prefer one or the other type, based on the same section-name heuristic as the client - don't really see a need for the X-DEBUGINFOD-SECTION response header, which simply echoes back the very same parameter the client just requested; the other X-DEBUGINFOD-* headers are novel metadata - re. verbose logging in the section vs non-section case, suggest just keeping the code simple (even if it makes the logs more verbose), i.e., not duplicating if (...) clog << STUFF else clog << STUFF; no biggie tho - the webapi docs in debuginfod.8 should document the new query type Otherwise lgtm. Lots of nice work. - FChE