aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-06-02block: document child argument of bdrv_attach_child_common()Vladimir Sementsov-Ogievskiy
The logic around **child is not obvious: this reference is used not only to return resulting child, but also to rollback NULL value on transaction abort. So, let's add documentation and some assertions. While being here, drop extra declaration of bdrv_attach_child_noperm(). Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210601075218.79249-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block/file-posix: Try other fallbacks after invalid FALLOC_FL_ZERO_RANGEThomas Huth
If fallocate(... FALLOC_FL_ZERO_RANGE ...) returns EINVAL, it's likely an indication that the file system is buggy and does not implement unaligned accesses right. We still might be lucky with the other fallback fallocate() calls later in this function, though, so we should not return immediately and try the others first. Since FALLOC_FL_ZERO_RANGE could also return EINVAL if the file descriptor is not a regular file, we ignore this filesystem bug silently, without printing an error message for the user. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210527172020.847617-3-thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block/file-posix: Fix problem with fallocate(PUNCH_HOLE) on GPFSThomas Huth
A customer reported that running qemu-img convert -t none -O qcow2 -f qcow2 input.qcow2 output.qcow2 fails for them with the following error message when the images are stored on a GPFS file system : qemu-img: error while writing sector 0: Invalid argument After analyzing the strace output, it seems like the problem is in handle_aiocb_write_zeroes(): The call to fallocate(FALLOC_FL_PUNCH_HOLE) returns EINVAL, which can apparently happen if the file system has a different idea of the granularity of the operation. It's arguably a bug in GPFS, since the PUNCH_HOLE mode should not result in EINVAL according to the man-page of fallocate(), but the file system is out there in production and so we have to deal with it. In commit 294682cc3a ("block: workaround for unaligned byte range in fallocate()") we also already applied the a work-around for the same problem to the earlier fallocate(FALLOC_FL_ZERO_RANGE) call, so do it now similar with the PUNCH_HOLE call. But instead of silently catching and returning -ENOTSUP (which causes the caller to fall back to writing zeroes), let's rather inform the user once about the buggy file system and try the other fallback instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210527172020.847617-2-thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block: drop BlockBackendRootState::read_onlyVladimir Sementsov-Ogievskiy
Instead of keeping additional boolean field, let's store the information in BDRV_O_RDWR bit of BlockBackendRootState::open_flags. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210527154056.70294-4-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block: drop BlockDriverState::read_onlyVladimir Sementsov-Ogievskiy
This variable is just a cache for !(bs->open_flags & BDRV_O_RDWR), which we have to synchronize everywhere. Let's just drop it and consistently use bdrv_is_read_only(). Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210527154056.70294-3-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block: consistently use bdrv_is_read_only()Vladimir Sementsov-Ogievskiy
It's better to use accessor function instead of bs->read_only directly. In some places use bdrv_is_writable() instead of checking both BDRV_O_RDWR set and BDRV_O_INACTIVE not set. In bdrv_open_common() it's a bit strange to add one more variable, but we are going to drop bs->read_only in the next patch, so new ro local variable substitutes it here. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210527154056.70294-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block/vvfat: fix vvfat_child_perm crashVladimir Sementsov-Ogievskiy
It's wrong to rely on s->qcow in vvfat_child_perm, as on permission update during bdrv_open_child() call this field is not set yet. Still prior to aa5a04c7db27eea6b36de32f241b155f0d9ce34d, it didn't crash, as bdrv_open_child passed NULL as child to bdrv_child_perm(), and NULL was equal to NULL in assertion (still, it was bad guarantee for child being s->qcow, not backing :). Since aa5a04c7db27eea6b36de32f241b155f0d9ce34d "add bdrv_attach_child_noperm" bdrv_refresh_perms called on parent node when attaching child, and new correct child pointer is passed to .bdrv_child_perm. Still, s->qcow is NULL at the moment. Let's rely only on role instead. Without that fix, ./build/qemu-system-x86_64 -usb -device usb-storage,drive=fat16 \ -drive \ file=fat:rw:fat-type=16:"<path of a host folder>",id=fat16,format=raw,if=none crashes: (gdb) bt 0 raise () at /lib64/libc.so.6 1 abort () at /lib64/libc.so.6 2 _nl_load_domain.cold () at /lib64/libc.so.6 3 annobin_assert.c_end () at /lib64/libc.so.6 4 vvfat_child_perm (bs=0x559186f3d690, c=0x559186f1ed20, role=3, reopen_queue=0x0, perm=0, shared=31, nperm=0x7ffe56f28298, nshared=0x7ffe56f282a0) at ../block/vvfat.c:3214 5 bdrv_child_perm (bs=0x559186f3d690, child_bs=0x559186f60190, c=0x559186f1ed20, role=3, reopen_queue=0x0, parent_perm=0, parent_shared=31, nperm=0x7ffe56f28298, nshared=0x7ffe56f282a0) at ../block.c:2094 6 bdrv_node_refresh_perm (bs=0x559186f3d690, q=0x0, tran=0x559186f65850, errp=0x7ffe56f28530) at ../block.c:2336 7 bdrv_list_refresh_perms (list=0x559186db5b90 = {...}, q=0x0, tran=0x559186f65850, errp=0x7ffe56f28530) at ../block.c:2358 8 bdrv_refresh_perms (bs=0x559186f3d690, errp=0x7ffe56f28530) at ../block.c:2419 9 bdrv_attach_child (parent_bs=0x559186f3d690, child_bs=0x559186f60190, child_name=0x559184d83e3d "write-target", child_class=0x5591852f3b00 <child_vvfat_qcow>, child_role=3, errp=0x7ffe56f28530) at ../block.c:2959 10 bdrv_open_child (filename=0x559186f5cb80 "/var/tmp/vl.7WYmFU", options=0x559186f66c20, bdref_key=0x559184d83e3d "write-target", parent=0x559186f3d690, child_class=0x5591852f3b00 <child_vvfat_qcow>, child_role=3, allow_none=false, errp=0x7ffe56f28530) at ../block.c:3351 11 enable_write_target (bs=0x559186f3d690, errp=0x7ffe56f28530) at ../block/vvfat.c:3177 12 vvfat_open (bs=0x559186f3d690, options=0x559186f42db0, flags=155650, errp=0x7ffe56f28530) at ../block/vvfat.c:1236 13 bdrv_open_driver (bs=0x559186f3d690, drv=0x5591853d97e0 <bdrv_vvfat>, node_name=0x0, options=0x559186f42db0, open_flags=155650, errp=0x7ffe56f28640) at ../block.c:1557 14 bdrv_open_common (bs=0x559186f3d690, file=0x0, options=0x559186f42db0, errp=0x7ffe56f28640) at ../block.c:1833 ... (gdb) fr 4 #4 vvfat_child_perm (bs=0x559186f3d690, c=0x559186f1ed20, role=3, reopen_queue=0x0, perm=0, shared=31, nperm=0x7ffe56f28298, nshared=0x7ffe56f282a0) at ../block/vvfat.c:3214 3214 assert(c == s->qcow || (role & BDRV_CHILD_COW)); (gdb) p role $1 = 3 # BDRV_CHILD_DATA | BDRV_CHILD_METADATA (gdb) p *c $2 = {bs = 0x559186f60190, name = 0x559186f669d0 "write-target", klass = 0x5591852f3b00 <child_vvfat_qcow>, role = 3, opaque = 0x559186f3d690, perm = 3, shared_perm = 4, frozen = false, parent_quiesce_counter = 0, next = {le_next = 0x0, le_prev = 0x559186f41818}, next_parent = {le_next = 0x0, le_prev = 0x559186f64320}} (gdb) p s->qcow $3 = (BdrvChild *) 0x0 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210524101257.119377-3-vsementsov@virtuozzo.com> Tested-by: John Arbuckle <programmingkidx@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block/vvfat: child_vvfat_qcow: add .get_parent_aio_context, fix crashVladimir Sementsov-Ogievskiy
Commit 3ca1f3225727419ba573673b744edac10904276f "block: BdrvChildClass: add .get_parent_aio_context handler" introduced new handler and commit 228ca37e12f97788e05bd0c92f89b3e5e4019607 "block: drop ctx argument from bdrv_root_attach_child" made a generic use of it. But 3ca1f3225727419ba573673b744edac10904276f didn't update child_vvfat_qcow. Fix that. Before that fix the command ./build/qemu-system-x86_64 -usb -device usb-storage,drive=fat16 \ -drive file=fat:rw:fat-type=16:"<path of a host folder>",id=fat16,format=raw,if=none crashes: 1 bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 2 bdrv_attach_child_common (child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, perm=3, shared_perm=4, opaque=0x559d62445690, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2795 3 bdrv_attach_child_noperm (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2855 4 bdrv_attach_child (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, errp=0x7ffc74c2ae60) at ../block.c:2953 5 bdrv_open_child (filename=0x559d62464b80 "/var/tmp/vl.h3TIS4", options=0x559d6246ec20, bdref_key=0x559d606f9e3d "write-target", parent=0x559d62445690, child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, allow_none=false, errp=0x7ffc74c2ae60) at ../block.c:3351 6 enable_write_target (bs=0x559d62445690, errp=0x7ffc74c2ae60) at ../block/vvfat.c:3176 7 vvfat_open (bs=0x559d62445690, options=0x559d6244adb0, flags=155650, errp=0x7ffc74c2ae60) at ../block/vvfat.c:1236 8 bdrv_open_driver (bs=0x559d62445690, drv=0x559d60d4f7e0 <bdrv_vvfat>, node_name=0x0, options=0x559d6244adb0, open_flags=155650, errp=0x7ffc74c2af70) at ../block.c:1557 9 bdrv_open_common (bs=0x559d62445690, file=0x0, options=0x559d6244adb0, errp=0x7ffc74c2af70) at ... (gdb) fr 1 #1 0x0000559d603ea3bf in bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 1440 return c->klass->get_parent_aio_context(c); (gdb) p c->klass $1 = (const BdrvChildClass *) 0x559d60c58d20 <child_vvfat_qcow> (gdb) p c->klass->get_parent_aio_context $2 = (AioContext *(*)(BdrvChild *)) 0x0 Fixes: 3ca1f3225727419ba573673b744edac10904276f Fixes: 228ca37e12f97788e05bd0c92f89b3e5e4019607 Reported-by: John Arbuckle <programmingkidx@gmail.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210524101257.119377-2-vsementsov@virtuozzo.com> Tested-by: John Arbuckle <programmingkidx@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02qemu-io-cmds: assert that we don't have .perm requested in no-blk caseVladimir Sementsov-Ogievskiy
Coverity thinks blk may be NULL. It's a false-positive, as described in a new comment. Fixes: Coverity CID 1453194 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210519090532.3753-1-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02block/quorum: Provide .bdrv_co_flush instead of .bdrv_co_flush_to_diskLukas Straub
The quorum block driver uses a custom flush callback to handle the case when some children return io errors. In that case it still returns success if enough children are healthy. However, it provides it as the .bdrv_co_flush_to_disk callback, not as .bdrv_co_flush. This causes the block layer to do it's own generic flushing for the children instead, which doesn't handle errors properly. Fix this by providing .bdrv_co_flush instead of .bdrv_co_flush_to_disk so the block layer uses the custom flush callback. Signed-off-by: Lukas Straub <lukasstraub2@web.de> Reported-by: Minghao Yuan <meeho@qq.com> Message-Id: <20210518134214.11ccf05f@gecko.fritz.box> Tested-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-02Merge remote-tracking branch 'remotes/jsnow-gitlab/tags/python-pull-request' ↵Peter Maydell
into staging Pull request V2: - Squashed in fixup for 'Python: add utility function for retrieving port redirection' - Rebased on today's upstream CI here: https://gitlab.com/jsnow/qemu/-/pipelines/313202814 # gpg: Signature made Wed 02 Jun 2021 00:29:55 BST # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jsnow-gitlab/tags/python-pull-request: (44 commits) gitlab: add python linters to CI python: add tox support python: add .gitignore python: add Makefile for some common tasks python: add avocado-framework and tests python: add devel package requirements to setuptools python/qemu: add qemu package itself to pipenv python/qemu: add isort to pipenv python: move .isort.cfg into setup.cfg python: add mypy to pipenv python: move mypy.ini into setup.cfg python: Add flake8 to pipenv python: add excluded dirs to flake8 config python: move flake8 config to setup.cfg python: add pylint to pipenv python: move pylintrc into setup.cfg python: add pylint import exceptions python: Add pipenv support python: add MANIFEST.in python: add directory structure README.rst files ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-06-02configure: bump min required CLang to 6.0 / XCode 10.0Daniel P. Berrangé
Several distros have been dropped since the last time we bumped the minimum required CLang version. Per repology, currently shipping versions are: RHEL-8: 10.0.1 Debian Buster: 7.0.1 openSUSE Leap 15.2: 9.0.1 Ubuntu LTS 18.04: 6.0.0 Ubuntu LTS 20.04: 10.0.0 FreeBSD 12: 8.0.1 Fedora 33: 11.0.0 Fedora 34: 11.1.0 With this list Ubuntu LTS 18.04 is the constraint at 6.0.0 An LLVM version of 6.0.0 corresponds to macOS XCode version of 10.0 which dates from Sept 2018. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-13-berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02configure: bump min required GCC to 7.5.0Daniel P. Berrangé
Several distros have been dropped since the last time we bumped the minimum required GCC version. Per repology, currently shipping versions are: RHEL-8: 8.3.1 Debian Buster: 8.3.0 openSUSE Leap 15.2: 7.5.0 Ubuntu LTS 18.04: 7.5.0 Ubuntu LTS 20.04: 9.3.0 FreeBSD: 10.3.0 Fedora 33: 9.2.0 Fedora 34: 11.0.1 OpenBSD: 8.4.0 macOS HomeBrew: 11.1.0 With this list Ubuntu LTS 18.04 / openSUSE Leap 15.2 are the constraint at 7.5.0 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-12-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02configure: bump min required glib version to 2.56Daniel P. Berrangé
The glib version was not previously constrained by RHEL-7 since it rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of these are old enough that they are outside our platform support matrix now. Per repology, current shipping versions are: RHEL-8: 2.56.4 Debian Buster: 2.58.3 openSUSE Leap 15.2: 2.62.6 Ubuntu LTS 18.04: 2.56.4 Ubuntu LTS 20.04: 2.64.6 FreeBSD: 2.66.7 Fedora 33: 2.66.8 Fedora 34: 2.68.1 OpenBSD: 2.68.1 macOS HomeBrew: 2.68.1 Thus Ubuntu LTS 18.04 / RHEL-8 are the constraint for GLib version at 2.56 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-11-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02tests/docker: drop CentOS 7 containerDaniel P. Berrangé
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-10-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02tests/vm: convert centos VM recipe to CentOS 8Daniel P. Berrangé
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-9-berrange@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02crypto: drop used conditional checkDaniel P. Berrangé
The condition being tested has never been set since the day the code was first introduced. Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-8-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02crypto: bump min gnutls to 3.5.18, dropping RHEL-7 supportDaniel P. Berrangé
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. This lets us increment the minimum required gnutls version Per repology, current shipping versions are: RHEL-8: 3.6.14 Debian Buster: 3.6.7 openSUSE Leap 15.2: 3.6.7 Ubuntu LTS 18.04: 3.5.18 Ubuntu LTS 20.04: 3.6.13 FreeBSD: 3.6.15 Fedora 33: 3.6.16 Fedora 34: 3.7.1 OpenBSD: 3.6.15 macOS HomeBrew: 3.6.15 Ubuntu LTS 18.04 has the oldest version and so 3.5.18 is the new minimum. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-7-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> [thuth: rebased to use .gitlab-ci.d/buildtest.yml] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02crypto: bump min gcrypt to 1.8.0, dropping RHEL-7 supportDaniel P. Berrangé
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. This lets us increment the minimum required gcrypt version and assume that HMAC is always supported Per repology, current shipping versions are: RHEL-8: 1.8.5 Debian Buster: 1.8.4 openSUSE Leap 15.2: 1.8.2 Ubuntu LTS 18.04: 1.8.1 Ubuntu LTS 20.04: 1.8.5 FreeBSD: 1.9.2 Fedora 33: 1.8.6 Fedora 34: 1.9.3 OpenBSD: 1.9.3 macOS HomeBrew: 1.9.3 Ubuntu LTS 18.04 has the oldest version and so 1.8.0 is the new minimum. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-6-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: rebased to use .gitlab-ci.d/buildtest.yml] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02crypto: drop back compatibility typedefs for nettleDaniel P. Berrangé
Now that we only support modern nettle, we don't need to have local typedefs to mask the real nettle types. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-5-berrange@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02crypto: bump min nettle to 3.4, dropping RHEL-7 supportDaniel P. Berrangé
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. This lets us increment the minimum required nettle version and drop a lot of backwards compatibility code for 2.x series of nettle. Per repology, current shipping versions are: RHEL-8: 3.4.1 Debian Buster: 3.4.1 openSUSE Leap 15.2: 3.4.1 Ubuntu LTS 18.04: 3.4 Ubuntu LTS 20.04: 3.5.1 FreeBSD: 3.7.2 Fedora 33: 3.5.1 Fedora 34: 3.7.2 OpenBSD: 3.7.2 macOS HomeBrew: 3.7.2 Ubuntu LTS 18.04 has the oldest version and so 3.4 is the new minimum. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-4-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> [thuth: rebased to use .gitlab-ci.d/buildtest.yml] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02patchew: move quick build job from CentOS 7 to CentOS 8 containerDaniel P. Berrangé
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210514120415.1368922-3-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02block/ssh: Bump minimum libssh version to 0.8.7Thomas Huth
It has been over two years since RHEL-8 was released, and thus per the platform build policy, we no longer need to support RHEL-7 as a build target. So from the RHEL-7 perspective, we do not have to support libssh v0.7 anymore now. Let's look at the versions from other distributions and operating systems - according to repology.org, current shipping versions are: RHEL-8: 0.9.4 Debian Buster: 0.8.7 openSUSE Leap 15.2: 0.8.7 Ubuntu LTS 18.04: 0.8.0 * Ubuntu LTS 20.04: 0.9.3 FreeBSD: 0.9.5 Fedora 33: 0.9.5 Fedora 34: 0.9.5 OpenBSD: 0.9.5 macOS HomeBrew: 0.9.5 HaikuPorts: 0.9.5 * The version of libssh in Ubuntu 18.04 claims to be 0.8.0 from the name of the package, but in reality it is a 0.7 patched up as a Frankenstein monster with patches from the 0.8 development branch. This gave us some headaches in the past already and so it never worked with QEMU. All attempts to get it supported have failed in the past, patches for QEMU have never been merged and a request to Ubuntu to fix it in their 18.04 distro has been ignored: https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 Thus we really should ignore the libssh in Ubuntu 18.04 in QEMU, too. Fix it by bumping the minimum libssh version to something that is greater than 0.8.0 now. Debian Buster and openSUSE Leap have the oldest version and so 0.8.7 is the new minimum. Signed-off-by: Thomas Huth <thuth@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20210519155859.344569-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02docs: fix references to docs/devel/s390-dasd-ipl.rstStefano Garzarella
Commit cc3d15a5ea ("docs: rstfy s390 dasd ipl documentation") converted docs/devel/s390-dasd-ipl.txt to docs/devel/s390-dasd-ipl.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/s390-dasd-ipl.txt/s390-dasd-ipl.rst/ \ $(git grep -l docs/devel/s390-dasd-ipl.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20210517151702.109066-6-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02docs: fix references to docs/specs/tpm.rstStefano Garzarella
Commit 6e8a3ff6ed ("docs/specs/tpm: reST-ify TPM documentation") converted docs/specs/tpm.txt to docs/specs/tpm.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tpm.txt/tpm.rst/ $(git grep -l docs/specs/tpm.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-5-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02docs: fix references to docs/devel/build-system.rstStefano Garzarella
Commit a14f0bf165 ("docs: convert build system documentation to rST") converted docs/devel/build-system.txt to docs/devel/build-system.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/build-system.txt/build-system.rst/ \ $(git grep -l docs/devel/build-system.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20210517151702.109066-4-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02docs: fix references to docs/devel/atomics.rstStefano Garzarella
Commit 15e8699f00 ("atomics: convert to reStructuredText") converted docs/devel/atomics.txt to docs/devel/atomics.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/atomics.txt/atomics.rst/ $(git grep -l docs/devel/atomics.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-3-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-02docs: fix references to docs/devel/tracing.rstStefano Garzarella
Commit e50caf4a5c ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-01Merge remote-tracking branch ↵Peter Maydell
'remotes/ehabkost-gl/tags/x86-next-pull-request' into staging x86 queue, 2021-06-01 Features: * Add CPU model versions supporting 'xsaves' (Vitaly Kuznetsov) * Support AVX512 ZMM regs dump (Robert Hoo) Bug fixes: * Use better matching family/model/stepping for generic CPUs (Daniel P. Berrangé) Cleanups: * Hyper-V feature initialization cleanup (Vitaly Kuznetsov) * SEV firmware error list touchups (Connor Kuehl) * Constify CPUCaches and X86CPUDefinition (Philippe Mathieu-Daudé) * Document when features can be added to kvm_default_props (Eduardo Habkost) # gpg: Signature made Tue 01 Jun 2021 19:08:33 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost-gl/tags/x86-next-pull-request: (24 commits) sev: add missing firmware error conditions sev: use explicit indices for mapping firmware error codes to strings target/i386/sev: add support to query the attestation report i386: use global kvm_state in hyperv_enabled() check i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size i386: switch hyperv_expand_features() to using error_setg() i386: move eVMCS enablement to hyperv_init_vcpu() i386: split hyperv_handle_properties() into hyperv_expand_features()/hyperv_fill_cpuids() i386: introduce hv_cpuid_cache i386: drop FEAT_HYPERV feature leaves i386: introduce hv_cpuid_get_host() i386: introduce hyperv_feature_supported() i386: stop using env->features[] for filling Hyper-V CPUIDs i386: always fill Hyper-V CPUID feature leaves from X86CPU data i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough i386: keep hyperv_vendor string up-to-date i386: use better matching family/model/stepping for 'max' CPU i386: use better matching family/model/stepping for 'qemu64' CPU i386/cpu_dump: support AVX512 ZMM regs dump ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-06-01gitlab: add python linters to CIJohn Snow
Add a Python container that has just enough juice for us to run the Python code quality analysis tools. Base this container on Fedora, because Fedora has very convenient packaging for testing multiple Python versions. We need python3, pip (for pulling packages), pipenv and virtualenv for creating virtual environments, and tox for running tests. make is needed for running 'make check-tox' and 'make venv-check' targets. Python3.10 is needed explicitly because the tox package only pulls in 3.6-3.9, but we wish to test the forthcoming release of Python as well to help predict any problems. Lastly, we need gcc to compile PyPI packages that may not have a binary distribution available. Add two tests: check-python-pipenv uses pipenv to test a frozen, very explicit set of packages against our minimum supported python version, Python 3.6. This test is not allowed to fail. The dependencies this test uses do not change unless python/Pipfile.lock is changed. check-python-tox uses tox to install the latest versions of required python dependencies against a wide array of Python versions from 3.6 to 3.9, even including the yet-to-be-released Python 3.10. This test is allowed to fail with a warning. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-32-jsnow@redhat.com [Fix rebase conflict over .gitlab-ci.yml --js] Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add tox supportJohn Snow
This is intended to be a manually run, non-CI script. Use tox to test the linters against all python versions from 3.6 to 3.10. This will only work if you actually have those versions installed locally, but Fedora makes this easy: > sudo dnf install python3.6 python3.7 python3.8 python3.9 python3.10 Unlike the pipenv tests (make venv-check), this pulls "whichever" versions of the python packages, so they are unpinned and may break as time goes on. In the case that breakages are found, setup.cfg should be amended accordingly to avoid the bad dependant versions, or the code should be amended to work around the issue. With confidence that the tests pass on 3.6 through 3.10 inclusive, add the appropriate classifiers to setup.cfg to indicate which versions we claim to support. Tox 3.18.0 or above is required to use the 'allowlist_externals' option. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-31-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add .gitignoreJohn Snow
Ignore *Python* build and package output (build, dist, qemu.egg-info); these files are not created as part of a QEMU build. They are created by running the commands 'python3 setup.py <sdist|bdist>' when preparing tarballs to upload to e.g. PyPI. Ignore miscellaneous cached python confetti (mypy, pylint, et al) Ignore .idea (pycharm) .vscode, and .venv (pipenv et al). Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-30-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add Makefile for some common tasksJohn Snow
Add "make venv" to create the pipenv-managed virtual environment that contains our explicitly pinned dependencies. Add "make check" to run the python linters [in the host execution environment]. Add "make venv-check" which combines the above two: create/update the venv, then run the linters in that explicitly managed environment. Add "make develop" which canonizes the runes needed to get both the linting pre-requisites (the "[devel]" part), and the editable live-install (the "-e" part) of these python libraries. make clean: delete miscellaneous python packaging output possibly created by pipenv, pip, or other python packaging utilities make distclean: delete the above, the .venv, and the editable "qemu" package forwarder (qemu.egg-info) if there is one. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-29-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add avocado-framework and testsJohn Snow
Try using avocado to manage our various tests; even though right now they're only invoking shell scripts and not really running any python-native code. Create tests/, and add shell scripts which call out to mypy, flake8, pylint and isort to enforce the standards in this directory. Add avocado-framework to the setup.cfg development dependencies, and add avocado.cfg to store some preferences for how we'd like the test output to look. Finally, add avocado-framework to the Pipfile environment and lock the new dependencies. We are using avocado >= 87.0 here to take advantage of some features that Cleber has helpfully added to make the test output here *very* friendly and easy to read for developers that might chance upon the output in Gitlab CI. [Note: ALL of the dependencies get updated to the most modern versions that exist at the time of this writing. No way around it that I have seen. Not ideal, but so it goes.] Provided you have the right development dependencies (mypy, flake8, isort, pylint, and now avocado-framework) You should be able to run "avocado --config avocado.cfg run tests/" from the python folder to run all of these linters with the correct arguments. (A forthcoming commit adds the much easier 'make check'.) Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-28-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add devel package requirements to setuptoolsJohn Snow
setuptools doesn't have a formal understanding of development requires, but it has an optional feataures section. Fine; add a "devel" feature and add the requirements to it. To avoid duplication, we can modify pipenv to install qemu[devel] instead. This enables us to run invocations like "pip install -e .[devel]" and test the package on bleeding-edge packages beyond those specified in Pipfile.lock. Importantly, this also allows us to install the qemu development packages in a non-networked mode: `pip3 install --no-index -e .[devel]` will now fail if the proper development dependencies are not already met. This can be useful for automated build scripts where fetching network packages may be undesirable. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-27-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python/qemu: add qemu package itself to pipenvJohn Snow
This adds the python qemu packages themselves to the pipenv manifest. 'pipenv sync' will create a virtual environment sufficient to use the SDK. 'pipenv sync --dev' will create a virtual environment sufficient to use and test the SDK (with pylint, mypy, isort, flake8, etc.) The qemu packages are installed in 'editable' mode; all changes made to the python package inside the git tree will be reflected in the installed package without reinstallation. This includes changes made via git pull and so on. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-26-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python/qemu: add isort to pipenvJohn Snow
isort 5.0.0 through 5.0.4 has a bug that causes it to misinterpret certain "from ..." clauses that are not related to imports. isort < 5.1.1 has a bug where it does not handle comments near import statements correctly. Require 5.1.2 or greater. isort can be run (in "check" mode) with 'isort -c qemu' from the python root. isort can also be used to fix/rewrite import order automatically by using 'isort qemu'. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-25-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move .isort.cfg into setup.cfgJohn Snow
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-24-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add mypy to pipenvJohn Snow
0.730 appears to be about the oldest version that works with the features we want, including nice human readable output (to make sure iotest 297 passes), and type-parameterized Popen generics. 0.770, however, supports adding 'strict' to the config file, so require at least 0.770. Now that we are checking a namespace package, we need to tell mypy to allow PEP420 namespaces, so modify the mypy config as part of the move. mypy can now be run from the python root by typing 'mypy -p qemu'. A note on mypy invocation: Running it as "mypy qemu/" changes the import path detection mechanisms in mypy slightly, and it will fail. See https://github.com/python/mypy/issues/8584 for a decent entry point with more breadcrumbs on the various behaviors that contribute to this subtle difference. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-23-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move mypy.ini into setup.cfgJohn Snow
mypy supports reading its configuration values from a central project configuration file; do so. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-22-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: Add flake8 to pipenvJohn Snow
flake8 3.5.x does not support the --extend-ignore syntax used in the .flake8 file to gracefully extend default ignores, so 3.6.x is our minimum requirement. There is no known upper bound. flake8 can be run from the python/ directory with no arguments. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-21-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add excluded dirs to flake8 configJohn Snow
Instruct flake8 to avoid certain well-known directories created by python tooling that it ought not check. Note that at-present, nothing actually creates a ".venv" directory; but it is in such widespread usage as a de-facto location for a developer's virtual environment that it should be excluded anyway. A forthcoming commit canonizes this with a "make venv" command. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-20-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move flake8 config to setup.cfgJohn Snow
Update the comment concerning the flake8 exception to match commit 42c0dd12, whose commit message stated: A note on the flake8 exception: flake8 will warn on *any* bare except, but pylint's is context-aware and will suppress the warning if you re-raise the exception. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-19-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add pylint to pipenvJohn Snow
We are specifying >= pylint 2.8.x for several reasons: 1. For setup.cfg support, added in pylint 2.5.x 2. To specify a version that has incompatibly dropped bad-whitespace checks (2.6.x) 3. 2.7.x fixes "unsubscriptable" warnings in Python 3.9 4. 2.8.x adds a new, incompatible 'consider-using-with' warning that must be disabled in some cases. These pragmas cause warnings themselves in 2.7.x. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-18-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move pylintrc into setup.cfgJohn Snow
Delete the empty settings now that it's sharing a home with settings for other tools. pylint can now be run from this folder as "pylint qemu". Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-17-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add pylint import exceptionsJohn Snow
Pylint 2.5.x - 2.7.x have regressions that make import checking inconsistent, see: https://github.com/PyCQA/pylint/issues/3609 https://github.com/PyCQA/pylint/issues/3624 https://github.com/PyCQA/pylint/issues/3651 Pinning to 2.4.4 is worse, because it mandates versions of shared dependencies that are too old for features we want in isort and mypy. Oh well. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-16-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: Add pipenv supportJohn Snow
pipenv is a tool used for managing virtual environments with pinned, explicit dependencies. It is used for precisely recreating python virtual environments. pipenv uses two files to do this: (1) Pipfile, which is similar in purpose and scope to what setup.cfg lists. It specifies the requisite minimum to get a functional environment for using this package. (2) Pipfile.lock, which is similar in purpose to `pip freeze > requirements.txt`. It specifies a canonical virtual environment used for deployment or testing. This ensures that all users have repeatable results. The primary benefit of using this tool is to ensure *rock solid* repeatable CI results with a known set of packages. Although I endeavor to support as many versions as I can, the fluid nature of the Python toolchain often means tailoring code for fairly specific versions. Note that pipenv is *not* required to install or use this module; this is purely for the sake of repeatable testing by CI or developers. Here, a "blank" pipfile is added with no dependencies, but specifies Python 3.6 for the virtual environment. Pipfile will specify our version minimums, while Pipfile.lock specifies an exact loadout of packages that were known to operate correctly. This latter file provides the real value for easy setup of container images and CI environments. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-15-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add MANIFEST.inJohn Snow
When creating a source or binary distribution via 'python3 setup.py <sdist|bdist>', the VERSION and PACKAGE.rst files aren't bundled by default. Create a MANIFEST.in file that instructs the build tools to include these so that installation from these files won't fail. This is required by 'tox', as well as by the tooling needed to upload packages to PyPI. Exclude the 'README.rst' file -- that's intended as a guidebook to our source tree, not a file that needs to be distributed. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-14-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add directory structure README.rst filesJohn Snow
Add short readmes to python/, python/qemu/, python/qemu/machine, python/qemu/qmp, and python/qemu/utils that explain the directory hierarchy. These readmes are visible when browsing the source on e.g. gitlab/github and are designed to help new developers/users quickly make sense of the source tree. They are not designed for inclusion in a published manual. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-13-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add VERSION fileJohn Snow
Python infrastructure as it exists today is not capable reliably of single-sourcing a package version from a parent directory. The authors of pip are working to correct this, but as of today this is not possible. The problem is that when using pip to build and install a python package, it copies files over to a temporary directory and performs its build there. This loses access to any information in the parent directory, including git itself. Further, Python versions have a standard (PEP 440) that may or may not follow QEMU's versioning. In general, it does; but naturally QEMU does not follow PEP 440. To avoid any automatically-generated conflict, a manual version file is preferred. I am proposing: - Python tooling follows the QEMU version, indirectly, but with a major version of 0 to indicate that the API is not expected to be stable. This would mean version 0.5.2.0, 0.5.1.1, 0.5.3.0, etc. - In the event that a Python package needs to be updated independently of the QEMU version, a pre-release alpha version should be preferred, but *only* after inclusion to the qemu development or stable branches. e.g. 0.5.2.0a1, 0.5.2.0a2, and so on should be preferred prior to 5.2.0's release. - The Python core tooling makes absolutely no version compatibility checks or constraints. It *may* work with releases of QEMU from the past or future, but it is not required to. i.e., "qemu.machine" will, for now, remain in lock-step with QEMU. - We reserve the right to split the qemu package into independently versioned subpackages at a later date. This might allow for us to begin versioning QMP independently from QEMU at a later date, if we so choose. Implement this versioning scheme by adding a VERSION file and setting it to 0.6.0.0a1. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-12-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 07:27:08 +0000