Re: [Libguestfs] [PATCH nbdkit UNFINISHED] Add the ability to write plugins in golang.

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 > > 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). > > Why did you choose this approach ? Do you mean the design of constructing the .so file directly using --buildmode=c-shared? I wasn't aware there was any other way to do it. Should we use some kind of module loading instead?

> Looking at the code below there's the general boilerplate that > will be approx the same for all plugins with cut+paste tedium > across projects, and then there's the "interesting" code in > test.go > > The methods in test.go though look quite unappealing from a > Go programmer's POV, as the API contracts are full of CGo > types and unsafe pointers. > > To make something that is attractive for Go programmers, I > think it needs to hide all the low level CGo stuff entirely. > > Implementing a nbdkit plugin should require nothing more > that providing pure Go code that satisfies a well defined > Go "interface" type definition. There should not be any > copy+paste of example boilerplate, nor any use of CGo. I don't disagree, I just have no idea how to achieve this. > As an illustration, consider an interface and basic infrastructure: [...] I'll have a go at changing it like this, but I don't see how this changes any of the fundamental problems, but maybe I will understand more once I've done that.