DeveloperNews: Difference between revisions
m (Paolo's memory PULL has been merged last night) |
(Add datestamps to developer news entries) |
||
| Line 2: | Line 2: | ||
It is not a replacement for reading the mailing list nor a place to announce cool new [[Contribute/StartHere#Features|features]] for users. | It is not a replacement for reading the mailing list nor a place to announce cool new [[Contribute/StartHere#Features|features]] for users. | ||
* [[User:MichaelTsirkin|Michael S. Tsirkin]] is [http://www.mail-archive.com/kvm@vger.kernel.org/msg92073.html about to move] '''ACPI''' table generation code to qemu. Any patches that need ACPI support should integrate with that. | * '''2013-07-07''': [[User:MichaelTsirkin|Michael S. Tsirkin]] is [http://www.mail-archive.com/kvm@vger.kernel.org/msg92073.html about to move] '''ACPI''' table generation code to qemu. Any patches that need ACPI support should integrate with that. | ||
* [[User:Paolo Bonzini|Paolo]] has [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00798.html extended] '''MemoryRegion'''s to reference an '''owner''' Object. Therefore new MemoryRegions should not carry the name of its containing device but its purpose within that device.<br/> Note that this pull touches on ''every'' <code>memory_region_init()</code>, <code>memory_region_init_io()</code> and <code>memory_region_init_ram()</code> in the tree (in patch 18/66) and is thus likely to conflict with any patch adding a new device. | * '''2013-07-05''': [[User:Paolo Bonzini|Paolo]] has [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00798.html extended] '''MemoryRegion'''s to reference an '''owner''' Object. Therefore new MemoryRegions should not carry the name of its containing device but its purpose within that device.<br/> Note that this pull touches on ''every'' <code>memory_region_init()</code>, <code>memory_region_init_io()</code> and <code>memory_region_init_ram()</code> in the tree (in patch 18/66) and is thus likely to conflict with any patch adding a new device. | ||
* The staging tree '''[https://github.com/afaerber/qemu-cpu/commits/qom-next qom-next]''' was [http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg05470.html revived] by [[User:AF|Andreas]] for '''QOM refactoring''' patches (type constants, cast macros, QOM realize). It should not be used as base for new feature or bugfix patches. | * '''2013-07-05''': The staging tree '''[https://github.com/afaerber/qemu-cpu/commits/qom-next qom-next]''' was [http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg05470.html revived] by [[User:AF|Andreas]] for '''QOM refactoring''' patches (type constants, cast macros, QOM realize). It should not be used as base for new feature or bugfix patches. | ||
* All new devices derived from '''SysBusDevice''' should [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00041.html use QOM realize] (DeviceClass::'''realize''') rather than SysBusDeviceClass::init. Work is under way to convert existing devices. It is permissable to implement neither realize [http://git.qemu.org/?p=qemu.git;a=commit;h=4ce5dae88ecf2bafa0cd663de7e923728b1b3672 nor init].<br/> QOM realize was first [http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04025.html presented] by [[User:AnthonyLiguori|Anthony]] on the 2012-01-31 KVM call and after much debate of scope [http://git.qemu.org/?p=qemu.git;a=commit;h=249d41720b7dfbb5951b430b9eefdbee7464f515 minimally implemented] for DeviceState by [[User:AF|Andreas]] for v1.4. Some extensions by [[User:Paolo Bonzini|Paolo]] (recursive realization) are still pending device preparations. | * '''2013-07-05''': All new devices derived from '''SysBusDevice''' should [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00041.html use QOM realize] (DeviceClass::'''realize''') rather than SysBusDeviceClass::init. Work is under way to convert existing devices. It is permissable to implement neither realize [http://git.qemu.org/?p=qemu.git;a=commit;h=4ce5dae88ecf2bafa0cd663de7e923728b1b3672 nor init].<br/> QOM realize was first [http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04025.html presented] by [[User:AnthonyLiguori|Anthony]] on the 2012-01-31 KVM call and after much debate of scope [http://git.qemu.org/?p=qemu.git;a=commit;h=249d41720b7dfbb5951b430b9eefdbee7464f515 minimally implemented] for DeviceState by [[User:AF|Andreas]] for v1.4. Some extensions by [[User:Paolo Bonzini|Paolo]] (recursive realization) are still pending device preparations. | ||
* It has been requested to mark PULL request patches <code>[PULL n/m]</code> (rather than <code>[PATCH n/m]</code>) to avoid prompting people in CC to start re-reviewing an in-flight PULL request. | * '''2013-07-05''': It has been requested to mark PULL request patches <code>[PULL n/m]</code> (rather than <code>[PATCH n/m]</code>) to avoid prompting people in CC to start re-reviewing an in-flight PULL request. | ||
* [[Planning/1.6|v'''1.6''' roadmap]] has been added by [[User:AnthonyLiguori|Anthony]]. | * '''2013-07-05''': [[Planning/1.6|v'''1.6''' roadmap]] has been added by [[User:AnthonyLiguori|Anthony]]. | ||
* Page [[QOMConventions|'''QOM'''Conventions]] was created by [[User:AF|Andreas]] to summarize some review comments and acceptance guidelines for patches that affect '''all devices'''. | * '''2013-07-05''': Page [[QOMConventions|'''QOM'''Conventions]] was created by [[User:AF|Andreas]] to summarize some review comments and acceptance guidelines for patches that affect '''all devices'''. | ||
* An '''I2C''' libqos test framework was [http://git.qemu.org/?p=qemu.git;a=commit;h=2bf7b4572b39a494403190636b4e7d44967504c0 contributed] by [[User:AF|Andreas]], so any new I2C host controllers should come with a libqos driver implementation and new I2C devices should be accompanied by a qtest test case. | * '''2013-07-05''': An '''I2C''' libqos test framework was [http://git.qemu.org/?p=qemu.git;a=commit;h=2bf7b4572b39a494403190636b4e7d44967504c0 contributed] by [[User:AF|Andreas]], so any new I2C host controllers should come with a libqos driver implementation and new I2C devices should be accompanied by a qtest test case. | ||
Revision as of 15:22, 28 April 2014
This page highlights some news bits from qemu-devel that all QEMU developers should be aware of. It is not a replacement for reading the mailing list nor a place to announce cool new features for users.
- 2013-07-07: Michael S. Tsirkin is about to move ACPI table generation code to qemu. Any patches that need ACPI support should integrate with that.
- 2013-07-05: Paolo has extended MemoryRegions to reference an owner Object. Therefore new MemoryRegions should not carry the name of its containing device but its purpose within that device.
Note that this pull touches on everymemory_region_init(),memory_region_init_io()andmemory_region_init_ram()in the tree (in patch 18/66) and is thus likely to conflict with any patch adding a new device. - 2013-07-05: The staging tree qom-next was revived by Andreas for QOM refactoring patches (type constants, cast macros, QOM realize). It should not be used as base for new feature or bugfix patches.
- 2013-07-05: All new devices derived from SysBusDevice should use QOM realize (DeviceClass::realize) rather than SysBusDeviceClass::init. Work is under way to convert existing devices. It is permissable to implement neither realize nor init.
QOM realize was first presented by Anthony on the 2012-01-31 KVM call and after much debate of scope minimally implemented for DeviceState by Andreas for v1.4. Some extensions by Paolo (recursive realization) are still pending device preparations. - 2013-07-05: It has been requested to mark PULL request patches
[PULL n/m](rather than[PATCH n/m]) to avoid prompting people in CC to start re-reviewing an in-flight PULL request. - 2013-07-05: v1.6 roadmap has been added by Anthony.
- 2013-07-05: Page QOMConventions was created by Andreas to summarize some review comments and acceptance guidelines for patches that affect all devices.
- 2013-07-05: An I2C libqos test framework was contributed by Andreas, so any new I2C host controllers should come with a libqos driver implementation and new I2C devices should be accompanied by a qtest test case.