From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39742 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrtMr-0001ad-3E for qemu-devel@nongnu.org; Tue, 22 Feb 2011 09:37:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrtMq-0007QD-03 for qemu-devel@nongnu.org; Tue, 22 Feb 2011 09:37:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrtMp-0007Py-NF for qemu-devel@nongnu.org; Tue, 22 Feb 2011 09:37:31 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1MEbUXV012956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2011 09:37:30 -0500 Date: Tue, 22 Feb 2011 20:07:26 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 1/7] iohandlers: Mark current implementation as 'old' Message-ID: <20110222143726.GA4939@amit-x200.redhat.com> References: <689bf4c031ed209bb306dacdd575b0a9bdb89cc5.1298369272.git.amit.shah@redhat.com> <4D63996E.9070701@redhat.com> <20110222111718.GD10446@amit-x200.redhat.com> <4D63BA1B.60709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D63BA1B.60709@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu list , Gerd Hoffmann On (Tue) 22 Feb 2011 [15:28:59], Avi Kivity wrote: > 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. Yes, completely removing the older API is the plan (as noted in message 00). Amit