From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] memory: transaction API Date: Thu, 21 Jul 2011 14:52:44 +0200 Message-ID: <4E28211C.5060705@siemens.com> References: <1311243679-18403-1-git-send-email-avi@redhat.com> <4E280195.5040003@siemens.com> <4E281609.7090809@redhat.com> <4E2816DE.5010102@siemens.com> <4E2817DA.4030505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:33389 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751754Ab1GUMwv (ORCPT ); Thu, 21 Jul 2011 08:52:51 -0400 In-Reply-To: <4E2817DA.4030505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-07-21 14:13, Avi Kivity wrote: > On 07/21/2011 03:09 PM, Jan Kiszka wrote: >>> >>> Why? just stick a _begin() and _commit() at the start and end of the >>> update_mapping() function. It's an optional API, for simple cases (like >>> mapping a BAR) you don't have to use it. >> >> begin >> delete old >> free old >> create new >> add new >> end >> >> vs. >> >> update >> > > The problem is that "update" can change lots of things. offset, size, > whether it's mmio or RAM, read-onlyness, even the wierd things like > coalesced mmio. So it's either a function with 324.2 parameters (or a > large struct), or it's a series of functions with demarcation as to > where the update begins and ends. We do not need to provide update support for each and every bit, but for the common cases. memory_region_update_alias(region, offset, size) would be an excellent first candidate IMO. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux