From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S78Sf-0007ag-O9 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:51:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S78SR-0006Cv-31 for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:51:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S78SQ-0006Ck-Qi for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:50:51 -0400 Message-ID: <4F5E2965.4010609@redhat.com> Date: Mon, 12 Mar 2012 17:50:45 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1331430564-32745-1-git-send-email-mjt@msgid.tls.msk.ru> <1331430564-32745-7-git-send-email-mjt@msgid.tls.msk.ru> <4F5CBE4F.1040007@redhat.com> <4F5CC41E.1080106@msgid.tls.msk.ru> <4F5DFA66.80900@redhat.com> <4F5E244C.3010701@msgid.tls.msk.ru> In-Reply-To: <4F5E244C.3010701@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-devel@nongnu.org Il 12/03/2012 17:29, Michael Tokarev ha scritto: >> For example, qemu_co_recvv has handling for receiving 0, but >> > qemu_co_sendv does not. > This is a bug, which I dind't notice, it shouldn't > be there. Somehow I overlooked this difference, but > I really wondered how they're differ! By using common > code here it becomes much more obvious (whith the bug > actually fixed). write should never return 0, read does for end-of-file. So your code was actually correct in some sense. >> This is what I don't really like in the second part of these patches. >> You are doing changes for the sake of other changes which are not >> upstream yet, for which there is no clear vision, and for which there is >> no clear benefit. > I already posted the example of this. I can complete whole thing > and send it all in one huge chunk if you prefer that > >> While I agree that there is a lot of duplicated code in block.c and >> block/*, I don't think that what we need is more parameters to the >> functions. We have places where we need to know the request flags, for >> example, but the methods are already quite unwieldy and have a lot of >> arguments. So I'm not sure that this kind of unification buys anything. > Which places are these? If we turn zero-write into a special case of discard, we will need it as a flag in discard. Block mirroring would like to have access to copy-on-read flags. > Also, how about dropping nr_sectors? > > If you need flags, well, the extra argument being > added can really be used for that if necessary. Or we can actually clean up everything, and create a real "request" structure that can be passed along. See how flush and discard are really similar (which do not have all the accumulated stuff for throttling, copy-on-read, bounce buffering, etc.). Perhaps that's the place to start. Paolo