From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16FDDC433ED for ; Tue, 13 Apr 2021 08:09:36 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF48A611F2 for ; Tue, 13 Apr 2021 08:09:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF48A611F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.109572.209144 (Exim 4.92) (envelope-from ) id 1lWE6s-0004Rf-NB; Tue, 13 Apr 2021 08:09:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 109572.209144; Tue, 13 Apr 2021 08:09:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lWE6s-0004RY-KC; Tue, 13 Apr 2021 08:09:22 +0000 Received: by outflank-mailman (input) for mailman id 109572; Tue, 13 Apr 2021 08:09:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lWE6r-0004RT-8I for xen-devel@lists.xenproject.org; Tue, 13 Apr 2021 08:09:21 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a2e963ff-be95-4357-af5d-e1d620ff985e; Tue, 13 Apr 2021 08:09:20 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 719E3B0EA; Tue, 13 Apr 2021 08:09:19 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2e963ff-be95-4357-af5d-e1d620ff985e X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1618301359; h=from:from:reply-to: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=LHAvMnvNF4OK3/k9Ct4oNGcrGQrZqtQ6oj43xIDYCh4=; b=Xy+jXwWXYLbjxw1sOC/K9m9HrXZlDFTanD0r+jc/UvqP8MqN2BX4N+++G6PS9bM2qRINOW T9vmQpsXpXbi2E3rx/t9dMape3vbQPPW5ZPqEjbRX4MfebtyiYCFHCC/B/uczzHqdacXX8 1X7ZSphCcpgyGoFg/+lraZvQv6rxXTY= Subject: Re: [PATCH 3/3] xen-pciback: simplify vpci's find hook To: Boris Ostrovsky Cc: Juergen Gross , Konrad Wilk , "xen-devel@lists.xenproject.org" References: <158273a2-d1b9-3545-b25d-affca867376c@suse.com> <037a8fc2-2c69-2049-8826-32181b8aec2d@oracle.com> From: Jan Beulich Message-ID: Date: Tue, 13 Apr 2021 10:09:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <037a8fc2-2c69-2049-8826-32181b8aec2d@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12.04.2021 18:05, Boris Ostrovsky wrote: > > On 4/12/21 5:50 AM, Jan Beulich wrote: >> On 09.04.2021 23:45, Boris Ostrovsky wrote: >>> On 4/7/21 10:37 AM, Jan Beulich wrote: >>>> There's no point in comparing SBDF - we can simply compare the struct >>>> pci_dev pointers. If they weren't the same for a given device, we'd have >>>> bigger problems from having stored a stale pointer. >>>> >>>> Signed-off-by: Jan Beulich >>> >>> Reviewed-by: Boris Ostrovsky >> Thanks. As the 1st patch of this series still looks to have an unclear >> disposition (unless not getting back a reply on my responses to your >> comments means silent agreement), > > > TBH I have been struggling with understanding both the original problem (just like you have) and the solution you are proposing (apart from making dev_list[] more compact). > > >> I can't predict yet when I'd be able >> to submit v2. Hence I'd like to point out that this patch is >> independent of the former two, and hence would need to wait further if >> you wanted to apply it. After all this one (unlike the other two) is >> merely cleanup, and hence would rather want to go in during a merge >> window. > > > Given that next Sunday may be when 5.12 is released I think everything but stoppers will have to wait for the merge window. Oh, I didn't mean it this way. Instead I thought the 3rd patch here could be pushed to Linus during the merge window, while the other two may be fine to go his way also during early RCs of 5.13 (giving us some time to sort what exactly we want to do). Jan