From: Jan Beulich <jbeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/3] xen-pciback: simplify vpci's find hook
Date: Tue, 13 Apr 2021 10:09:19 +0200 [thread overview]
Message-ID: <e7686006-5f95-3216-60ff-daf1b1cbe8c4@suse.com> (raw)
In-Reply-To: <037a8fc2-2c69-2049-8826-32181b8aec2d@oracle.com>
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 <jbeulich@suse.com>
>>>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> 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
next prev parent reply other threads:[~2021-04-13 8:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 14:35 [PATCH 0/3] xen-pciback: a fix, a workaround, and some simplification Jan Beulich
2021-04-07 14:37 ` [PATCH 1/3] xen-pciback: redo VF placement in the virtual topology Jan Beulich
2021-04-08 22:28 ` Boris Ostrovsky
2021-04-09 8:16 ` Jan Beulich
2021-04-07 14:37 ` [PATCH 2/3] xen-pciback: reconfigure also from backend watch handler Jan Beulich
2021-04-09 21:43 ` Boris Ostrovsky
2021-04-12 9:44 ` Jan Beulich
2021-04-12 15:55 ` Boris Ostrovsky
2021-04-07 14:37 ` [PATCH 3/3] xen-pciback: simplify vpci's find hook Jan Beulich
2021-04-09 21:45 ` Boris Ostrovsky
2021-04-12 9:50 ` Jan Beulich
2021-04-12 16:05 ` Boris Ostrovsky
2021-04-13 8:09 ` Jan Beulich [this message]
2021-04-13 12:54 ` Boris Ostrovsky
2021-04-23 8:05 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7686006-5f95-3216-60ff-daf1b1cbe8c4@suse.com \
--to=jbeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).