docs

docs/reference_guide.md

@@ -43,7 +43,7 @@ This is a work in progress. If something is missing, check the bpftrace source t
     - [4. `count()`: Frequency Counting](#4-count-frequency-counting)
     - [5. `hist()`, `lhist()`: Histograms](#5-hist-lhist-histograms)
     - [6. `nsecs`: Timestamps and Time Deltas](#6-nsecs-timestamps-and-time-deltas)
-    - [7. `stack`: Stack Traces, Kernel](#7-stack-stack-traces-kernel)
+    - [7. `kstack`: Stack Traces, Kernel](#7-kstack-stack-traces-kernel)
     - [8. `ustack`: Stack Traces, User](#8-ustack-stack-traces-user)
     - [9. `$1`, ..., `$N`: Positional Parameters](#9-1--n-positional-parameters)
 - [Functions](#functions)
@@ -913,7 +913,7 @@ That would fire once for every 1000000 cache misses. This usually indicates the
 - `nsecs` - Nanosecond timestamp
 - `cpu` - Processor ID
 - `comm` - Process name
-- `stack` - Kernel stack trace
+- `kstack` - Kernel stack trace
 - `ustack` - User stack trace
 - `arg0`, `arg1`, ..., `argN`. - Arguments to the traced function
 - `retval` - Return value from traced function
@@ -1036,16 +1036,16 @@ at 1438 ms: sleep
 ^C
 ```
 
-## 7. `stack`: Stack Traces, Kernel
+## 7. `kstack`: Stack Traces, Kernel
 
-Syntax: `stack`
+Syntax: `kstack`
 
 These are implemented using BPF stack maps.
 
 Examples:
 
 ```
-# bpftrace -e 'kprobe:ip_output { @[stack] = count(); }'
+# bpftrace -e 'kprobe:ip_output { @[kstack] = count(); }'
 Attaching 1 probe...
 [...]
 @[
@@ -1253,7 +1253,7 @@ Tracing block I/O sizes > 0 bytes
 - `exit()` - Quit bpftrace
 - `cgroupid(char *path)` - Resolve cgroup ID
 
-Some of these are asynchronous: the kernel queues the event, but some time later (milliseconds) it is processed in user-space. The asynchronous actions are: <tt>printf()</tt>, <tt>time()</tt>, and <tt>join()</tt>. Both <tt>sym()</tt> and <tt>usym()</tt>, as well as the variables <tt>stack</tt> and </tt>ustack</tt>, record addresses synchronously, but then do symbol translation asynchronously.
+Some of these are asynchronous: the kernel queues the event, but some time later (milliseconds) it is processed in user-space. The asynchronous actions are: <tt>printf()</tt>, <tt>time()</tt>, and <tt>join()</tt>. Both <tt>sym()</tt> and <tt>usym()</tt>, as well as the variables <tt>kstack</tt> and </tt>ustack</tt>, record addresses synchronously, but then do symbol translation asynchronously.
 
 A selection of these are discussed in the following sections.
 
@@ -1316,7 +1316,7 @@ tbl
 
 Syntax: `str(char *s [, int length])`
 
-Returns the string pointed to by s. `length` can be used to limit the size of the read, and/or introduce a null-terminator.  
+Returns the string pointed to by s. `length` can be used to limit the size of the read, and/or introduce a null-terminator.
 By default, the string will have size 64 bytes (tuneable using [env var `BPFTRACE_STRLEN`](#7-env-bpftrace_strlen)).
 
 Examples:

docs/tutorial_one_liners.md

@@ -215,12 +215,12 @@ secondary_startup_64+165
 Profile kernel stacks at 99 Hertz, printing a frequency count.
 
 - profile:hz:99: This fires on all CPUs at 99 Hertz. Why 99 and not 100 or 1000? We want frequent enough to catch both the big and small picture of execution, but not too frequent as to perturb performance. 100 Hertz is enough. But we don't want 100 exactly, as sampling may occur in lockstep with other timed activities, hence 99.
-- stack: Returns the kernel stack trace. This is used as a key for the map, so that it can be frequency counted. The output of this is ideal to be visualized as a flame graph. There is also `ustack` for the user-level stack trace.
+- kstack: Returns the kernel stack trace. This is used as a key for the map, so that it can be frequency counted. The output of this is ideal to be visualized as a flame graph. There is also `ustack` for the user-level stack trace.
 
 # Lesson 10. Scheduler Tracing
 
 ```
-# bpftrace -e 'tracepoint:sched:sched_switch { @[stack] = count(); }'
+# bpftrace -e 'tracepoint:sched:sched_switch { @[kstack] = count(); }'
 ^C
 [...]
 
@@ -248,8 +248,8 @@ This counts stack traces that led to context switching (off-CPU) events. The abo
 
 - sched: The sched category has tracepoints for different kernel CPU scheduler events: sched_switch, sched_wakeup, sched_migrate_task, etc.
 - sched_switch: This probe fires when a thread leaves CPU. This will be a blocking event: eg, waiting on I/O, a timer, paging/swapping, or a lock.
-- stack: A kernel stack trace.
-- sched_switch fires in thread context, so that the stack refers to the thread who is leaving. As you use other probe types, pay attention to context, as comm, pid, stack, etc, may not refer to the target of the probe.
+- kstack: A kernel stack trace.
+- sched_switch fires in thread context, so that the stack refers to the thread who is leaving. As you use other probe types, pay attention to context, as comm, pid, kstack, etc, may not refer to the target of the probe.
 
 # Lesson 11. Block I/O Tracing