[Bro-Dev] Config Framework Feedback

Hosom, Stephen M hosom at battelle.org
Tue Oct 30 12:58:27 PDT 2018


I agree that more complex code on my side would definitely make this a non-issue.

In my case, I was setting up something in bro_init that would be used repeatedly throughout execution, and you're right--my code never handled option updates.


In this case, I opted to just use old redefable consts, as they will perform exactly as expected for any downstream users (changes require a bro restart).


Honestly, I only brought this up at all because I can definitely see a person new to scripting wondering why their options do not have the expected values at bro_init time and troubleshooting for hours.


Maybe it would be worthwhile to just add a note in the documentation for the config framework about it and leave it at that?

________________________________
From: Azoff, Justin S <jazoff at illinois.edu>
Sent: Tuesday, October 30, 2018 3:41:00 PM
To: Hosom, Stephen M
Cc: bro-dev at bro.org
Subject: Re: [Bro-Dev] Config Framework Feedback

Message received from outside the Battelle network. Carefully examine it before you open any links or attachments.


> On Oct 30, 2018, at 2:09 PM, Hosom, Stephen M <hosom at battelle.org> wrote:
>
> I bumped into a limitation that was a little frustrating to work around with the config framework.
>
>
> It is inconvenient that values stored in files read by adding to Config::config_files are not available within the bro_init event. After reviewing how the Config framework works, I understand why this is the case, but it means that if you want to use configuration values on startup, you're not guaranteed to be working with the anticipated value.
>
>
> I think the introduction of an event that ensures that configuration files have been read by the time that the event fires might be worthwhile. I was wondering if anyone had any thoughts on how to resolve/work-around this issue.

This is an issue, but probably not the one you are thinking of.  even if configuration files were fully read by the time bro_init was ran, you'd still need to handle the value changing at runtime.

If you need to run code when an option changes, you can use the Option::set_change_handler to make bro raise an event.  Using this instead of bro_init would fix the startup problem, and handle it changing at any time.

There's a test that uses this in testing/btest/core/option-priorities.bro and a few other files.


—
Justin Azoff





More information about the bro-dev mailing list