multi file C program, how best to implement optional logging?

Question

I have a multi file C program. I\'d like the user to be able to specify different debugging levels at run time.

What is the best way to implement this?

I was thi

Answer 1

In Windows (and broadly across Microsoft), we use Event Tracing for Windows (ETW) extensively. ETW is an efficient static logging mechanism. The NT kernel and many components are very well instrumented. ETW has a lot of advantages:

• Any ETW event provider can be dynamically enabled/disabled at run time - no rebooting or process restarts required. Most ETW providers provide granular control over individual events, or groups of events.
• Formatting of event data is not done a run time (which can be very expensive). Its done when the event trace is post processed.
• ETW is the underlying mechanism for The Windows Event Log. If you build your instrumentation correctly you get application level logging for free.
• Your component can support very granular enabling of events, either individually, by levels, or in groups (or in any combination). You can also put multiple providers in our code.
• Events from any provider (most importantly the kernel) can be merged into a single trace so all events can be correlated.
• A merged trace can be copied off the box and fully processed - with symbols.
• The NT kernel sample profile interrupt can generate an ETW event - this yields a very light weight sample profile that can be used any time
• On Vista and Windows Server 2008, logging an event is lock free and fully multi-core aware - a thread on each processor can independently log events with no synchronization needed between them.
• ETW is efficient when logging is off as well - its just a simple Boolean check (ETW dos this, or you can do it explicitly). Note, this does not require a kernel mode transition. Its all done in process.

This is hugely valuable for us, and can be for your Windows code as well - ETW is usable by any component - including user mode, drivers and other kernel components.

Many people like to watch their logging output as their program or component runs. This is easy to do with ETW. We often do is write a streaming ETW consumer. Instead of putting printfs in the code, I just put ETW events at interesting places. When my component is running, I can then just run my ETW watcher at any time - the watcher receives the events and displays them, counts them, or does other interesting things with them.

Most code can benefit from well implemented logging. Well implemented static run-time logging can make finding many problems straight forward - without it, you have zero visibility into what is happening in your component. You can look at inputs, outputs and guess -that's about it.

They key here is the term 'well implemented'. Instrumentation must be in the right place. Like any thing else, this requires some thought and planning. If it is not in helpful/interesting places, then it will not help you find problems in a a development, testing, or deployed scenario. You can also have too much instrumentation causing perf problems when it is on - or even off!

There are several tools in windows to help you with ETW based loggers and events. These include logman.exe and tracerpt.exe. There are also the xperf tools which are focused on performance, but can also control any ETW provider and dump log files.