看起来你在trace-cmd的参数使用上搞混了**事件（event）和函数过滤（function filter）**的区别，这是ftrace/trace-cmd体系里很容易踩的坑。下面给你一步步的正确解决方案：

一、正确的trace-cmd录制命令 #

核心是区分大写-F（函数过滤）和小写-f（事件过滤）：前者对应sysfs里的set_ftrace_filter（用来筛选要追踪的内核函数），后者是给特定trace事件加过滤条件。

正确的录制命令如下：

trace-cmd record -p function_graph -F '*:mod:my_mod' -- cat /dev/my_mod

逐个参数解释：

• -p function_graph：指定使用function_graph追踪器，和你之前在sysfs里设置echo function_graph > current_tracer的效果一致
• -F '*:mod:my_mod'：关键！大写-F表示设置函数过滤规则，匹配my_mod模块下的所有函数，完全对应你之前用的echo '*:mod:my_mod' > set_ftrace_filter
• --：用来分隔trace-cmd的参数和后面要执行的测试命令（cat /dev/my_mod），避免命令参数被trace-cmd错误解析
• cat /dev/my_mod：触发你的内核模块逻辑的测试命令，替换成你实际的触发方式即可

执行完成后，当前目录会生成标准的trace.dat文件，这个格式完美兼容KernelShark和trace-cmd report。

二、后续分析方法 #

1. 用trace-cmd report快速查看/过滤 #

直接在命令行查看追踪结果，还可以过滤只看你的模块内容：

# 查看全部内容
trace-cmd report

# 只过滤my_mod模块的函数调用
trace-cmd report -f 'mod == "my_mod"'

2. 用KernelShark可视化分析 #

启动KernelShark加载trace.dat，就能用图形化界面做各种操作：

kernelshark trace.dat

在KernelShark里你可以：

• 用顶部的过滤框输入mod == "my_mod"，只显示模块相关的调用
• 缩放时间轴，查看函数调用的时序和耗时
• 右键函数调用查看详细栈信息
• 用统计功能聚合函数调用次数、平均耗时等数据

三、你之前的错误原因解析 #

把你踩过的坑拆解清楚，避免再犯：

1. 用小写-f做函数过滤：小写-f是给**事件（比如sched、irq）**加过滤的，不是给function_graph追踪器的函数过滤用的，所以会提示过滤语法错误
2. 用-e '*:mod:my_mod'：-e是指定要追踪的trace事件（比如sched_switch），而*:mod:my_mod是函数过滤规则，不是事件名，所以会提示找不到事件
3. 参数顺序错误：trace-cmd的参数有严格顺序，追踪器（-p）、函数过滤（-F）要放在测试命令之前，且要用--分隔

四、进阶技巧 #

• 追踪特定函数：如果不需要追踪模块所有函数，把*:mod:my_mod换成具体函数名，比如my_mod_read:mod:my_mod
• 指定输出文件名：用-o参数自定义输出文件，避免覆盖默认的trace.dat：

  trace-cmd record -p function_graph -F '*:mod:my_mod' -o my_mod_trace.dat -- cat /dev/my_mod
  

• 验证模块加载状态：如果录制后看不到模块函数，先确认模块已加载：lsmod | grep my_mod，同时确保内核开启了CONFIG_FUNCTION_GRAPH_TRACER、CONFIG_TRACING等必要配置（主流发行版内核默认都开启了）

这样应该就能完美解决你的问题，生成的trace.dat可以用专业工具轻松做过滤、可视化和统计分析了！