From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHOoF-0001nd-2L for qemu-devel@nongnu.org; Thu, 18 Jun 2009 17:06:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHOoA-0001jB-70 for qemu-devel@nongnu.org; Thu, 18 Jun 2009 17:06:10 -0400 Received: from [199.232.76.173] (port=47736 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHOo9-0001j1-Pk for qemu-devel@nongnu.org; Thu, 18 Jun 2009 17:06:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:40360) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHOo9-0001MH-64 for qemu-devel@nongnu.org; Thu, 18 Jun 2009 17:06:05 -0400 Date: Thu, 18 Jun 2009 18:05:55 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH v4] avoid compilation warning/errors on up to date Message-ID: <20090618180555.7f5cb06c@doriath> In-Reply-To: <4A3AA47F.9090004@codemonkey.ws> References: <200906172322.35496.jcd@tribudubois.net> <200906180041.31816.jcd@tribudubois.net> <4A39737F.7070101@codemonkey.ws> <200906180116.37819.jcd@tribudubois.net> <20090618171639.1a3c1364@doriath> <4A3AA47F.9090004@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Jean-Christophe Dubois On Thu, 18 Jun 2009 15:33:03 -0500 Anthony Liguori wrote: > Luiz Capitulino wrote: > > On Thu, 18 Jun 2009 01:16:37 +0200 > > "Jean-Christophe Dubois" wrote: > > > > > >> And whatever I have added is a lot more robust than what was > >> before. Once again, please just show me where my patch is > >> incorrect and I will fix it. > >> > > > > I really missed this v4, sorry for that and thanks for letting me > > know. > > > > I think the first step is to do one logical change at a time. You > > could, for example do: > > > > 1. Add qemu_read() and qemu_write() > > > > We already have these in various places. The problem is, we often > want different semantics. We don't always want to retry partial > results (like for live migration). We need a more rationalized > approach to this. If a reasonable number of users can agree on one general semantic, we could have qemu_read() for it and let the others use plain read() directly. But now I'm guessing, one should map all the usage to have a better picture on how to encapsulate and share code. And I hope this is done before having anything merged, otherwise this will require the same amount of work later.