[Bro-Dev] Bro package granularity

Jon Siwek jsiwek at corelight.com
Mon Jan 22 15:31:52 PST 2018


On Mon, Jan 22, 2018 at 12:38 PM, Jan Grashöfer
<jan.grashoefer at gmail.com> wrote:

> packaging some POC-seen scripts for the intel framework I was wondering
> what would be the preferred granularity of Bro packages. In case of seen
> scripts, it feels extreme to generate a package for every script.

Might depend largely on the judgement of the packager, though I think
the train of thought will end up being similar enough to provide
guidelines like the following:

If you think other packagers would depend on your scripts: it probably
is better to provide separate packages where each offers the minimal
feature set that one would expect to depend upon.

If you don't think other packagers would depend on your scripts, then
it may make sense to start with a single monolithic package, depending
on what you think would be the best thing for your users.  A deciding
factor/question here could be "does the package have a performance
impact by default".  If no, a single package for multiple different
APIs/features could work alright.  If there are performance hits just
by installing/loading the package, then it may be easiest for you to
separate out those areas that require extra cpu utilization into
distinct packages, or else you'd need to provide a user with a set of
options (&redef's) that they can use to toggle different features of
the monolithic package.

> case it would be nice if one could check either for the availability of
> certain identifiers (lookup_ID didn't work for me due to type clash in
> comparison) or a package.

Would the @if, @ifdef, @ifndef directives (e.g. for preprocessing away
whole chunks of code) work for what you were trying to do?

There's also maybe the `bro_script_loaded` event you could use to set
a global flag and then branch on that in later code paths.

- Jon



More information about the bro-dev mailing list