From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23110 invoked by alias); 18 Nov 2019 09:24:40 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 22910 invoked by uid 89); 18 Nov 2019 09:24:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Frank, perspective X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 09:24:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574069052; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ldaGnRR/nJP3/dOqi7jsF4QNkD/p66H5ep1Qx7bAFj8=; b=U5chM9FlrM2G5LUIihs1g8G+NykXeus5auoflQjsHqIwTlo+2k4DsS6yFz85rzJ77EPVOj DRfszcDrvH4kJgEmYxPgLfYdBGfYLbJzf98ZbV2GzWF+h4qkDvvpOZtRhD6Pn5aYvOqRQD nnaBteTlghmhDDHO1fZowZm1qniJEm4= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-j3ZZRa2sMMmkvokFI4Xn8w-1; Mon, 18 Nov 2019 04:24:10 -0500 Received: by mail-wr1-f72.google.com with SMTP id p4so14936284wrw.15 for ; Mon, 18 Nov 2019 01:24:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qwBl3Y8dMOFNGx4Nbo+weMFsT+QsbXuWxRD3urhz1CQ=; b=djQ6xeYcJG5dHgxI0xrJ3FkfRLRLvZwhXV32p1F7r8wlmyoNCmTTSDFrDBCOxku/bk 2rWMogCOEKk5NyHFdExnotmj2ON7AzGChcTkNQiRxdchMBkJEnZHTW4JqjOOrcjVaxIB pRcqxf+0iGBvP5LtDmIafh6tubElcsf5eifJU/EPc0GAT4fuYnF2y58kQ2P/TKHac8kI O/G4KM/+8lQ2i1sc9aXjWlE238KtvdkKm0zYXm/u6IwX2jK+blCFAw+7nLqnFxb1R8ST I/SVASqkAr6DHSM6Ntt9Y9L3ZmzEEaQ69A97s0BOfnl0O4mDfEbRsMqJnrbNx7u8dTeU saLQ== X-Gm-Message-State: APjAAAVPlAbqZ97RY9IkLV1nGz2Jykr9WkCEHCxvZGmRDdow1EvLTbU0 ng0ZRU8S7q38BCT2x+o3rHOPTlpk+UuPJn7GK5Rdb3kJF6BH5Wk5UL9eAd4X2z31xqZbmqpXpo0 TFuaNvjgATzAFcwXc2c3URtp1gw== X-Received: by 2002:adf:b1cb:: with SMTP id r11mr19965019wra.246.1574069049134; Mon, 18 Nov 2019 01:24:09 -0800 (PST) X-Google-Smtp-Source: APXvYqz7WR7XZXRVeXbKf0y4bDuMgWZT3kx7ZaUgaMMzC99QR5Y6LlsFNXgpH8i+vgbgJhqD1SNYQQ== X-Received: by 2002:adf:b1cb:: with SMTP id r11mr19964994wra.246.1574069048959; Mon, 18 Nov 2019 01:24:08 -0800 (PST) Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id 205sm29231454wmb.3.2019.11.18.01.24.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 01:24:08 -0800 (PST) Subject: Re: patch 3/3 debuginfod client interruptability To: "Frank Ch. Eigler" , Mark Wielaard References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <20191028190726.GE14349@redhat.com> <20191104214823.GA17633@redhat.com> <73de7c5ac7205dbb5e6d4c47a2abb0c23cd79d5e.camel@klomp.org> <23bbcd14-fc4f-64f6-9a6a-af860b1018cb@redhat.com> <20191118025008.GA29713@redhat.com> Cc: Aaron Merey , elfutils-devel@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 18 Nov 2019 09:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20191118025008.GA29713@redhat.com> Content-Language: en-US X-MC-Unique: j3ZZRa2sMMmkvokFI4Xn8w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-q4/txt/msg00163.txt.bz2 On 11/18/19 2:50 AM, Frank Ch. Eigler wrote: >> Attached is a variant that adds debuginfod_begin and debuginfo_end >> (names matching elf/dwarf_begin/end) and adds a debuginfod_client >> handle to each other function. Thanks much for doing this! >=20 > Sure, if you like. Would you be sympathetic to supporting a > client=3DNULL entrypoint to the lookup functions, ergo no begin/end, for > applications that don't want a progressfn callback? That way the > simple case looks simple. I'm not sure that's a good idea. Creating/destroying the client object doesn't seem onerous to me. It'd mask out bugs where the client pointer becomes NULL by mistake. As the API evolves, it'll very likely gain more state. Seems simpler to me that way from a documentation and maintenance perspective, that with having everyone use the API in the same way. My 2c. Thanks, Pedro Alves