Re: [Qemu-devel] [PATCH 09/24] omap_gpmc/nseries/tusb6010: convert to memory API

[Avi Kivity <avi@redhat.com>]

On 08/08/2011 08:43 PM, Peter Maydell wrote:
> On 8 August 2011 18:06, Avi Kivity<avi@redhat.com>  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.