"Linux Kernel Reproduction" Made More Understandable - Update 1 at linux.tokyo

Summary

• Made the code reproduction easier to understand and more intuitive.
• Added fork() (kernel_clone) and exec() in addition to the write system call (complete coverage will take about a year).
• Other minor UI and other fixes.

Introduction

In the previous article, I introduced a mechanism to visualize the Linux kernel's write system call at the function level, making it intuitive to understand "how to read kernel code."

https://zenn.dev/coffeecupjp/articles/07f01040a4c7a4

https://linux.tokyo

Since then, I have extended the functionality to support fork() and exec(), added tree navigation, JSON export, and integration with Linux Reader.
This article introduces the updates and the actual evolution points.

Dissatisfaction with the Previous Version

The "Linux Kernel Visualization Site" introduced in the previous article allowed users to understand function tracing through a tree structure, but I found several dissatisfaction points myself (perhaps I rushed it too much like an express train...).

1. Important function candidates were visible, but the path to reach them was hard to follow.
2. After clicking an important function candidate, you had to manually navigate to the target function.
3. When the tree became too large, it became difficult to view.
4. There was no integration with Linux-Reader, which I had created.
5. The content was limited (although covering all 323 system calls of Linux 6.17 arm64 plus extras would take even me, an unemployed person, well over a year).

So, I made some fixes, and this article is about those changes.
If you don't feel like reading, feel free to skip the details and just try out the site first.

https://linux.tokyo

Fixes

So, I'll explain each fix one by one (sorry if they're not in a specific order).

◾️ Ability to Reproduce the Path from the Selected Function Upward

In the previous article, I mentioned "reproduction," but to reproduce a function's path from the root node's function, you had to click each one individually.
That is, for example, when you wanted to know the relationship from the root function nvme_irq to send_call_function_single_ipi of write(4) (see image below):

You had to click through each function one by one: __smp_call_single_queue → generic_exec_single → smp_call_function_single_async → blk_mq_complete_send_ipi → ...

But that was quite tedious.
So I added a feature (replay function) that allows tracking the path from the root function to the selected function.

Usage is simple. Under the selected function, a blue button "Reproduce from root node" appears; just click it.
This lets you step through each function from the root function one by one (by pressing "Next code") to see the contents of the target function.

// It's quite long...
"nvme_poll_cq" -> "nvme_handle_cqe" -> "nvme_try_complete_req" -> "blk_mq_complete_request_remote" -> "blk_mq_complete_send_ipi" -> "smp_call_function_single_async" -> "generic_exec_single" -> "__smp_call_single_queue" -> "send_call_function_single_ipi"

Like that.
This brings us closer to true "reproduction"! Yay.

◾️ Added Fork (kernel_clone) and Exec in addition to Write

In the previous article, I wrote "conquer all Linux kernel functions," but upon closer inspection, I realized I would need to cover nearly 400 functions (Linux 6.17 arm64 323 system calls+a), which would take even an unemployed person like me over a year. So I didn't give up; for now, I wrote the typical fork and exec.

Currently I'm working on exit, but the size of exit_fs is huge and I'm struggling. At this rate, it might take two years... However, some system calls are minor, so I plan to take my time starting with the major ones (open, read, mmap, slab, sched, start_kernel, etc.).

◾️ Ability to Save the Tree JSON and Re-explore with Linux-Reader

Actually, this site https://linux.tokyo is built by displaying JSON files generated with my custom VSCode extension Linux-Reader. For those who think "the content is not enough!" I made it possible to re-explore with Linux-Reader.

To re-explore, follow these steps. I've implemented the feature, so if you're interested, give it a try.

1. Prepare the above VSCode extension, the Linux kernel, and compile_commands.json (generated with the bear command + Linux build).

https://marketplace.visualstudio.com/items?itemName=coffeecupjapan.linux-reader&ssr=false

2. Go to the page you want to re-explore on https://linux.tokyo, and click "Download tree as JSON" to the right of "Purpose of exploring this function."

3. Open the VSCode extension from the command palette and configure it in the settings screen. Settings are not automatically saved, so you need to click the save button for each one.

4. After configuration, return to the chat screen, click "Move to search history input," enter the path of the JSON file saved in step 2, and the tree structure will be displayed. By entering the auto-assigned identification hash value for each function, you can re-explore!

I explained it, but since it requires effort (e.g., generating compile_commands.json with a Linux build), I would only suggest doing it if you really want to try it yourself.

◾️ Auto-scrolling to the Target Function When Clicking Important Function Candidates

The fixes from here are light.
Currently, https://linux.tokyo has a feature that selects important function paths ("main function paths") within the tree, but it did not automatically scroll to the selected function, so I made it scroll.

◾️ Ability to Collapse the Entire Tree

While using it, I realized that expanding too much makes the tree too large and hard to understand.
So, I added a feature to display the tree only up to the initial state of "depth 2."

Conclusion

This week's improvements were quite impactful, but I plan to continue improving if usability issues arise.
Next time, I aim to complete exit() and also tackle representative system calls like open/read/mmap.
I hope more people can intuitively feel the "structural beauty" of the code.