[Bro-Dev] changing Notice::policy mechanism
Seth Hall
seth at icir.org
Fri Nov 2 12:09:17 PDT 2012
On Nov 2, 2012, at 12:38 PM, Robin Sommer <robin at icir.org> wrote:
> Can't say I like the multi-body functions;
Continuing the discussion from the group call, I think that we're starting to converge on adding a "policy" keyword to the language to represent something between a function and an event. Jon and I chatted about it some more and we couldn't come to a more abstracted and still clear keyword than "policy". (I really like the policy keyword here)
As a concrete example of the existing policy mechanism in the notice framework and the reworked mechanism I'll give an equivalent implementation of both.
# New style under discussion.
policy Notice::trigger(n: Notice::Info) &priority=5
{
if (n$note == Whatever && Site::is_local_host(n$conn$id$orig_h)
add n$actions[ACTION_BLAH];
}
# Existing style
redef Notice::policy += {
[$pred(n: Notice::Info) = {
return (n$note == Whatever && Site::is_local_host(n$conn$id$orig_h);
},
$priority = 5,
$action = ACTION_BLAH]
};
To address your various points about how this needs to work:
1. Immediate policy handler execution. Not even by jumping to the beginning of the
event queue and waiting for the queue to be flushed, just direct execution.
2. Adding a "break"-like keyword to halt policy execution (only valid in policy handlers).
3. No return value(s) when calling policy handlers. We'll reuse the mutability mechanism
that I subversively began using all over the place by modifying records in place.
Calling policy handlers would look like this:
policy Notice::trigger(n);
4. Policy handlers sorted by priority. Equivalent priority has undefined execution order,
but I don't see that as a problem since it's already a concern for event handlers.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/
More information about the bro-dev
mailing list