DeveloperNews: Difference between revisions

From QEMU
No edit summary
mNo edit summary
Line 1: Line 1:
This page highlights some news bits from [https://lists.nongnu.org/mailman/listinfo/qemu-devel qemu-devel] that all QEMU developers should be aware of.
This page highlights some news bits from [https://lists.nongnu.org/mailman/listinfo/qemu-devel 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 [[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.
 
* [[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]] is [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00798.html about to extend] '''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.
* [[User:Paolo Bonzini|Paolo]] is [http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg00798.html about to extend] '''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.
* 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.

Revision as of 09:20, 8 July 2013

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.

  • Michael S. Tsirkin is about to move ACPI table generation code to qemu. Any patches that need ACPI support should integrate with that.
  • Paolo is about to extend 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 every memory_region_init(), memory_region_init_io() and memory_region_init_ram() in the tree (in patch 18/66) and is thus likely to conflict with any patch adding a new device.
  • 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.
  • 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.
  • 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.
  • v1.6 roadmap has been added by Anthony.
  • Page QOMConventions was created by Andreas to summarize some review comments and acceptance guidelines for patches that affect all devices.
  • 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.