Re: [Libguestfs] [libnbd PATCH v3 01/29] use space consistently in function and function-like macro invocations

On Wed, Feb 15, 2023 at 01:48:39PM -0600, Eric Blake wrote: > In my experience with GNU code (which this is not), the style I've > seen there is to omit () whenever possible, as in: > > #if defined __GNUC__ > > or even > > #ifdef __GNUC__ I didn't know this was possible. I checked it. GCC

[Libguestfs] [PATCH v2v v2 0/3] Use host-model

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/thread.html#30694 I made a few changes in v2 but overall decided to keep the now unused gcaps_arch_min_version capability. This doesn't preclude removing it in future if we think it's never going to be useful. I

[Libguestfs] [PATCH v2v v2 2/3] -o libvirt: Always use host-model unless overridden by source hypervisor

In the case where the source hypervisor doesn't specify a CPU model, previously we chose qemu64 (qemu's most basic model), except for a few guests that we know won't work on qemu64, eg. RHEL 9 requires x86_64-v2 where we use However we recently encountered an obscure KVM bug related to this

[Libguestfs] [PATCH v2v v2 3/3] -o qemu: Always use -cpu host unless overridden by source hypervisor

As with the prior commit, prefer -cpu host for all guests (except when we have more information from the source hypervisor). Although there is the disadvantage that -cpu host is non-migratable, in practice it would be very difficult to live migrate a host launched using direct qemu commands.

[Libguestfs] [PATCH v2v v2 1/3] v2v: Rename gcaps_default_cpu to gcaps_arch_min_version

Some guests require not just a specific architecture, but cannot run on qemu's default CPU model, eg. requiring x86_64-v2. Since we anticipate future guests requiring higher versions, let's encode the minimum architecture version instead of a simple boolean. This patch essentially just remaps:

Re: [Libguestfs] [PATCH] python: Avoid leaking py_array along error paths

On Thu, Feb 16, 2023 at 03:23:51PM +, Richard W.M. Jones wrote: > See-also: > https://listman.redhat.com/archives/libguestfs/2023-February/030730.html > Fixes: commit 6ef5837e2d8c5d4d83eff51c0201eb2e08f719de > Thanks: Laszlo Ersek > --- > python/handle.c | 1 + > 1 file changed, 1

Re: [Libguestfs] [libnbd PATCH v3 01/29] use space consistently in function and function-like macro invocations

On Fri, Feb 17, 2023 at 11:49:58AM +, Richard W.M. Jones wrote: > On Wed, Feb 15, 2023 at 01:48:39PM -0600, Eric Blake wrote: > > In my experience with GNU code (which this is not), the style I've > > seen there is to omit () whenever possible, as in: > > > > #if defined __GNUC__ > > > > or

Re: [Libguestfs] python: Avoid leaking py_array and py_args in event callbacks

Sorry, ignore this, I found yet another problem. Will post v3. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch

Re: [Libguestfs] [PATCH] python: Avoid leaking py_array along error paths

On Fri, Feb 17, 2023 at 10:54:26AM -0600, Eric Blake wrote: > On Thu, Feb 16, 2023 at 03:23:51PM +, Richard W.M. Jones wrote: > > See-also: > > https://listman.redhat.com/archives/libguestfs/2023-February/030730.html > > Fixes: commit 6ef5837e2d8c5d4d83eff51c0201eb2e08f719de > > Thanks:

[Libguestfs] [PATCH v3 0/2] python: Avoid leaking py_array and py_args in event callbacks

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/030732.html (Ignore version 2 which had a mistake, this is version 3) Following Eric's suggestion here: https://listman.redhat.com/archives/libguestfs/2023-February/030746.html let's decrement the reference

[Libguestfs] [PATCH v3 1/2] Revert "python: fix call of Python handlers of events"

This reverts commit 85235aec837716f1ddb2926b9a59a02543195500. --- python/handle.c | 1 - 1 file changed, 1 deletion(-) diff --git a/python/handle.c b/python/handle.c index bf639b5789..8eeabe60a7 100644 --- a/python/handle.c +++ b/python/handle.c @@ -139,7 +139,6 @@

[Libguestfs] [PATCH v3 2/2] python: Avoid leaking py_array and py_args in event callbacks

See also: https://listman.redhat.com/archives/libguestfs/2023-February/030730.html https://listman.redhat.com/archives/libguestfs/2023-February/030745.html https://listman.redhat.com/archives/libguestfs/2023-February/030746.html Fixes: commit 6ef5837e2d8c5d4d83eff51c0201eb2e08f719de Thanks:

[Libguestfs] [supermin PATCH] Add support for OCaml 5.0

Hi, Here is a patch to add support to OCaml 5.0 to supermin: https://github.com/libguestfs/supermin/commit/01a6f2cfdb44d6140f11dbd00f13ceb9e45892c7 Note: As with my hivex patch, this patch also breaks support for OCaml < 4.07. If you want to keep support for those versions you can apply the

[Libguestfs] python: Avoid leaking py_array and py_args in event callbacks

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/030732.html Following Eric's suggestion here: https://listman.redhat.com/archives/libguestfs/2023-February/030746.html let's decrement the reference of py_array right after adding it to the args. (This works

[Libguestfs] [PATCH v2] python: Avoid leaking py_array and py_args in event callbacks

See also: https://listman.redhat.com/archives/libguestfs/2023-February/030730.html https://listman.redhat.com/archives/libguestfs/2023-February/030745.html https://listman.redhat.com/archives/libguestfs/2023-February/030746.html Fixes: commit 6ef5837e2d8c5d4d83eff51c0201eb2e08f719de Thanks:

Re: [Libguestfs] [PATCH 1/2] python: Avoid crash if callback parameters cannot be built

On Thu, Feb 16, 2023 at 03:09:02PM +0100, Laszlo Ersek wrote: > On 2/14/23 19:51, Richard W.M. Jones wrote: > > In the case that building the parameters to the Python event callback > > fails, args was returned as NULL. We immediately tried to call > > Py_INCREF on this which crashed. Returning

Re: [Libguestfs] [libnbd PATCH v3 12/29] socket activation: clean up responsibilities of prep.sock.act.env.()

On Wed, Feb 15, 2023 at 04:39:35PM +, Richard W.M. Jones wrote: > On Wed, Feb 15, 2023 at 03:11:41PM +0100, Laszlo Ersek wrote: > > prepare_socket_activation_environment() is a construction function that is > > supposed to fill in a string_vector object from the ground up. Right now > > it has

Re: [Libguestfs] [supermin PATCH] Add support for OCaml 5.0

On Fri, Feb 17, 2023 at 05:49:35PM +, Kate Deplaix wrote: > Hi, > > Here is a patch to add support to OCaml 5.0 to supermin: > https://github.com/libguestfs/supermin/commit/ > 01a6f2cfdb44d6140f11dbd00f13ceb9e45892c7 > > Note: As with my hivex patch, this patch also breaks support for OCaml

Re: [Libguestfs] [PATCH v2v 1/3] v2v: Rename gcaps_default_cpu to gcaps_arch_min_version

On Fri, Feb 17, 2023 at 08:53:42AM +0100, Laszlo Ersek wrote: > On 2/15/23 15:12, Richard W.M. Jones wrote: > > Some guests require not just a specific architecture, but cannot run > > on qemu's default CPU model, eg. requiring x86_64-v2. Since we > > anticipate future guests requiring higher

Re: [Libguestfs] [PATCH v2v 2/3] -o libvirt: Always use host-model unless overridden by source hypervisor

On 2/15/23 15:12, Richard W.M. Jones wrote: > In the case where the source hypervisor doesn't specify a CPU model, > previously we chose qemu64 (qemu's most basic model), except for a few > guests that we know won't work on qemu64, eg. RHEL 9 requires > x86_64-v2 where we use > > However we

Re: [Libguestfs] [PATCH v2v 3/3] -o qemu: Always use -cpu host unless overridden by source hypervisor

On 2/17/23 08:55, Laszlo Ersek wrote: > On 2/15/23 15:12, Richard W.M. Jones wrote: >> As with the prior commit, prefer -cpu host for all guests (except when >> we have more information from the source hypervisor). Although there >> is the disadvantage that -cpu host is non-migratable, in