[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: |
Kevin Wolf |
Subject: |
Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release |
Date: |
Mon, 15 Feb 2021 13:13:34 +0100 |
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:
> > > >
> > > > https://qemu.readthedocs.io/en/latest/system/build-platforms.html
> > > >
> > > > 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 reply
> > >
> > > from Jason that he sees no problem in bumping to a release which is
> > > already unmaintained
> > >
> > > 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?
> 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
maintain.
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.
Kevin
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, (continued)
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Daniel P . Berrangé, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Daniel P . Berrangé, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Peter Lieven, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Daniel P . Berrangé, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Peter Lieven, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Daniel P . Berrangé, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Peter Lieven, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Daniel P . Berrangé, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release,
Kevin Wolf <=
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Peter Lieven, 2021/02/15
- Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release, Jason Dillaman, 2021/02/22