之所以取这个标题，是因为本文的主要脉络，就是根据Ftrace的作者Steven Rosted的Understanding the Linux Kernel via Ftrace 展开的。
相比起perf, systemtap这些跟踪手段，ftrace使用起来算是比较简单的，不需要记忆众多繁杂的参数，只需要使用"echo"和"cat"这两条基础的shell命令就可以了（也可以用命令行形式的"trace-cmd"工具）。而且，要想使用ftrace功能，只需内核的配置项中含有以下部分：
事实上，大部分内核的默认配置项中都包含了ftrace，所以把ftrace称为Linux的官方tracer也不为过。Ftrace的配置项位于路径为"/sys/kernel/debug/tracing"，文件系统类型为debugfs的目录下（如果嫌这个默认路径太长，可以用bind mount的方式挂载到其他目录，比如根目录下的"/debug"）。
Ftrace是用来追踪内核函数的执行的，而要产生追踪数据，需要同时满足3个条件：
一是得有trace事件产生。内核函数的执行是如此频繁，还会缺trace事件吗？缺倒是不缺，反倒由于事件太多，需要进行一定的筛选。筛选的标的很多，最基础的当然是用函数名，比如只想看和RCU有关的函数：
echo '*rcu*' >> set_ftrace_filter
写完读一下"set_ftrace_filter"这个文件，会发现里面列出了众多包含"rcu"的函数。那ftrace是怎么找到这些函数的呢？其实是从记录内核符号表的"/proc/kallsyms"文件获取的，并保存在ftrace自己的"available_filter_functions"中。如果试图追踪的函数名不在这个列表中（比如由于大小写不匹配），将会报错：
此外，还支持只追踪既定模块（这在驱动模块的调试中非常有用）或者只追踪特定进程产生的事件：
二是要有trace的方法。Ftrace的实现原理大致是在编译的时候，于每个函数开头插入一个hook，不开启ftrace的时候，就是"nop"，开启后则指向具体的函数，即"function"，如果希望输出结果是类似于源代码缩进的形式，则可用"function_graph"，这些都被称为"tracer"。
通过写入"current_tracer"文件，即可选择需要的trace方式。只要tracer不是"nop"，就会开始产生trace数据了。
echo funciton > current_tracer
那产生的trace数据放到哪里了呢？Ftrace是用ring buffer来存储trace数据的，如果循环缓冲区满，那么新产生的数据将会覆盖之前产生的数据。
不过从trace数据到ring buffer需要经过一个关卡，就是"tracing_on"。其值为1，关卡开放，trace数据才能进来，所以第三点是需使能ring buffer。
如果不希望旧的数据被覆盖（比如刚做完一个测试），就把关卡停掉，此时trace数据还是会继续产生（意味着对系统性能的开销还存在），但"trace"文件里的数据不会变化。
sh -c 'echo 1 > tracing_on; run_test; echo 0 > tracing_on'
数据观测完后，再往"current_tracer"里写入"nop"，以停止产生trace数据并清空缓冲区。
举个例子
知道如何使用ftrace了，接下来就通过一个例子实际地操练一下吧。比如我们现在想看下read()系统调用的路径。前面一路下来都还比较顺畅，直到"__vfs_read()"这一步：
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
--> vfs_read(f.file, buf, count, &pos);
--> __vfs_read(struct file *file, char __user *buf, size_t count,loff_t *pos)
{
if (file->f_op->read)
return file->f_op->read(file, buf, count, pos);
else if (file->f_op->read_iter)
return new_sync_read(file, buf, count, pos);
else
return -EINVAL;
}
