similar to: [PATCH nbdkit 0/2 v2] golang: Compile against the local nbdkit build.

Version 2: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00166 Version 3 contains all changes discussed in the previous review. Rich.

On 4/23/20 2:13 PM, Richard W.M. Jones wrote: > Compiling nbdkit from source when an older nbdkit is installed would > fail because certain symbols such as .get_ready are not defined in the > (installed) <nbdkit-plugin.h>: > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) >

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

Compiling nbdkit from source when an older nbdkit is installed would fail because certain symbols such as .get_ready are not defined in the (installed) <nbdkit-plugin.h>: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) Of course we should be compiling against the local include/nbdkit-plugin.h

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

[Adding libguestfs mailing list] I reproduced it locally - the difference was installing "gcc-go". I only had golang-bin installed previously. With gcc-go installed: ../run go install libguestfs.org/libnbd write of Go pointer 0xc000016060 to non-Go memory 0x7f5fe8297390 fatal error: Go pointer stored into non-Go memory runtime stack: runtime_mstart

Sorry Dan, but I really do dislike golang with a passion :-) Here is a patch that allows you to write nbdkit plugins in golang. As with C, OCaml and Rust, you can write a plugin in Go which compiles directly to a .so file that can be loaded into golang, so in that sense it works completely differently from scripting language plugins like Perl and Python where there's an

Thanks: Dan Berrangé XXX UNFINISHED: - Is using uintptr for the handle a good idea? Plugins must return something != 0. In other languages we would allow plugins to return an arbitrary object here, but this is not possible in golang because of lack of GC roots. - Default can_* methods are hard to implement. Ideally we would be able to test if a user plugin implements a

For the current set of examples this doesn't matter. This also adds another example where we use the Connection to store data, just to check that actually works. Thanks: James @ purpleidea, Dan Berrangé --- plugins/golang/nbdkit-golang-plugin.pod | 10 +- plugins/golang/Makefile.am | 9 + plugins/golang/examples/disk/disk.go | 168 ++++++++++++++++++

--- run.in | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/run.in b/run.in index 8fdf454..438a68c 100755 --- a/run.in +++ b/run.in @@ -140,15 +140,15 @@ export PERL_VALGRIND=1 export PERL_DESTRUCT_LEVEL=2 # For Python. -export PYTHON=@PYTHON@ +export PYTHON="@PYTHON@" prepend PYTHONPATH "$b/python/.libs" prepend PYTHONPATH

I took the easy route of crippling what I couldn't get working, on the grounds that partial coverage is better than none now that we have Cirrus CI checking commits on additional platforms. This series got me to a green checkmark: https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983 but depends on an as-yet uncommitted patch in libvirt-ci:

Another test, the same as before.

Best of .. 4?

After enabling procmail debugging ...

This is a repost so I can test my procmail script / automatic testing framework. The patch series is identical to v1. Rich.

Patch 1 cleans up the gobject tests. Patches 2 and 3 remote gtk-doc, which is slow and useless, and replace it with a simple manual page. https://bugzilla.redhat.com/show_bug.cgi?id=1465665 Rich.

On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > Thanks: Dan Berrangé > > > > XXX UNFINISHED: > > > > - Is using uintptr for the handle a good idea? Plugins must return > > something != 0. In other languages we would allow plugins to > > return an

On Sat, Oct 17, 2020 at 09:00:30AM +0100, Richard W.M. Jones wrote: >On Sat, Oct 17, 2020 at 08:48:40AM +0100, Richard W.M. Jones wrote: >> [Adding libguestfs mailing list] >> >> I reproduced it locally - the difference was installing "gcc-go". >> I only had golang-bin installed previously. With gcc-go installed: >> >> ../run go install

On Thu, Apr 23, 2020 at 05:58:25PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 23, 2020 at 05:55:14PM +0100, Richard W.M. Jones wrote: > > When compiling when an older nbdkit is installed, the build would fail > > because certain symbols such as .get_ready were not defined: > > > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type

These bindings get as far as running very simple connections. However there are many missing parts still: * No callbacks. * No functions which handle buffers (pread/pwrite!) This is posted just for general early interest, not even for review. Rich.