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.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW