On Tue, Jun 17, 2014 at 6:05 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 17/06/2014 09:16, Stefan Hajnoczi ha scritto: > >> > The bigger issue though is how do you do an N:1 mapping. The container >> > should only have 1 "midr" prop, but it should mirror to all contained >> > CPUs. Should we add multiplicity to the aliasing feature? >> >> If we'll need 1:N alias properties in other places too.
Well A15 MPCore is the obvious one. Any homogeneous n-way container that wants to forward props could make use of this. > > > I think in the case it's the contained object that should look for a midr > property in the parent, and possibly create an alias to the parent's midr > property. > This sounds too difficult to me. How do you define whether a contained object is allowed to go looking into a parent for suitable aliasing oppurtunities without container level knowledge? The contained object should also be able to create it's property regularly in cases where the parent does not provide an aliasable which adds some ugly iffery to the contained's init fn. Ultimately I think the container should remain in full control and do the 1:N aliasing in a loop when appropriate. And some further food for thought, if we throw Andreas' heterogenous MPCore idea (one of the tangent topics on this thread) in the mix, a container will want to potentially alias the same property on two different children to two different props on the child. The child simply cannot handle this without knowing too much about it's container. Regards, Peter > Paolo >
