From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37744 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrsIb-0006Et-6k for qemu-devel@nongnu.org; Tue, 22 Feb 2011 08:29:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrsIa-0007ye-73 for qemu-devel@nongnu.org; Tue, 22 Feb 2011 08:29:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrsIZ-0007yS-SM for qemu-devel@nongnu.org; Tue, 22 Feb 2011 08:29:04 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1MDT3po014532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2011 08:29:03 -0500 Message-ID: <4D63BA1B.60709@redhat.com> Date: Tue, 22 Feb 2011 15:28:59 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/7] iohandlers: Mark current implementation as 'old' References: <689bf4c031ed209bb306dacdd575b0a9bdb89cc5.1298369272.git.amit.shah@redhat.com> <4D63996E.9070701@redhat.com> <20110222111718.GD10446@amit-x200.redhat.com> In-Reply-To: <20110222111718.GD10446@amit-x200.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu list , Gerd Hoffmann On 02/22/2011 01:17 PM, Amit Shah wrote: > On (Tue) 22 Feb 2011 [13:09:34], Avi Kivity wrote: > > On 02/22/2011 12:18 PM, Amit Shah wrote: > > >Mark the current iohandler list as 'old'. In the next commit we'll > > >introduce a new iohandler api that will replace the list name. > > > > > >The 'old' list will eventually be completely replaced by the new > > >implementation. > > > > A better way to do this is to implement the old API in terms of the > > new API. This ensures you don't lose any functionality, and reduces > > the amount of low-level infrastructure. > > With this new approach of switching to just one callback, that is more > work for little gain as we'll just deprecate the older API soon. (The > previous patches used this approach, btw.) Does "deprecate" mean "completely remove"? If so I agree. > Would you still prefer to have an old->new mapping? > If you don't remove the old API, yes. -- error compiling committee.c: too many arguments to function