On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas Färber wrote: > Am 08.06.2012 10:20, schrieb Igor Mammedov: > > On Wed, May 23, 2012 at 05:07:27AM +0200, Andreas Färber wrote: > > This is touching on a core QOM question: Can we link<> during initfn? > That's what you're trying to do for the APIC and why this may be too > late in your case. I believe the answer to that question must be no. Yep, it's more of general question. Potentially any property could be set in initfn to intialize defaults and a property setter could create a link causing chicken/egg conflict. If making link<> to object is not permited till its initfn is done then when it is permited to be made? Maybe object_new() should take parent as parameter or maybe due to limitation we should revise purpose of link<>s /if they are replacement of ptr properties/?
[...] > Another factor that is making this slightly difficult is that there are > three APIC subclasses. Currently they all have an instance_size of > sizeof(APICCommonState) so it could be created in-place if it actually > is a part (child<>) of the CPU wrt hot-plug. Creating objects with > object_new() in QOM instance_init is forbidden. Any particular reason why object_new() in intifn is not acceptable? > [...] > > Maybe this CPU hot-plug business would be a good topic for a KVM call? It's more that I'm unhappy about wrong cpu creation order in pc_new_cpu() at the present code. For hotplug qdev_device_add makes new object as a child<> when it's created and it just needs to be placed before other properties are set. > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >