[RFC,02/18] pc: create PC object on pc_init1()

It would be interesting to make the generic machine intialization code
create a machine object instead, but changing the machine initialization
function signature is a nightmare, so by now I am creating the object
inside pc_init1().

The object is not used for anything by now, but it will be used during
some steps of the initialization, later.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 hw/pc_piix.c | 3 +++
 1 file changed, 3 insertions(+)

Il 03/10/2012 15:28, Eduardo Habkost ha scritto:
> It would be interesting to make the generic machine intialization code
> create a machine object instead, but changing the machine initialization
> function signature is a nightmare, so by now I am creating the object
> inside pc_init1().
> 
> The object is not used for anything by now, but it will be used during
> some steps of the initialization, later.
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/pc_piix.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index fd5898f..28b5f8a 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -148,6 +148,7 @@ static void pc_init1(MemoryRegion *system_memory,
>      MemoryRegion *pci_memory;
>      MemoryRegion *rom_memory;
>      void *fw_cfg = NULL;
> +    PC *pc = PC(object_new(TYPE_PC_MACHINE));
>  
>      pc_cpus_init(cpu_model);
>  
> @@ -285,6 +286,8 @@ static void pc_init1(MemoryRegion *system_memory,
>      if (pci_enabled) {
>          pc_pci_device_init(pci_bus);
>      }
> +
> +    qdev_init_nofail(DEVICE(pc));
>  }
>  
>  static void pc_init_pci(ram_addr_t ram_size,
> 

Can you add a hook to QEMUMachine so that this object is created by
qdev_get_machine() and ends up at /machine?

Paolo

On Wed, Oct 03, 2012 at 04:40:06PM +0200, Paolo Bonzini wrote:
> Il 03/10/2012 15:28, Eduardo Habkost ha scritto:
> > It would be interesting to make the generic machine intialization code
> > create a machine object instead, but changing the machine initialization
> > function signature is a nightmare, so by now I am creating the object
> > inside pc_init1().
> > 
> > The object is not used for anything by now, but it will be used during
> > some steps of the initialization, later.
> > 
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  hw/pc_piix.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index fd5898f..28b5f8a 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -148,6 +148,7 @@ static void pc_init1(MemoryRegion *system_memory,
> >      MemoryRegion *pci_memory;
> >      MemoryRegion *rom_memory;
> >      void *fw_cfg = NULL;
> > +    PC *pc = PC(object_new(TYPE_PC_MACHINE));
> >  
> >      pc_cpus_init(cpu_model);
> >  
> > @@ -285,6 +286,8 @@ static void pc_init1(MemoryRegion *system_memory,
> >      if (pci_enabled) {
> >          pc_pci_device_init(pci_bus);
> >      }
> > +
> > +    qdev_init_nofail(DEVICE(pc));
> >  }
> >  
> >  static void pc_init_pci(ram_addr_t ram_size,
> > 
> 
> Can you add a hook to QEMUMachine so that this object is created by
> qdev_get_machine() and ends up at /machine?

Oh, I didn't know there was an existing "machine" object already, I
didn't know qdev_get_machine().

Shouldn't /machine be a child of the "container" class? That leads to
the other question you asked in another message: in this case, PC
wouldn't be a child of DeviceState, and we would need an additional
mechanism to allow non-DeviceState objects to use global properties.

(The sole reason I introduced the PC class was to allow the PC code to
use the compatibility "contiguous_apic_ids" global property.)

Il 03/10/2012 16:53, Eduardo Habkost ha scritto:
>> > 
>> > Can you add a hook to QEMUMachine so that this object is created by
>> > qdev_get_machine() and ends up at /machine?
> Oh, I didn't know there was an existing "machine" object already, I
> didn't know qdev_get_machine().
> 
> Shouldn't /machine be a child of the "container" class?

It should, but note that "container" is really just the same as
TYPE_OBJECT.  It is only for clarity that a difference class is used.
So using TYPE_DEVICE for now is not too bad.

Paolo

> That leads to
> the other question you asked in another message: in this case, PC
> wouldn't be a child of DeviceState, and we would need an additional
> mechanism to allow non-DeviceState objects to use global properties.
> 
> (The sole reason I introduced the PC class was to allow the PC code to
> use the compatibility "contiguous_apic_ids" global property.)