[Bro-Dev] Dynamic plugin model (Re: [Bro-Commits] [git/bro] topic/robin/dynamic-plugins-2.3: Start of a plugin writing how-to. (87a1618))
robin at icir.org
Thu Dec 19 10:21:32 PST 2013
On Thu, Dec 19, 2013 at 10:23 -0500, you wrote:
> * Would a section on testing be appropriate? Both btest and unit
> testing might be useful for plugins.
Ack, that's a good point, the init-plugin script could put a basic
setup in place for that, maybe even with a first test making sure
> * A short section explaining how / when to modify CMakeLists.txt might
> be useful.
Yeah, likewise agreed. Indeed tthe documentation needs quite a bit
more material to get people actually started without having to browse
a ton of other code first. I'll leave that for later though once we've
fleshed this all fully out.
> * Should plugins be allowed to link to additional libraries?
Yes, definitly. My thinking is that the plugin author will extend the
CMakeIndex.txt with the corresponding pieces, including compile-time
logic to figure out if it's available. However, if the binary module
aims to link against a lib that's not available at runtime where Bro
executes, then I don't think there's much more we can do than fail
loading the plugin: the dlopen will fail (iirc, Bro currently aborts
in that case, I'm not sure if it should proceed without?)
Thanks for the feedback. From chatting with Seth the other day, I took
two more suggestions away:
- I'm coming around that the BRO_PLUGIN_* macros aren't the best way
of doing things. My main motivation for using them was hiding
implementation details of the plugin API so that we can more easily
change things without breaking existing code. However, it seems they
are putting too much constraints on the plugin writer and/or, if one
needs to get around them, require a lot of digging into the
internals. So I'm mulling over creating a (simpler) C++ API to the
Plugin class that can be used directly.
- The static and dynamic plugins could be unified further. It's
unclear what the right default is for shipping plugins that provide
standard functionality, but it would be nice in any case if we could
just flip a switch to change between static and dynamic builds for
the in-tree stuff.
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin
More information about the bro-dev