On Thu, Oct 04, 2012 at 09:28:13AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonz...@redhat.com> writes:
>
> > Il 04/10/2012 15:46, Anthony Liguori ha scritto:
> >>> > +typedef struct PC {
> >>> > + DeviceState parent_obj;
> >>> > +} PC;
> >> So the general problem with this approach is that it strays from
> >> modeling hardware.
> >
> > It doesn't really; it's a motherboard object, there's no reason why
> > /machine shouldn't be a Device itself, with a few objects (CPUs, the
> > i440FX, the IOAPIC, and of course the peripherals) hanging off it.
>
> Okay, but modeling a motherboard is different than creating a "PC"
> object and throwing in the kitchen skink.
>
> And I'm not sure that going top-down is the best strategy. I think
> going bottom up makes more sense (starting with modeling Super IO chip).
>
So, would you be OK with this implementation if the class were named
"Motherboard", "set-of-CPU-sockets", or something like that?
(The change on the APIC ID generation logic is not something that
affects only individual CPUs or APICs, but the fw_cfg NUMA & CPU hotplug
code as well, that's why I don't think "contiguous_apic_ids" should be a
property of CPU or APIC objects).
> Regards,
>
> Anthony Liguori
>
> >
> > Paolo
--
Eduardo
