On 08/08/2011 08:43 PM, Peter Maydell wrote:
On 8 August 2011 18:06, Avi Kivity<avi@xxxxxxxxxx> wrote: > Somewhat clumsy since it needs a variable sized region. > @@ -119,7 +120,7 @@ void omap_sdrc_reset(struct omap_sdrc_s *s); > struct omap_gpmc_s; > struct omap_gpmc_s *omap_gpmc_init(target_phys_addr_t base, qemu_irq irq); > void omap_gpmc_reset(struct omap_gpmc_s *s); > -void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, int iomemtype, > +void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, MemoryRegion *iomem, > void (*base_upd)(void *opaque, target_phys_addr_t new), > void (*unmap)(void *opaque), void *opaque); I have a pile of omap_gpmc patches almost ready to submit which are mostly waiting on my figuring out how to get them to work with the new memory API. In particular I think this is wrong -- omap_gpmc_attach should just take a MemoryRegion*, and there should be standard APIs for "resize this memory region" and "unmap this memory region", [we have the latter but not the former currently], at which point there's no need to pass in base_upd or unmap function pointers.
I agree we need better support for this in the core. But I'm limiting core updates so I can continue to convert users, without which the entire effort is useless, and so I can collect additional requirements.
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.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
