From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPl1e-0001KI-7q for qemu-devel@nongnu.org; Wed, 21 Jan 2009 16:54:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPl1d-0001JW-7f for qemu-devel@nongnu.org; Wed, 21 Jan 2009 16:54:17 -0500 Received: from [199.232.76.173] (port=51744 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPl1d-0001JI-1l for qemu-devel@nongnu.org; Wed, 21 Jan 2009 16:54:17 -0500 Received: from qw-out-1920.google.com ([74.125.92.147]:27916) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPl1c-0000Ae-M5 for qemu-devel@nongnu.org; Wed, 21 Jan 2009 16:54:16 -0500 Received: by qw-out-1920.google.com with SMTP id 5so740152qwc.4 for ; Wed, 21 Jan 2009 13:54:15 -0800 (PST) Message-ID: <4977997A.3020704@codemonkey.ws> Date: Wed, 21 Jan 2009 15:54:02 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <4974943B.4020507@redhat.com> <18804.44271.868488.32192@mariner.uk.xensource.com> <4974B82F.9020805@redhat.com> <20090119182502.GA2080@shareable.org> <4974C9BA.1050803@redhat.com> <18805.58460.230350.875145@mariner.uk.xensource.com> <49760D1C.3020202@redhat.com> <18807.21106.292689.945702@mariner.uk.xensource.com> <497758D8.8010806@redhat.com> In-Reply-To: <497758D8.8010806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Avi Kivity wrote: > Ian Jackson wrote: > >>> I'm suggesting we do that unconditionally (as my patch does) and >>> only add that complexity when we know it's needed for certain. >>> >> >> At the moment there are no such devices (your claims about ide >> notwithstanding) but I think it will be easier to argue about the >> specific case after we have agreed on a non-deficient API. >> > > I don't think we'll ever reach agreement. API's don't have to be fixed for any period of time. They can be changed as needed. The only thing we have to agree on is that 1) we're not causing regressions and 2) we're not digging ourselves into a hole. So far, I don't see anything in the API that would cause either issue. Regards, Anthony Liguori