qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Nbd] [Qemu-block] [PATCH] doc: Propose NBD_FLAG_INIT_Z


From: Wouter Verhelst
Subject: Re: [Qemu-devel] [Nbd] [Qemu-block] [PATCH] doc: Propose NBD_FLAG_INIT_ZEROES extension
Date: Wed, 14 Dec 2016 09:22:46 +0100
User-agent: NeoMutt/20161126 (1.7.1)

Hi Eric,

On Tue, Dec 13, 2016 at 04:36:08PM -0600, Eric Blake wrote:
> On 12/13/2016 06:18 AM, Wouter Verhelst wrote:
> > On Tue, Dec 13, 2016 at 08:38:12AM +0100, Kevin Wolf wrote:
> >> Am 12.12.2016 um 19:12 hat Wouter Verhelst geschrieben:
> >>> I'm not opposed to this proposal, per se, but there seems to be some
> >>> disagreement (by Kevin, for instance) on whether this extension is at
> >>> all useful.
> >>
> >> FWIW, I'm not opposed to adding the flag. I don't think it can hurt, but
> >> I wanted to ask the question so that we don't end up adding a feature
> >> that noone actually uses. Ultimately it's your call as a maintainer
> >> anyway how conservative you want to be with spec additions.
> > 
> > I'm not opposed either, but I do agree with you that we shouldn't add
> > such a feature if it doesn't end up getting used. Especially so if it
> > burns a flag in the (16-bit) "transmission flags" field, where space is
> > at a premium.
> 
> No, it is NOT a "transmission flag", as it is a per-export property
> (where we currently have 64 bits).

That may be what you meant, but the patch you sent uses a flag in the
transmission flags field.

If you meant to use something else, you'll have to clarify what your
patch should have been like ;-)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12



reply via email to

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