Re: [Qemu-devel] [RFC] Memory API

[Avi Kivity <avi@redhat.com>]

On 05/19/2011 04:26 PM, Jan Kiszka wrote:
> On 2011-05-19 15:07, Avi Kivity wrote:
> >  On 05/19/2011 04:03 PM, Jan Kiszka wrote:
> >>  On 2011-05-19 15:00, Avi Kivity wrote:
> >>>   On 05/19/2011 03:58 PM, Jan Kiszka wrote:
> >>>>>
> >>>>>    Eventually we may make the memory API a sub-API of qdev.  I don't want
> >>>>>    to start with that however, the change is large enough already.
> >>>>
> >>>>   Touching all devices again at that point to change the way they register
> >>>>   regions may not be the best approach. I would try to consolidate the
> >>>>   refactoring work that affects the majority of device models.
> >>>
> >>>   The risk is that the entire work will be stalled if it requires too much
> >>>   effort.
> >>
> >>  Then we could still switch one gear down, converting at least some
> >>  exemplary devices completely to demonstrate that the API changes fit
> >>  into the big picture.
> >
> >  My plan is:
> >
> >  - post RFC v1 with updated API in patch form
> >  - RFC v2 with implementation + significant fraction of PC devices coverted
> >  - PATCH v3 with full conversion an elimination of the old API
>
> And when introducing hierarchical registration, we will have to go
> through all of this once again. Plus the API may have to be changed
> again if it does not fulfill all requirements of the hierarchical region
> management. And we have no proof that it allows an efficient core
> implementation.

This API *is* hierarchical registration.  v2 will (hopefully) prove that 
it can be done efficiently.

What is missing is to make qdev and this API the same hierarchy.

> Before touching any device at all, what about building the
> infrastructure to manage and address memory regions hierarchically via
> qdev first? That could be started on a green field, then applied to the
> PC architecture, and finally rolled out for all.

I feel a lot less comfortable about it since it introduces more 
variables.  It also means a full conversion is impossible.

While doing it in one pass reduces the total effort, it increases the 
risk IMO.

-- 
error compiling committee.c: too many arguments to function