[Bro-Dev] Proposed IOSource reorg

Scott Campbell scampbell at lbl.gov
Tue Dec 3 11:08:03 PST 2013

Hash: SHA1

Would the input framework code be morphed into iosource/sources or
continue living in it's own directory?

Re breaking out communication and serialization into it's own place,
it seems like it has a distinct function outside of i/o - it is used
by i/o, but it can work outside of the core functionality.  Making
this a one step at a time reorg as Jon suggests might be a less
complex and destructive way to go about that...


On 12/3/13 12:07 PM, Robin Sommer wrote:
> I'm thinking to move the IOSource infrastructure into its own 
> subdirectory/namespace and turn the IOSourceRegistry into 
> iosource::Manager in alignment with the layout we've started to
> move to with the logging/input/etc. I'd then move the classes
> derived from IOSource into corresponding subdirectories, like
> this:
> src/iosource/ src/iosource/Manager.{h,cc} 
> src/iosource/IOSource.{h,cc} 
> src/iosource/sources/pkt-src/PktSrc.{h,cc} 
> src/iosource/sources/pkt-src/bpf/* src/iosource/sources/flow-src/* 
> src/iosource/sources/dns-mgr/* 
> src/iosource/sources/remote-serializer/*
> The sources would turn into plugin components. New types of packet 
> sources (like netmap) would then go into iosource/pkt-src/foo/.
> Does that make sense?
> One piece where I'm unsure: would it be better to keep the remote 
> serializer out if this and instead do a separate serializer/
> hierarchy where all the current serialization/communication code
> goes?
> Robin

Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the bro-dev mailing list