Implementation plan for instrumentation and logging

The current plan is to take the "back ends" of log4cxx (the appenders), provide a "simple" SystemC implementation of the log4cxx front end, and re-use the GreenSocsConfigurationAtRuntime mechanism (instead of log4cxx's mechanism).

This means that we have to standardise the interface, and what it "gives" you.

Straw man interface spec ideas:

1. specify an gs_module that initialises both logger and configuration information in all \"sc_moduels\" with the INSTANCE name - people can do this in their own sc_modules, or use gs_module. Maybe the interface can simply be gs_servicesInit(this); - (this being the sc_module instance?) 2. sc_log(id, X). X can either be a string, OR an sc_object with a toString function in it. Logging information will then be \"tagged\" with the module instance name and can then be selected that way.

Note: we need \"id\" to be able to identify the logger to be able to enable/disable it...

3. Important: The user might need access to the \"on/off\" state of logging, in order to either include, or not, some internal (and sophisticated?) data collection algorithms. These might be expensive, so it's better to only have them if the logging is enabled. So, we also need something like \"sc_log_enabled(id)\" - so you can write if (sc_log_enabled(id)) { ... generate my complex data collection ...}

Plan

1. Evaluate work required to extract log4cxx backends and re-use
2. Evaluate work required to add GreenSocsConfigurationAtRuntime as the config mechanism into log4cxx.
3. Implement gs_module / servicesInit structure
4. Implement sc_log(X) to take object (and print to screen).

Based on the evaluation above, more or less of the following will be possible in the current project scope:

1. extract log4cxx backends
2. Add GreenSocsConfigurationAtRuntime
3. Adapt log4cxx data structures to handle sc_objects as well as strings.
4. Wrap Appenders to convert to strings where needed.
5. Write an SCV "appender".
6. add connection from sc_log to extended log4cxx data structures.