qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to ta


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM
Date: Mon, 26 Mar 2012 17:17:48 +0000

On Mon, Mar 26, 2012 at 12:20, Jan Kiszka <address@hidden> wrote:
> On 2012-03-26 04:06, Wanpeng Li wrote:
>> From: Anthony Liguori <address@hidden>
>>
>>
>> This series aggressively refactors the PC machine initialization to be more
>> modelled and less ad-hoc.  The highlights of this series are:
>>
>>  1) Things like -m and -bios-name are now device model properties
>>
>>  2) The i440fx and piix3 are now modelled in a thorough fashion
>>
>>  3) Most of the chipset features of the piix3 are modelled through 
>> composition
>>
>>  4) i440fx_init is trivialized to creating devices and setting properties
>>
>>  5) convert MemoryRegion to QOM
>>
>>  6) convert PCI host bridge to QOM
>>
>> The point (4) is the most important one.  As we refactor in this fashion,
>> we should quickly get to the point where machine->init disappears completely 
>> in
>> favor of just creating a handful of devices.
>>
>> The two stage initialization of QOM is important here.  instance_init() is 
>> when
>> composed devices are created which means that after you've created a device, 
>> all
>> of its children are visible in the device model.  This lets you set 
>> properties
>> of the parent and its children.
>>
>> realize() (which is still called DeviceState::init today) will be called 
>> right
>> before the guest starts up for the first time.
>
> While I see the value of the overall direction, I still disagree on
> making internal data structures of HPET, RTC and 8254 publicly
> available. That's a wrong step back. I'm sure there are smarter
> solutions, alse as there were some proposals back then in the original
> thread.

Fully agree. At least there should be something like this memory.c line:

/* All fields are private - violators will be prosecuted */

or other C++-ish comments about the fields being private to the class.
Device classes should not have friend classes except in exceptional
cases like LAPIC/RTC.

> I'm also sure we will have to refactor the merge significantly again for
> the introduction of additional chipsets and PC boards. But unless those
> requirements can already be specified (Isaku?), that might be unavoidable.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]