首先，先看看想测试那个系统调用，在应用层，如果使用C语言编程一般我们一来就是open函数，实际在测试的时候，直接用touch xxx.txt然后 echo "xxx" >> xxx.txt，这样就完成了文件创建和写文件的操作，那肯定会用到open的系统调用，但是有一个问题：从【linux】6.9.0系统调用接口列表，一共644个-CSDN博客这篇文章来看，里边有好几个长得像open的，不知道调用的是哪个？只是看名称也不太容易看得出来，我们去内核源代码里边去搜索：

有好些，也不知道调用的是哪个，碰到这样的情况，直接去内核源代码里找到代码（因为是文件系统，所以直接进入fs目录），使用的命令行是grep -Hrn "SYSCALL" *.c | grep "(open"：

然后添加打印日志，这里我们在fs/open.c这个文件里加了个计数的count，然后在刚才搜索出来结果的地方添加了打印，具体这个为什么要添加判断count>20才打印，不太记得了，在内核初始化的时候，要把内核压缩包的虚拟文件系统解压出来，实际上会调用到fopen的系统调用，好像是这样，不太记得了：

从前面的搜索得知，open.c 这个文件里实际上有好几个跟fopen长得像的，我们当前只用一个 count，注意是搜索出来的每个里边都去添加下打印日志，添加完成后，编译（编译如果报错，一般是新增代码出现的语法错误），重启电脑，再看看日志：

日志类似这样的，这样可以看出来（实际上调用的是openat这个系统调用，行数有点对不上，因为代码经过多次测试，失败了N多次）：

从打印的日志来看，其实已经出现不断调用openat系统调用的死循环了，具体原因还不太清楚（这里需要注意，在本机测试的时候发现：

1）只是执行pr_info("")；这个代码对内核影响是最小的；

2）如果想执行pr_info("count: %d", count)； 这个也能执行，有时候能成功，有时候不一定，说人话就是内核不一定能起来；

3）再如果想执行pr_info("count: %d, filename: %s", count, filename)； 本意是想把被操作的文件名显示出来，测试结果是内核根本起不来，就是这么刺激）；

从这个栈看不太出来，这块不太懂，猜测内核前面已经出问题了，最后随便打印点日志意思意思。

另外，如果操作系统未能正常启动，内核打印的日志不一定能看到，显示画面滚动太快。

这应该也是调用栈，不太看得出来跟我们合入代码有啥关系，估计是间接影响的吧。

 上图这个也不太会看，跟上边那个有点像。

这个调用栈就明显跟我们代码合入有关了。红色方框上边部分一看就是内核打印日志那个宏的栈。。这里注意下这个日志是在 busybox 时调用dmesg 打印的日志，这里对grep命令如果学会使用grep -A, -B，会比较容易看到详细的日志，grep过滤的时候不会找关键字就直接基于前面的时间戳过滤，这样容易找到自已想要的信息，不过要需要耐心。

 这个日志从第一行看到是我们合入代码出了问题，这也是为什么在我们合入代码的时候，自已感觉没有问题，实际就会有问题。不过调用栈后边的代码，还不太懂。

这就是基于时间戳过滤，从内核启动时间来看大概是5秒多一点。 

这也是。

这个图不太懂，猜测是内核文件系统初始化内核运行依赖的一些系统库。

搞文件系统的摸索，经常把虚拟机搞死机，当然外边的电脑也蓝屏了好几次，这样多有意思，doge。

在文件系统系统调用API添加打印日志会导致UBUNTU不能正常启动，坏消息就是系统不能正常启动，好消息就是知道系统一定会走到我们打印日志的地方，doge... 

系统起不来，有时候会进到busybox的界面，注意这里边可以使用的命令比较有限。

不能正常起动的问题可以通过开机进入高级选项，选项里边选择较前面编译的可以启动的版本（比如：6.9.0+）就可以了，实在不放心直接使用6.8.0（内核未升级之间的版本就好了）。 

然后进入代码目录，把修改的可能导致系统不能起来的代码回退掉，然后重新编译代码，这样问题基本可以解决。

博客内容估计还有很多不对的地方，请包涵。