[Bro-Dev] script loading changes
jsiwek at ncsa.illinois.edu
Wed Jul 13 08:19:06 PDT 2011
> > 1) When an @load or command line argument relies on BROPATH to
> > search for the script/package, directory separator characters
> > (i.e. '/') must be replaced with dots ('.').
> Do we want to say "may" instead of "must"? So both versions would be
So I take this to mean the search order for "@load a.b.c" would be
to look in BROPATH for "a.b.c", "a.b.c.bro", "a/b/c", then "a/b/c.bro".
And the search order for "@load a/b/c" would be "a/b/c" then "a/b/c.bro"
We could do that, but I think in the shipped scripts should use one
form consistently -- probably the dotted form or else we'd just be
adding a feature that never gets used.
And actually I think the search orders listed above should be reversed
to make the common case faster.
> > 3) A new "@add x when y ..." directive
> One thing we haven't considered yet: what if "x" itself has new @loads
> or @adds? Can we make that well-defined?
If 'x' contains @loads, they get loaded immediately during the scan of 'x'
and set some flag to indicate we should go back to iterating from the
beginning of the current pool of @adds-to-evaluate to re-check dependencies.
If 'x' contains @adds, then those are added to the end of the pool of
@adds-to-evaluate (we should be somewhere in the middle of iterating over
the pool at this point).
Another problem I was thinking of was what happens when there's
@add x when y
@add y when z
And there's only an "@load z", creating a dependency chain. To resolve
those cases, we can take the same approach I describe above and reset
the iterator to the beginning of the @adds-to-evaluate pool in order to
re-check dependencies whenever one of the elements evaluates successfully.
Dependency cycles will just get dropped on the floor if no element on the
cycle is ever explicitly @load'd.
More information about the bro-dev