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

[Daniel P. Berrangé]

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

No, I was mostly meaning the "copylib" approach to plugins, where the
plugin author owns the whole stack.

I was just thinking of what the "ideal" would be from a Go programmers
POV, and that I think involves the least possible exposure to CGo and
the native nbdkit APIs.

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

I think the hairy CGo/libnbdkit interaction problems still exist in what
I'm describing. Mostly I'm just thinking about how they can be isolated
so that they owned by nbdkit maintainers in one place, and not copied
around, nor even seen by plugin authors.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|