[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 00/17] 64bit block-layer
From: |
Eric Blake |
Subject: |
Re: [PATCH v3 00/17] 64bit block-layer |
Date: |
Tue, 1 Dec 2020 15:50:13 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 12/1/20 10:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
>
> I'm sorry, I should have pinged it, or resend, or suggest to pull at
> least a half long ago :(
>
> I've rebased it on master and make some fixes.
>
> What to do next? I can just resend. But I'm afraid that Eric's careful
> audits may be out of date: time passed, there is no guarantee that
> callers are not changed. Really sorry :(
> So r-b marks are not applicable as well, yes?
If you think the rebase has fundamentally changed things, then dropping
the r-b is safest. I will probably spend a good time on the audit
again, but this time, I want to see the project through to completion,
and am willing to take patches through my NBD tree if Kevin or other
block maintainers do not have enough time to take it through a broader
block tree. I can justify it because I have a specific patch in NBD
that will benefit from this audit - I want to rever 890cbccb08 in favor
of using saner 64-bit APIs throughout the block layer. But I am also
aware that your patches touch more than NBD, so even if Kevin can't
commit to a full review, I will at least try to get his Acked-by.
>
> But if I just resend it with no r-bs, is it feasible to review/merge it
> in a finite time? So that audits of patches will not become outdated?
Yes, let's agree to put a lot more effort into getting this series in
for 6.0.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org