[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous releas

From: Peter Lieven
Subject: Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release
Date: Mon, 15 Feb 2021 14:28:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 15.02.21 um 13:13 schrieb Kevin Wolf:
Am 15.02.2021 um 12:45 hat Peter Lieven geschrieben:
Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:
On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.
We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:


At this time RHEL-7 is usually the oldest platform, and it
builds with RBD 10.2.5, so we can't bump the version to 12.2.

I'm afraid this patch has to be dropped.
I have asked exactly this question before I started work on this series and got 

from Jason that he sees no problem in bumping to a release which is already 

for 3 years.
I'm afraid Jason is wrong here.  It doesn't matter what the upstream
consider the support status to be. QEMU targets what the OS vendors
ship, and they still consider this to be a supported version.

Okay, but the whole coroutine stuff would get a total mess with all
the ifdef'ry.
Hm, but how are these ifdefs even related to the coroutine conversation?
It's a bit more code that you're moving around, but shouldn't it be
unchanged from the old code, just moving from an AIO callback to a
coroutine? Or am I missing some complications?

No, the ifdef's only come back in for the write zeroes part.

Would it be an option to make a big ifdef in the rbd driver? One with
old code for < 12.0.0 and one

with new code for >= 12.0.0?
I don't think this is a good idea, this would be a huge mess to

The conversion is probably a good idea in general, simply because it's
more in line with the rest of the block layer, but I don't think it adds
anything per se, so it's hard to justify such duplication with the
benefits it brings.

I would wait for Jasons comment on the rbd part of the series and then spin a V3

with a for-6.1 tag.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]