similar to: [PATCH nbdkit v2] Add the ability to write plugins in golang.

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 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 arbitrary object here, but this is not possible in golang > because of lack of GC roots. Yeah, this is

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

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 ++++++++++++++++++

On Fri, Apr 10, 2020 at 02:51:52PM +0100, Richard W.M. Jones wrote: > Similar to C, OCaml and Rust, this is not a plugin per se. Instead > it's more of a method and set of tests around writing plugins in > golang. They are standalone programs that compile into shared objects > that nbdkit can then load (so there is no "go plugin" between nbdkit > and the user plugin,

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) >

On Thu, Apr 23, 2020 at 10:03:45AM +0100, Richard W.M. Jones wrote: > 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

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

Version 1 was here: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00160 Version 2 side-steps the objections to the first patch by using a well-formed alternate nbdkit.pc file and running ordinary pkg-config against it, so any parsing of --cflags etc will be done by pkg-config. The first patch is essentially the same idea as:

Similar to C, OCaml and Rust, this is not a plugin per se. Instead it's more of a method and set of tests around writing plugins in golang. They are standalone programs that compile into shared objects that nbdkit can then load (so there is no "go plugin" between nbdkit and the user plugin, unlike in scripting languages like Perl). --- plugins/golang/nbdkit-golang-plugin.pod

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

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

[To continue the conversation from https://github.com/libguestfs/nbdkit/issues/5] > Currently there's no way for the Rust plugin to report an error. The > idiomatic way to do it would be for each callback to return a Result > object, much like how the Go plugin currently does it. I'm sure it's not idiomatic for Rust, but I just wanted to say that there is a way to return an

Commit 6725fa0e12 changed copy_uint32_array() to utilize a Go hack for accessing a C array as a Go slice in order to potentially benefit from any optimizations in Go's copy() for bulk transfer of memory over naive one-at-a-time iteration. But that commit also acknowledged that no benchmark timings were performed, which would have been useful to demonstrat an actual benefit for using hack in

On Tue, Aug 08, 2023 at 02:36:12PM +0300, Nir Soffer wrote: > On Thu, Aug 3, 2023 at 4:57?AM Eric Blake <eblake at redhat.com> wrote: > > func copy_uint32_array(entries *C.uint32_t, count C.size_t) []uint32 { > > + if (uint64(count) > 64*1024*1024) { > > + panic(\"violation of state machine guarantee\") > > This is unwanted in a library, it

On Thu, Aug 3, 2023 at 4:57?AM Eric Blake <eblake at redhat.com> wrote: > > Commit 6725fa0e12 changed copy_uint32_array() to utilize a Go hack for > accessing a C array as a Go slice in order to potentially benefit from > any optimizations in Go's copy() for bulk transfer of memory over > naive one-at-a-time iteration. But that commit also acknowledged that > no

[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

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 Wed, Apr 15, 2020 at 06:04:26PM +0100, Richard W.M. Jones wrote: > On Wed, Apr 15, 2020 at 05:27:07PM +0100, Daniel P. Berrangé wrote: > > On Fri, Apr 10, 2020 at 02:51:52PM +0100, Richard W.M. Jones wrote: > > > Similar to C, OCaml and Rust, this is not a plugin per se. Instead > > > it's more of a method and set of tests around writing plugins in > > >