On 9 August 2011 08:41, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 08/09/2011 10:37 AM, Peter Maydell wrote:
>>
>> On 9 August 2011 07:34, Avi Kivity<avi@xxxxxxxxxx> wrote:
>> > Also, my patchset focuses on mechanical transformations. It is already
>> > risky enough in terms of regressions, I'm not going to rewrite/improve
>> > all
>> > of qemu; if you want those callbacks removed, you will have to remove
>> > them
>> > yourself.
>>
>> Sure. Can I ask you to drop this one and the onenand patch, and I'll
>> have a go over the next week or three at incorporating a conversion into
>> the patchset I have for those?
> Umm... next week or three? I'd like to move fast on this.
I'm busy at least half of this week, and next week is the KVM
Forum, so I didn't want to promise anything faster.
> Can't you base your patches on this instead? After all, this is just a
> mechanical transformation, there should be no functional change.
Well, maybe, but it seems a bit silly to commit something which is
going to be half-reverted and rewritten.
Also I just noticed this change:
-static CPUReadMemoryFunc * const omap_gpmc_readfn[] = {
- omap_badwidth_read32, /* TODO */
- omap_badwidth_read32, /* TODO */
- omap_gpmc_read,
-};
-
-static CPUWriteMemoryFunc * const omap_gpmc_writefn[] = {
- omap_badwidth_write32, /* TODO */
- omap_badwidth_write32, /* TODO */
- omap_gpmc_write,
+static const MemoryRegionOps omap_gpmc_ops = {
+ /* TODO: specialize <4 byte writes? */
+ .read = omap_gpmc_read,
+ .write = omap_gpmc_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
};
...isn't this just throwing away the warnings on bad-width accesses?
(it's not clear to me from the docs what the behaviour of the new
API on bad-width accesses is going to be.)
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
