Features/Version3.0: Difference between revisions
(Add q35 idea) |
mNo edit summary |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Note: This page is used to gather ideas about what we could do when switching to the next major version of QEMU, i.e. version 3.0. The ideas here are by no means mandatory - it is rather meant as a base for discussion. | Note: This page is used to gather ideas about what we could do when switching to the next major version of QEMU, i.e. version 3.0. The ideas here are by no means mandatory - it is rather meant as a base for discussion. | ||
So for version 3.0, we very likely should do the following: | So for version 3.0, we very likely should do the following: | ||
* Make sure that we remove all | * Make sure that we remove all interfaces and features that are marked as deprecated since two releases according to the qemu-doc deprecation chapter (see https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features for details) | ||
* Use "--accel kvm | * Use "--accel kvm:tcg" by default instead of running in TCG mode by default (hax is too far from feature parity, but we could also add "hvf" to the list in case it gets merged in time and is stable enough) | ||
* Stop supporting SDL 1.2 | * Stop supporting SDL 1.2 | ||
* Stop supporting GTK2 | |||
Controversial ideas that likely need some discussion first: | Controversial ideas that likely need some discussion first: | ||
* Update all python code to use python 3.x instead of python 2.x | |||
* Get rid of some really, really old and very likely completely unused machine types, like pc-0.10 and pc-0.11 | * Get rid of some really, really old and very likely completely unused machine types, like pc-0.10 and pc-0.11 | ||
* Remove some code which is likely hardly used anymore and where we do not have an active maintainer since years? Especially if we do not have an "make check" regression test for it. (i.e. did anybody test the bluetooth code in the recent years?) | * Remove some code which is likely hardly used anymore and where we do not have an active maintainer since years? Especially if we do not have an "make check" regression test for it. (i.e. did anybody test the bluetooth code in the recent years?) | ||
** Samsung was using it as recently as 2014. Also don't underestimate the Android emulator, it's in widespread use. | ** Samsung was using it as recently as 2014. Also don't underestimate the Android emulator, it's in widespread use. | ||
* Use q35 as default instead of pc-i440fx ? We likely can not do it due to compatibility issues ... but let's keep it in mind in case somebody comes up with a clever solution... | * Use q35 as default instead of pc-i440fx ? We likely can not do it due to compatibility issues ... but let's keep it in mind in case somebody comes up with a clever solution... | ||
* Use getopt_long() to parse the CLI parameters, to get more "standard" behaviour of the options. Our tools like qemu-img already use getopt_long so this would also unify the behaviour between the QEMU binaries. | |||
* Since compilation and testing time for QEMU is really huge, we could get rid of some QEMU binaries: qemu-system-aarch64 is a superset of qemu-system-arm, qemu-system-x86_64 is a superset of qemu-system-i386 and qemu-system-ppc64 is a superset of qemu-system-ppc (and qemu-system-ppcemb). Would be feasible to get rid of the subset binaries with some work? | |||
Latest revision as of 16:20, 27 April 2018
Note: This page is used to gather ideas about what we could do when switching to the next major version of QEMU, i.e. version 3.0. The ideas here are by no means mandatory - it is rather meant as a base for discussion.
So for version 3.0, we very likely should do the following:
- Make sure that we remove all interfaces and features that are marked as deprecated since two releases according to the qemu-doc deprecation chapter (see https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features for details)
- Use "--accel kvm:tcg" by default instead of running in TCG mode by default (hax is too far from feature parity, but we could also add "hvf" to the list in case it gets merged in time and is stable enough)
- Stop supporting SDL 1.2
- Stop supporting GTK2
Controversial ideas that likely need some discussion first:
- Update all python code to use python 3.x instead of python 2.x
- Get rid of some really, really old and very likely completely unused machine types, like pc-0.10 and pc-0.11
- Remove some code which is likely hardly used anymore and where we do not have an active maintainer since years? Especially if we do not have an "make check" regression test for it. (i.e. did anybody test the bluetooth code in the recent years?)
- Samsung was using it as recently as 2014. Also don't underestimate the Android emulator, it's in widespread use.
- Use q35 as default instead of pc-i440fx ? We likely can not do it due to compatibility issues ... but let's keep it in mind in case somebody comes up with a clever solution...
- Use getopt_long() to parse the CLI parameters, to get more "standard" behaviour of the options. Our tools like qemu-img already use getopt_long so this would also unify the behaviour between the QEMU binaries.
- Since compilation and testing time for QEMU is really huge, we could get rid of some QEMU binaries: qemu-system-aarch64 is a superset of qemu-system-arm, qemu-system-x86_64 is a superset of qemu-system-i386 and qemu-system-ppc64 is a superset of qemu-system-ppc (and qemu-system-ppcemb). Would be feasible to get rid of the subset binaries with some work?