[Bro-Dev] #633: Globals cleanup

[Bro Tracker]

#633: Globals cleanup
----------------------+------------------------
  Reporter:  robin    |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:  Bro1.6
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:  beta
----------------------+------------------------

Comment (by seth):

 > - We still have a number of globals that are redefable and therefore
 > should be constants instead:
 >
 >     {{{> grep -R ^global  scripts | grep redef}}}

 It's possible that I've left those with &redef because someone may want to
 modify an expiration attribute.  I think this was what we missed when we
 were talking about getting rid of &redef.  There are cases where you want
 to &redef globals to modify attributes.  Due to how attributes are set I
 can't turn the attribute arguments into variables either because you can't
 set them at init time.  We may want to discuss this further soon and try
 to address it in an upcoming release.

 > - There are some globals that look like they should be {{{const ...
 > &redef}}} instead. Example:
 >    {{{ global local_nets_table: table[subnet] of subnet = {}; }}} in
 > {{{./base/utils/site.bro}}}

 That's actually deliberate.  local_nets_table is generated at runtime
 (well, init time and possible runtime if I ever integrate it with the
 control framework which I've been meaning to do).

 > - Not everything that should be {{{&synchronized}}} yet is already,
 > Roughly speaking, once the two tasks above are done, all remaining
 > ``globals`` that store state not limited to a specific host pair, should
 > be {{{&synchronized}}}. Example {{{global did_notice_orig}}} in
 > {{{./base/frameworks/notice/weird.bro}}}.

 Hm, that probably just needs to be refactored.  Notice suppression is
 built into the notice framework at a low level now and it is already
 integrated with the cluster framework so &synchronized won't be needed in
 that case.

 > Exception: there are some global
 > tables that are static after initialization (like ``filters`` in
 > {{{./base/frameworks/logging/main.bro}}}; these are fine (ideally, we
 > would have a way to mark this usage pattern and catch it if somebody
 > changes stuff later)).

 Ah, yes.  This is the same as the local_nets_table issue.  All of these
 need to work transparently with the control framework (modified remotely
 or locally at runtime but remain mostly static) as well which needs to be
 wired together manually now but there be a better abstraction we could
 come up with.

-- 
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/633#comment:3>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker