From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvqiF-0006lt-78 for qemu-devel@nongnu.org; Fri, 22 May 2015 13:26:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvqiE-0000UW-1S for qemu-devel@nongnu.org; Fri, 22 May 2015 13:26:23 -0400 Message-ID: <555F66B5.1030103@redhat.com> Date: Fri, 22 May 2015 13:26:13 -0400 From: John Snow MIME-Version: 1.0 References: <1431460381-8530-1-git-send-email-jsnow@redhat.com> <55525D43.6060402@redhat.com> <555BA8A4.8070407@redhat.com> <87wq033bje.fsf@blackfin.pond.sub.org> <555E52AE.2040001@redhat.com> <20150522082210.GA4267@noname.redhat.com> <87egm9vwrj.fsf@blackfin.pond.sub.org> <20150522114955.GB4267@noname.redhat.com> In-Reply-To: <20150522114955.GB4267@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qapi: add dirty bitmap status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Markus Armbruster Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On 05/22/2015 07:49 AM, Kevin Wolf wrote: > Am 22.05.2015 um 10:31 hat Markus Armbruster geschrieben: >> Kevin Wolf writes: >> >>> Am 21.05.2015 um 23:48 hat John Snow geschrieben: >>>> >>>> >>>> On 05/20/2015 04:20 AM, Markus Armbruster wrote: >>>>> John Snow writes: >>>>> >>>>>> On 05/12/2015 04:06 PM, Eric Blake wrote: >>>>>>> On 05/12/2015 01:53 PM, John Snow wrote: >>>>>>>> Bitmaps can be in a handful of different states with potentially >>>>>>>> more to come as we tool around with migration and persistence pa= tches. >>>>>>>> >>>>>>>> Instead of having a bunch of boolean fields, it was suggested th= at we >>>>>>>> just have an enum status field that will help expose the reason = to >>>>>>>> management APIs why certain bitmaps may be unavailable for vario= us >>>>>>>> commands >>>>>>>> >>>>>>>> (e.g. busy in another operation, busy being migrated, etc.) >>>>>>> >>>>>>> Might be worth mentioning that this is an API change, but safe be= cause >>>>>>> the old API is unreleased (and therefore, this patch MUST go in t= he 2.4 >>>>>>> time frame, if at all). >>>>>>> >>>>>>>> >>>>>>>> Suggested-by: Eric Blake >>>>>>>> Signed-off-by: John Snow >>>>>>>> --- >>>>>>>> block.c | 13 ++++++++++++- >>>>>>>> include/block/block.h | 1 + >>>>>>>> qapi/block-core.json | 23 +++++++++++++++++++++-- >>>>>>>> 3 files changed, 34 insertions(+), 3 deletions(-) >>>>>>>> >>>>>>> >>>>>>> Reviewed-by: Eric Blake >>>>>>> >>>>>> >>>>>> I'm not actually sure whose tree this should go in. Markus's, perh= aps? >>>>>> >>>>>> ("ping") >>>>> >>>>> I guess the case for "Block layer core" (Kevin) is at least as stro= ng as >>>>> the case for "QAPI" (me). Kevin, what do you think? >>> >>> I think bdrv_query_dirty_bitmaps() really belongs into block/qapi.c, >>> which is yours anyway. So it's either you as the QAPI maintainer or y= ou >>> as the block submaintainer. >> >> s/the block submaintainer/the newly minted block submaintainer/ >> >>> But if you think otherwise, I can consider it. >>> >>>> His silence says "Markus, can you please do it? I discovered today t= hat >>>> I don't care about this patch." >>> >>> I'm sorry, John, but you didn't CC me, you didn't CC qemu-block, you >>> didn't CC anyone. I only had a chance to know about it since Wednesda= y >>> when Markus forwarded it, and I'm not sitting there waiting for new >>> patch emails because I'm bored. Rest assured, I have enough of them. >>> >>> And then the forwarded email didn't even quote the patch any more, so= I >>> couldn't just give a quick reply, but had to find the full email thre= ad >>> in a different folder. >>> >>> If you want to have patches applied quickly, make it easy for the >>> maintainers. You did the exact opposite, so you have no reason to >>> complain. >> >> On the other hand, his "complaining" made me smile, which I appreciate= :) >=20 > Drom secht mr's j=F4 em Guada. ;-) >=20 > I'm sorry if my reply reads a bit too harsh, it's not meant like that. > In fact, the way John phrased it made me smile, too - but that doesn't > change that it is a reproach for me, and looking at the timestamp I > didn't feel that it was entirely fair. >=20 > Kevin >=20 Yes, sorry again. I will try to choose my jokes a little more carefully in the future. I want to make people laugh, but not at the expense of anyone's integrity. --John Snow