On 04/30/2012 04:40 PM, Peter Maydell wrote:
> On 30 April 2012 14:36, Avi Kivity <a...@redhat.com> wrote:
> > On 04/30/2012 04:27 PM, Peter Maydell wrote:
> >> On 30 April 2012 14:23, Avi Kivity <a...@redhat.com> wrote:
> >> > IMO the best fix is to unsysbus the device and qomify it instead.  This
> >> > way we're 100% flexible in how we can attach it.
> >>
> >> You don't need to wait for QOM to grow enough features to
> >> replace sysbus. If you don't like what sysbus_mmio_map() does, you
> >> can always use sysbus_mmio_get_region() to get the MemoryRegion* and
> >> then deal with it however you need to. This is the standard way
> >> to deal with "I have a sysbus device which I want to map into my
> >> custom container object".
> >
> > I believe that API voids you warrantee.
> I wrote it for essentially the purpose described above :-)
> If you're the owner of the sysbus device in question then it's
> entirely fine as you are the one deciding whether to use the
> traditional map function or not.
> It's as good as we're going to get until QOM actually lets
> you export memory regions and pins, at which point we can just
> convert all the sysbus devices.

Sure.  But expect breakage if sysbus changes, for example dropping use
of get_system_memory().

error compiling committee.c: too many arguments to function

Reply via email to