當一個女生讓你替她抓100只螢火蟲，她一定不是為了折磨你，而是因為她愛上了你。當你們之間經歷了無數的恩恩怨怨和彼此傷害，她再次讓你替她抓100只螢火蟲，那一定是因為她還愛著你。

為什么？因為這就是套路，是在下偶爾瞟一眼古裝肥皂劇總結出來的套路。

Linux里面最大的套路，就是“一切都是文件”。愛一個人，就為她捉螢火蟲；做一件事，就讓它成為一個“文件”。

為什么自古深情留不住，唯有“文件”得人心呢？因為文件在用戶態最直觀的形式是隨著一次open，獲得一個fd，有了這個fd，長城內外，你基本可以為所欲為：

在本進程內，fd的最直觀操作是open、close、mmap、ioctl、poll這些。mmap讓你具備把fd透射到內存的能力，所以你可以通過指針訪問文件的內容。再者，這個mmap，如果底層透射的是framebuffer、V4L2、DRM等，則讓我們具備了從用戶態操作底層顯存、多媒體數據等的能力；比如，無論是V4L2還是DRM，都支持把底層的dma_buf導出為fd。poll則提供給用戶阻塞等待某事件發生的能力。至于ioctl，就更加不用說了，你可以透過ioctl靈活地為fd添加控制命令。

在跨進程的情況下，Linux支持fd的跨進程socket傳輸，從而可以實現共享內存、dma_buf跨進程共享等。比如一個進程可以通過send_fd可以把fd發送出去：

而另外一個進程可以通過recv_fd把fd收過來：

這種fd在長城內外可以互訪，fd最終可以指向dma_buf同時可以被mmap，而dma_buf又最終可以被顯卡、顯示控制器、video decoder/encoder等設備訪問的能力，讓fd打通了設備、CPU和跨進程的障礙，從此可以橫著走。

我們在《宋寶華：世上最好的共享內存(Linux共享內存最透徹的一篇)》一文中已經詳細闡述過這個過程，這里我們就不再贅述了。本文的重點在于匿名inode。

02

inode源頭file活水

我們把文件想象成一個object，那么inode描述的是本源，和最終的object一一對應；dentry是inode的一個路徑馬甲，比如我們可以通過"ln"命令為同一個inode創建很多的硬鏈接馬甲；而file則是活水，進程對object的一次“open”，獲得一個file，導致用戶態得到一個"fd"的句柄來操作這個object。

經典的inode、dentry、file誰都不缺席的模型是這樣的：

上圖中，我們有一個inode，這個inode有2個dentry，進程A、B open的是第一個dentry；而進程C、D open的是第二個dentry。變了的是file和fd，不變的是inode，中間的dentry馬甲沒那么重要。

但是在inode、dentry、file這個經典鐵三角中，從來都是可以有一個缺席者的，那就是dentry，因為，有時候用戶態想獲得長城內外行走的便利，但是卻不想這個inode在文件系統里面留下一個路徑的痕跡。簡單來說，我希望有個fd，但是這個fd，你在從"/"往下面搜索的任何一條路徑下，你都找不到它，它根本在根文件系統以下不存在路徑，它是無名氏，它沒有馬甲，它是個傳說。

比如，近期名震江湖的劍客usefaultfd允許我們在用戶空間處理page fault，我們是通過userfaultfd這個系統調用先獲得一個fd，之后就可以對它進行各種ioctl了：

我們透過userfaultfd系統獲得了一個fd，它在/xxx/yyy/zzz這樣的文件系統下沒有路徑。這種情況下的fd，對應著的是一個沒有名字的匿名inode，你顯然沒有辦法像fd = open ("xxx", ..)那樣來得到匿名inode的fd，因為"xxx"是一個路徑，而匿名inode沒有xxx，所以你是直接透過syscall userfaultfd這樣的系統調用，來獲得anon_inode在你的進程里面對應的fd的:

人過留名，雁過留聲；殺人者，打虎武松也。但是anon inode不吃這一套，它是一個絕頂的輕功高手，它給與的，是透過fd長城內外行走的能力，但是，在文件系統里面卻從未來過。這是用戶真實的需求，如果這種需求一定要透過一個dentry的open才能實現，這未免有點畫蛇添足了。

03

匿名inode的內核實例

我們接下來可以隨便打開個anon inode的實例來看看它是怎么工作的了。首先userfaultd是一個系統調用：

這個代碼里面比較核心的是就是，它通過：

anon_inode_getfd_secure()

生成一個匿名inode，并獲得一個句柄fd。重點別忘記了，這種“文件”也是可以有file_operations的，比如上面anon_inode_getfd_secure()參數中的userfaultfd_fops：

這樣，我們就可以在file_operations的ioctl，poll，read等callback里面實現自己特別的“文件”邏輯，這是我們自由發揮的舞臺。

說起anon_inode_getfd_secure()，它再往底層走一級是__anon_inode_getfd()：

進而再走一級是__anon_inode_getfile()：

所以本質上，是先造一個anon_inode，然后再在這個anon_inode上面造一個pseudo的file，最后通過fd_install(fd, file)，把fd和file纏在一起。再次強調，用戶有了這個fd就可以為所欲為；而內核本身，則是通過file_operations的不同實現來為所欲為的。

anon_inode之上添加一個系統調用，造一種特殊的fd，讓用戶去poll，去ioctl，把想象空間拉大了。這種實現方法，如此拉風靈活，以至于它本身也成為了一種套路。比如內核里面fs目錄下的：

eventfd，eventpoll，fscontext，io_uring，fanotify，inotify，signalfd，timerfd.......

正所謂， 待到秋來九月八，我花開后百花殺。沖天香陣透長安，滿城盡帶黃金甲。文件，哪怕最終是匿名的，都以沖天的香陣，彌漫整個Linux的世界。

04

用戶使用匿名inode

到了要說再見的時刻了，用戶可見的就是fd，通過fd來使用匿名inode。下面我們來制造一個page fault的例子，讓用戶態來處理它，這個例子直接簡化自userfaultfd的man page。我們在主線程中，通過mmap申請一頁內存，然后通過userfaultfd的ioctl告訴內核這頁的開始地址和長度，以及通過UFFDIO_REGISTER告訴內核這頁的page fault想用戶空間處理：

然后我們在pthread_create()創建的fault_handler_thread線程中，poll userfaultfd等待事件，之后把一頁全是0x66的內容拷貝到page fault發生的那一頁：

我們運行這個程序得到的輸出如下：

我們主線程在執行addr[0]=0x5A5A5A5A的時候，觸發了page fault。在fault線程里面，page fault發生后，poll阻塞返回，之后用戶通過read()讀到了一個uffd_msg的結構體，里面的成員包含了page fault的地址。之后，我們通過UFFDIO_COPY這個ioctl，把內容為0x66的頁面拷貝給page fault的頁面。

所以，最終主線程在執行printf打印的時候，addr[0]里面讀到了5A5A5A5A，剩下的addr[1]里面讀到了66666666。看到page fault由用戶態靈活這么靈活自如地處理，我的小伙伴們都嚇尿了。

可以看出來：

poll()在等什么，完全被定制化了；

read()能讀什么，完全被定制化了；

ioctl()能控制什么，完全被定制化了。

我們通過“文件”這個不變的“靜”，制造了poll、read、ioctl的靈動自如。兵法有云，以不變應萬變，以萬變應不變。

原文標題：宋寶華：論一切都是文件之匿名inode

文章出處：【微信公眾號：Linuxer】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq