tracing: Clean up snapshot config logic and field name

The latency tracers (scheduler, irqsoff, etc) were created when tracing was first added. These tracers required a "snapshot" buffer that was the same size as the ring buffer being written to. When a new max latency was hit, the main ring buffer would swap with the snapshot buffer so that the trace leading up to the latency would be saved in the snapshot buffer (The snapshot buffer is never written to directly and the data within it can be viewed without fear of being overwritten).

Later, a new feature was added to allow snapshots to be taken by user space or even event triggers. This created a "snapshot" file that allowed users to trigger a snapshot from user space to save the current trace.

The config for this new feature (CONFIG_TRACER_SNAPSHOT) would select the latency tracer config (CONFIG_TRACER_MAX_LATENCY) as it would need all the functionality from it as it already existed. But this was incorrect. As the snapshot feature is really what the latency tracers need and not the other way around.

Have CONFIG_TRACER_MAX_TRACE select CONFIG_TRACER_SNAPSHOT where the tracers that needs the max latency buffer selects the TRACE_MAX_TRACE which will then select TRACER_SNAPSHOT.

Also, go through trace.c and trace.h and make the code that only needs the TRACER_MAX_TRACE protected by that and the code that always requires the snapshot to be protected by TRACER_SNAPSHOT.

As this snapshot buffer now has a more generic use case, calling it "max_buffer" is confusing. Rename it to "snapshot_buffer".

Head SHA1: 5c478bf3c6e04e6699d66a98bc6cabcc8ef5391c

Steven Rostedt (2):
tracing: Better separate SNAPSHOT and MAX_TRACE options
tracing: Rename trace_array field max_buffer to snapshot_buffer

----

 kernel/trace/Kconfig          |   8 +--
 kernel/trace/trace.c          | 122 +++++++++++++++++++++---------------------
 kernel/trace/trace.h          |  24 +++++----
 kernel/trace/trace_selftest.c |  10 ++--
 4 files changed, 84 insertions(+), 80 deletions(-)