[collectd] RFC: Should we maintain plugins written in Go?
octo at collectd.org
Tue Apr 28 23:46:10 CEST 2020
On 2020-04-28 01:49, Ranganath, Sunku wrote:
> Being a new user to Go, have you considered 'Plugin' package of Go 
> for shared object creation?
I think the "plugin" package would be useful if we implemented a
"golang" plugin that functions similarly to the "Perl", "Python", and
"Java" plugins. I.e. if we had some glue Go code in collectd and wanted
to dynamically load Go-based plugins from it.
What the "collectd.org/plugin" package allows you to do is write a
plugin in Go, compile it into a shared object and then load and execute
that shared object from collectd without any "glue" code in collectd
itself. To implement this, the Go code need to access symbols exported
by the daemon. The code currently uses dlopen() and dlsym() for this
purpose, but this could potentially be replaced by some clever linker
> Our team were contemplating to create either an out-of-tree location
> or propose a new folder ourselves. So this is perfect timing for us to
> have this created.
Glad to hear it :)
> If I understand Go correctly, new plugin authors could reuse/import
> any of the available Go packages from various sources and leverage
> go-collectd framework to make them into .SOs for Collectd daemon?
Yes. It's conceivable that some packages using "Cgo" themselves could
cause some trouble, but for the most part users should be able to use
available Go packages.
> Also would it be easier to unify go plugins & go-collectd framework to
> something like: github.com/collectd/go-collectd/plugins?
> It would be a bit confusing with
> github.com/collectd/go-collectd/plugin, but then atleast they both
> would be under same sub-tree.
> May be we can rename github.com/collectd/go-collectd/plugin to
> something unambigous? :)
Having the API and its users in the same repository has advantages,
especially around refactoring. I'm a bit hesitant to add plugins to the
collectd/go-collectd repository though. Moving the "collectd.org/plugin"
package out of that repository might be an option. It would also mean
that the collectd/go-collectd repository would become a pure Go
repository again, making building and testing of all sub-packages
collectd – The system statistics collection daemon
More information about the collectd