qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v4 00/58] Memory API


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API
Date: Tue, 19 Jul 2011 19:30:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-07-19 19:14, Avi Kivity wrote:
> On 07/19/2011 08:01 PM, Jan Kiszka wrote:
>> On 2011-07-19 15:56, Michael S. Tsirkin wrote:
>>>  On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
>>>>  New in this version:
>>>>    MemoryRegionOps gained .old_mmio and .old_portio members, which allow
>>>>    reusing old-style callbacks with the new API.  All uses were converted,
>>>>    except for eepro100.c, which uses the same MemoryRegionOps for both
>>>>    portio and mmio.  Some intermediate patches do introduce dispatching
>>>>    callbacks, but they are removed later.
>>>>
>>>>  Caveats:
>>>>  - some devices still grab a global memory region instead of inheriting
>>>>    it from their bus.  Seen in the code as #include "exec-memory.h"
>>>
>>>  Looks good to me.
>>>
>>>  It looks like with this, users of vga_dirty_log_stop
>>>  like qxl_write_config can go away because the region can
>>>  stay registered with dirty logging enabled?
>>
>> That was already possible with the old API, see [1]. Makes me wonder
>> what will be merged first...
>>
> 
> Rebasing is already not so fun for me with 78 patches and counting.  
> Let's drop yours and focus of getting mine in shape, since it's a superset.

The patches series are widely orthogonal except for both killing the
obsolete start/stop logging logic.

But I don't mind rebasing over yours - if something is finally merged at
all.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]