一、序言
在進行linux驅動開發和調試的過程中，頻繁地需要手動修改和編譯驅動源代碼，然后加載編譯出來的out-of-tree（oot）驅動。初次涉足linux驅動開發時，一位老資深同事曾告誡我，在調試驅動時最好使用insmod命令來加載自行編譯的oot驅動，這樣既便捷又安全。
為何如此建議呢？因為我發現，當使用modprobe nfp加載自行編譯的OOT驅動時，每次卻發現系統加載的驅動文件竟然位于/lib/modules/目錄下，這些文件是內核自帶的驅動文件，而非我手動編譯的驅動文件。于是，我開始探索的用法，并發現默認會在(uname -r)/目錄下搜索要加載的模塊，這讓我想到，如果能夠將/lib/modules/$(uname -r)/kernel/drivers/net/ethernet/netronome/nfp/目錄下的驅動文件每次替換為我自行編譯的OOT驅動文件，那么就能夠成功加載我編譯的驅動了。
于是，就對/lib/modules/$(uname -r)/kernel/drivers/net/ethernet/netronome/nfp/ 路徑下的in-tree驅動文件備份，并用我手動編譯出來的驅動文件替換該路徑下的驅動文件。本以為這種方式很nice，結果老員工卻告訴我當我編譯出來的oot驅動文件有bug的時候，即使重新啟動系統，原本的驅動也無法恢復，導致設備工作異常；因為該路徑下原有的in-tree驅動文件已不存在，而使用insmod直接加載我編譯出來的oot驅動時，即使該驅動文件有bug，系統重啟后，依然可以通過使用/lib/modules/$(uname -r)/kernel/drivers/net/ethernet/netronome/nfp/路徑下的in-tree驅動文件正常啟動系統。
想一想，好像確實是這個道理，于是，在日后的工作中，但凡加載自己手動編譯的oot驅動，我都是使用insmod命令。但是，后續的工作中，又遇到了一個問題，就是使用insmod加載的驅動，在系統重新啟動后，又變成了系統自帶的in-tree驅動。于是，只能再次手動卸載in-tree驅動，再加載oot驅動。如果該主機上部署了與該oot驅動模塊緊密相關的業務環境，意味著一切將需要重新手動設置一遍，不可謂不麻煩。于是乎，系統重啟后自動加載oot驅動就成了一個亟待解決的問題。
因此，遂考慮可能是因為使用insmod加載驅動的緣故，導致系統重新啟動后無法自動加載oot驅動。于是，便研究如何在工作中通過modprobe來加載oot驅動。
?
注意：其實導致系統重新啟動后無法自動加載oot驅動，與使用insmod或modprobe加載沒有關系，后續內容會講解。
?
【拓展】：模塊依據代碼編寫與編譯時的位置可分：內部模塊和外部模塊，即 in-tree模塊 和 out-of-tree(即oot)模塊，在內核樹外部編寫并構建的模塊就是外部模塊。動態加載的模塊包括in-tree模塊和out-of-tree(oot)模塊。in-tree 模塊是 Linux 內核樹的內部自帶的模塊，即它們已經是內核的一部分。樹外模塊是 來自 Linux 內核樹的外部。它們通常是為開發和測試目的編寫的，例如測試樹級或處理不兼容的內核模塊的新版本。往往oot模塊雖然安裝成功了，但是會提示loading out-of-tree module taints kernel，可通過dmesg查看到。
經過針對 modprobe 的研究和實驗，本文總結三種方法：拷貝法、軟鏈接法和配置 external 路徑法。
?
注意：本文所有實驗均在centos Stream 8系統上進行，一切配置和命令僅適用于CentOS系列機器，Ubuntu與其他機器具體配置指令可能有所區別。
二、modprobe加載oot驅動總結
這里有關modprobe的使用總結的三種方法，均需要依賴/etc/depmod.d/下的配置文件來實現自動識別驅動加載路徑。/etc/depmod.d/下通常會含有如下配置文件：
[root@localhost?~]#?ls?-l?/etc/depmod.d/ total?8 -rw-r--r--.?1?root?root?116?Jun??5??2021?dist.conf -rw-r--r--.?1?root?root?115?Nov?10??2021?kvdo.conf
接下來，讓我們一起了解一下有關使用modprobe的三種方法。
1、拷貝法
將自己編譯生成的oot驅動文件拷貝到/lib/modules/$(uname -r)/extra/目錄下，再執行echo “override xxx * extra” > /etc/depmod.d/xxx.conf命令，確保當Linux內核中存在多個同名的內核模塊時，優先安裝/lib/modules/$(uname -r)/extra/目錄下的文件。隨后，再執行depmod -a 進行模塊依賴的更新(驅動如果存在依賴項，必須先加載依賴項后才能進行驅動的安裝)。
?
注意：echo “override xxx * extra” > /etc/depmod.d/xxx.conf 命令表示在/etc/depmod.d/目錄下創建一個 xxx.conf（名字任意）文件，在里面添加override xxx * extra(其中，xxx表示待加載的驅動名字(不帶.ko后綴)，*表示匹配任何內核版本，也可以指定具體的內核版本)，通過/etc/depmod.d目錄內的配置文件，設置override命令，確保安裝在 /lib/modules/$(uname -r)/extra/（或其他模塊位置）下的任何匹配模塊名稱將優先于內核已經提供的任何類似名稱的模塊。外部開發的模塊一般我們都放在/lib/modules/$(uname -r)/extra 目錄下使用。
?
【拓展】：depmod配置文件的override命令格式和解析如下：
override?modulename?kernelversion?modulesubDirectorythis command allows you to override which version of a specific module will be used when more than one module sharing the same name is processed by the depmod command. It is possible to specify one kernel or all kernels using the * wildcard. modulesubdirectory is the name of the subdirectory under /lib/modules (or other module location) where the target module is installed. for example, it is possible to override the priority of an updated test module called kmod by specifying the following command: “override kmod * extra”. This will ensure that any matching module name installed under the extra subdirectory within /lib/modules (or other module location) will take priority over any likenamed module already provided by the kernel.
實戰演示如下：
#?將自己編譯的oot?nfp驅動拷貝到/lib/modules/$(uname?-r)/extra/路徑下 [root@localhost?~]#?cp?/home/xxx/nfp-drv-kmods-private/src/nfp.ko?/lib/modules/$(uname?-r)/extra/nfp.ko [root@localhost?~]#?ls?-l?/lib/modules/$(uname?-r)/extra total?50900 -rw-r--r--.?1?root?root?52121240?Nov?15?19:49?nfp.ko? #?如果/etc/下不存在depmod.d目錄，則執行如下命令創建depmod.d目錄，否則無需執行 [root@localhost?~]#?mkdir?-p?/etc/depmod.d #?該命令確保在depmod命令處理多個共享相同名稱的內核模塊時，優先安裝/lib/modules/$(uname?-r)/extra/下的模塊 [root@localhost?~]#?echo?"override?nfp?*?extra"?>?/etc/depmod.d/nfp.conf #?探測所有模塊。如果在命令行中沒有給出文件名，則默認啟用此選項。 [root@localhost?~]#?depmod?-a #?depmod創建一個模塊依賴列表，并確定它導出了什么符號以及它需要什么符號。默認情況下，該列表被寫入modules.dep [root@localhost?~]#?cat?/lib/modules/$(uname?-r)/modules.dep?|?grep?nfp extra/nfp.ko: [root@localhost?~]# #?系統自帶in-tree?nfp驅動，顯示大小為442368字節 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????442368??0 tls???????????????????110592??1?nfp #?卸載系統自帶的in-tree?nfp驅動 [root@localhost?~]#?rmmod?nfp #?直接modprobe?nfp就會加載手動編譯的oot?nfp驅動 [root@localhost?~]#?modprobe?nfp #?手動編譯的oot?nfp驅動，顯示大小為585728字節 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0 #?將depmod?-a更新后的結果保存到initramfs中,這一步可選 [root@localhost?~]#?dracut?-f
根據上面的結果，可以看出來拷貝法需要將手動編譯的oot驅動復制到/lib/modules/$(uname -r)/extra目錄下，創建depmod的配置文件，即/etc/depmod.d/nfp.conf，使用depmod創建模塊依賴列表，再使用modprobe加載驅動的時候，就可以成功安裝我們手動編譯的oot驅動了。這里之所以將oot驅動復制到extra目錄下，是為了更新依賴列表后就可以使用modprobe成功安裝，因為執行了echo “override nfp * extra” > /etc/depmod.d/nfp.conf這一步，override命令確保安裝在 /lib/modules/$(uname -r)/extra/下的nfp 驅動將優先于內核已經提供的任何同名的模塊。
上面實戰演示中的dracut -f是可選的步驟，可以執行，也可以不執行。具體作用后面再詳細介紹。
2、軟鏈接法
軟鏈接法與拷貝法比較相似，區別僅在于將自己編譯生成的 oot 驅動文件通過建立軟鏈接鏈接到 /lib/modules/$(uname -r)/extra/ 目錄下，而非拷貝到 extra 目錄下，其余步驟與拷貝法基本相同。
?
注意：uname -r 是獲取系統當前使用的內核版本，不同內核版本有各自的內核目錄。
實戰演示如下：
[root@localhst?~]#?rm?-f?/lib/modules/$(uname?-r)/extra/nfp.ko [root@localhost?~]#?ls?-l?/lib/modules/$(uname?-r)/extra total?0 #?建立軟鏈接 [root@localhost?~]#?ln?-sf?/home/xxx/nfp-drv-kmods-private/src/nfp.ko???/lib/modules/$(uname?-r)/extra/nfp.ko [root@localhost?~]#?ls?-l?/lib/modules/$(uname?-r)/extra total?0 lrwxrwxrwx.?1?root?root?42?Nov?16?12:20?nfp.ko?->?/home/xxx/nfp-drv-kmods-private/src/nfp.ko #?因拷貝法中已創建并配置該文件，因此，這里直接使用即可。否則，需要創建并配置該文件內容如下 [root@localhost?~]#?cat?/etc/depmod.d/nfp.conf override?nfp?*?extra #?創建依賴列表 [root@localhost?~]#?depmod?-a #?卸載掉之前安裝的驅動模塊 [root@localhost?~]#?rmmod?nfp #?安裝手動編譯的oot?nfp驅動 [root@localhost?~]#?modprobe?nfp #?查看新加載的oot?nfp驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0 #?將depmod?-a更新后的結果保存到initramfs中,這一步可選 [root@localhost?~]#?dracut?-f
根據上面的結果，可以看出來軟鏈接法需要將手動編譯的oot驅動鏈接到/lib/modules/$(uname -r)/extra目錄下，創建并配置depmod的配置文件，再使用depmod創建模塊依賴列表。當使用modprobe加載驅動的時候，就可以成功安裝我們手動編譯的oot驅動了。這里之所以將oot驅動軟鏈接到extra目錄下，更新依賴列表后就可以使用modprobe成功安裝，是因為創建并配置了depmod的配置文件，override命令確保安裝在 /lib/modules/$(uname -r)/extra/下的nfp 驅動將優先于內核已經提供的任何同名的模塊。
上面實戰演示中的dracut -f是可選的步驟，可以執行，也可以不執行。具體作用后面再詳細介紹。
3、配置external路徑
?
【解析】使用external關鍵字，可以指定系統上的任意編譯生成oot驅動的目錄作為modprobe安裝驅動的路徑。
配置external路徑法無需將自己編譯生成的oot驅動文件拷貝或者建立軟鏈接到/lib/modules/$(uname -r)/extra/目錄下，但是需執行echo “external * /home/xxx/nfp-drv-kmods-private/src” > /etc/depmod.d/xxx.conf命令以及配置/etc/depmod.d/dist.conf 文件。隨后，再執行depmod -a 進行模塊依賴表的更新，即更新modules.dep和modules.dep.bin文件。這時，再進行modprobe的時候，直接安裝的則是通過external命令指定的路徑下的oot驅動。
?
注意：echo “external * /home/xxx/nfp-drv-kmods-private/src” > /etc/depmod.d/xxx.conf 命令表示在/etc/depmod.d/目錄下創建一個 xxx.conf（名字任意）文件，在里面添加external * /home/xxx/nfp-drv-kmods-private/src(其中，/home/xxx/nfp-drv-kmods-private/src為編譯出oot驅動的路徑(xxx表示一個實際的路徑名字而已)， *表示匹配任何內核版本，也可以指定具體的內核版本)，通過/etc/depmod.d目錄內的配置文件，設置external命令，表示這是一個外部的路徑。/etc/depmod.d/dist.conf的內容則表示搜索路徑的優先級，如果想優先匹配external指定的路徑下的文件，則需將external放在extra和built-in之前。這樣external指定的路徑下的任何匹配模塊名稱將優先于extra內保存的同名模塊和內核已經提供的同名模塊。
?
【拓展】：depmod配置文件的external命令格式和解析如下：
external?kernelversion?absolutemodulesdirectory...This specifies a list of directories, which will be checked according to the priorities in the search command. The order matters also, the first directory has the higher priority. The kernelversion is a POSIX regular expression or * wildcard, like in the override.
實戰演示如下：
#?創建并配置depmod配置文件auto_define.conf [root@localhost?~]#?echo?"external?*?/home/xxx/nfp-drv-kmods-private/src"?>?/etc/depmod.d/auto_define.conf [root@localhost?~]#?cat?/etc/depmod.d/auto_define.conf external?*??/home/xxx/nfp-drv-kmods-private/src [root@localhost?~]#?ls?-l?/etc/depmod.d/ auto_define.conf??dist.conf??kvdo.conf #?編輯dist.conf文件內容，使external指定的路徑優先級高于extra和built-in，即將external放在extra和built-in前面 [root@localhost?~]#?vi?/etc/depmod.d/dist.conf #?查看dist.conf文件內容 [root@localhost?~]#?cat?/etc/depmod.d/dist.conf # #?depmod.conf # #?override?default?search?ordering?for?kmod?packaging search?updates?external?extra?built-in?weak-updates #?創建依賴列表 [root@localhost?~]#?depmod?-a #?查看modules.dep內容，根據檢索結果可知，加載驅動使用的是/home/xxx/nfp-drv-kmods-private/src/路徑下的oot?nfp驅動 [root@localhost?~]#?cat?/lib/modules/4.18.0-500.el8.x86_64/modules.dep?|?grep?nfp.ko /home/xxx/nfp-drv-kmods-private/src/nfp.ko: #?卸載掉系統上原有已加載的驅動 [root@localhost?~]#?rmmod?nfp #?重新加載驅動 [root@localhost?~]#?modprobe?nfp [root@localhost?~]# #?oot?nfp驅動加載成功 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0? #?將depmod?-a更新后的結果保存到initramfs中,這一步可選 [root@localhost?~]#?dracut?-f
需要注意的是：因為在/etc/depmod.d/dist.conf中，external的優先級高于extra，因此使用modprobe的時候，優先加載的是external 指定路徑下的驅動文件。否則，如果dist.conf的內容如下所示：
[root@localhost?~]#?cat?/etc/depmod.d/dist.conf # #?depmod.conf # #?override?default?search?ordering?for?kmod?packaging search?updates?extra?external?built-in?weak-updates
即extra位于external之前，則modprobe的時候，優先加載的將是/lib/modules/$(uname -r)/extra/目錄下的驅動文件。
?
注意：built-in表示/lib/modules/$(uname -r)/kernel/drivers/net/ethernet/netronome/nfp/目錄。
三、重啟系統后自動加載oot驅動
在日常Linux驅動開發及調試的過程中，經常遇到需要手動加載oot驅動成功的情況下，一旦重啟系統以后，機器上重啟前已成功加載的驅動就不見了，又需要重新再手動加載一遍，要是上面部署著復雜的業務，則全部都需要再重新部署一遍，就極其麻煩了。于是乎，系統重啟后自動加載oot驅動就成了一個亟待解決的問題。針對這個問題，小編經過學習以及工作中實戰，終于摸索出這里面的規律，總結如下：
- 規律一：無論是使用insmod或modprobe 加載驅動，如果未執行dracut —force 指令，均有可能會出現重啟系統后系統中原來加載的oot驅動消失，被in-tree驅動替代的現象。
- 規律二：如果initramfs中包含相關驅動且系統硬盤驅動庫目錄下存在同名的驅動，則系統重啟時，會加載initramfs中的該驅動(in-tree或oot 均適用)。
- 規律三：如果initramfs中包含多個同名驅動(in-tree或oot)，則會根據這些同名驅動的優先級(/etc/depmod.d/dist.conf中含有優先級)，系統啟動時選擇優先級最高的驅動加載。
- 規律四：如果initramfs中不包含相關驅動，而系統硬盤驅動庫下存在同名的驅動，則系統啟動時會選擇系統硬盤驅動庫目錄下的該同名驅動加載。
?
【拓展】initramfs 即 initram file system，翻譯成中文意思就是 初始 ram 文件系統，基于 tmpfs，是一種大小靈活，直接作用在內存中的文件系統。initramfs包含的工具和腳本，在正式的根文件系統的初始化腳本 init 啟動之前，就被掛載。Linux系統開機后，首先加載initramfs文件中包含的驅動程序，如果相應的設備對應的驅動不在initramfs文件包含范圍內，那么會去系統硬盤存儲的驅動庫中去尋找匹配的驅動進行加載；系統硬盤驅動庫的位置即為：/lib/modules/$($uname -r)/(下面講系統硬盤驅動庫時，即表示該目錄)；所以相應的驅動只要在系統硬盤的驅動庫下或者initramfs中至少存在一個就可以正常加載，一旦在initramfs中加載成功，無論系統硬盤的驅動庫中存在的驅動版本是否相同都不會重新去加載。initramfs中包含的驅動ko文件在目錄lib/modules/下，具體包含的ko可依次查看。
針對上述總結的規律，讓我們通過實戰演示來驗證一下。
1、規律一
無論是使用insmod或modprobe 加載驅動，如果未執行dracut –force 指令，均有可能會出現重啟系統后系統中原來加載的oot驅動消失，被in-tree驅動替代的現象。
實戰演示如下：
#?卸載掉系統中原來安裝的nfp驅動 [root@localhost?~]#?rmmod?nfp [root@localhost?~]#?lsmod?|?grep?nfp [root@localhost?~]#?ls?-l?/home/xxx/nfp-drv-kmods-private/src/?|?grep?nfp.ko -rw-r--r--.?1?root?root?52121240?Nov?17?19:10?nfp.ko #?insmod安裝自己編譯的oot?nfp驅動 [root@localhost?~]#?insmod?/home/xxx/nfp-drv-kmods-private/src/nfp.ko [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0 #?insmod安裝完oot?nfp驅動后，直接重啟系統 [root@localhost?~]#?reboot #?重啟系統后雖然加載了nfp驅動，但是并非自己編譯的oot?nfp驅動，而是系統內核自帶的in-tree?nfp驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????442368??0 tls???????????????????110592??1?nfp
通過對比系統重啟前后，加載的nfp驅動的大小可以知道，前后加載的驅動并非同一個驅動。果然，如果未執行dracut –force 指令，系統啟動后，系統內核自帶的in-tree驅動會取代了我自己編譯的oot驅動。那dracut –force指令的作用是什么呢？其實這個命令的作用就是將當前系統硬盤驅動庫中包含的驅動寫入到initramfs鏡像中，該鏡像會在系統啟動過程中，將里面含有的相關驅動加載到系統中。讓我們執行這個命令后，再看一下結果：
[root@localhost?~]#?rmmod?nfp [root@localhost?~]#?insmod?/home/xxx/nfp-drv-kmods-private/src/nfp.ko [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0 #?dracut?-f為?dracut?--force的縮寫 [root@localhost?~]#?dracut?-f [root@localhost?~]#? [root@localhost?~]#?reboot #?重啟后，加載的是in-tree?nfp驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????442368??0 tls???????????????????110592??1?nfp
明明前面說oot驅動加載后，未執行dracut –force，系統啟動后，系統內核自帶的in-tree驅動會取代了我自己編譯的oot驅動。為什么我現在執行了這個命令，我編譯的 oot 驅動卻還是被系統內核自帶的in-tree驅動取代了呢？因為dracut -f這個命令的作用是將當前系統硬盤驅動庫中包含的驅動寫入到initramfs鏡像中，而我使用 insmod 加載的是我自己編譯目錄下的驅動，而系統硬盤驅動庫中并未含有我編譯的 oot 驅動，讓我將自己編譯的oot驅動放置到系統硬盤驅動庫下屬的extra目錄下，再驗證一下結果會是怎么樣。
[root@localhost?~]#?cd?/lib/modules/$(uname?-r)/extra/ [root@localhost?extra]#?ls [root@localhost?extra]#?cp?/home/xxx/nfp-drv-kmods-private/src/nfp.ko?. [root@localhost?extra]#?ls nfp.ko [root@localhost?extra]#?pwd /lib/modules/4.18.0-500.el8.x86_64/extra [root@localhost?extra]#?rmmod?nfp #?insmod加載編譯路徑下的oot驅動 [root@localhost?extra]#?insmod?/home/xxx/nfp-drv-kmods-private/src/nfp.ko [root@localhost?extra]#?lsmod?|?grep?nfp nfp???????????????????585728??0 #建立模塊依賴列表 [root@localhost?extra]#?depmod?-a #?將oot驅動復制到extra目錄下以后，執行depmod?-a果然更新了模塊依賴列表 [root@localhost?extra]#?cat?/lib/modules/$(uname?-r)/modules.dep?|?grep?nfp.ko extra/nfp.ko: #?更新initramfs鏡像 [root@localhost?extra]#?dracut?-f #?拷貝initramfs到新創建的test1目錄下 [root@localhost?test1]#?cp?/boot/initramfs-4.18.0-500.el8.x86_64.img?. [root@localhost?test1]#?ls initramfs-4.18.0-500.el8.x86_64.img #?解壓縮initramfs到新創建的test1目錄下 [root@localhost?test1]#?/usr/lib/dracut/skipcpio?./initramfs-4.18.0-500.el8.x86_64.img?|?zcat?|?cpio?-ivd . bin dev dev/console dev/kmsg dev/null dev/random dev/urandom etc ...... [root@localhost?test1]#?ls bin??etc???init?????????????????????????????????lib????opt???root??sbin??????sys??????tmp??var dev??home??initramfs-4.18.0-500.el8.x86_64.img??lib64??proc??run???shutdown??sysroot??usr #?initramfs鏡像的lib/modules/4.18.0-500.el8.x86_64/extra/目錄下含有nfp.ko [root@localhost?test1]#?ls?./lib/modules/4.18.0-500.el8.x86_64/extra/ nfp.ko #?重新啟動系統 [root@localhost?test1]#?reboot #重啟系統后，加載的是我自己編譯的oot驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0
果然，將自己編譯的oot驅動放置到系統硬盤驅動庫下屬的extra目錄下，執行depmod -a，再執行dracut -f，即會更新initramfs鏡像，使其在initramfs鏡像內的驅動庫下屬的extra目錄下含有我編譯的oot驅動，這樣系統再重啟以后，就會自動加載我編譯的oot驅動了。因此，無論是使用insmod或modprobe加載oot驅動，重點是將自己編譯的oot驅動放置到硬盤驅動庫下屬的相關目錄下，執行depmod -a，再執行dracut -f，更新initramfs鏡像，使其在initramfs鏡像內的驅動庫下屬相關目錄下含有我編譯的oot驅動，這樣系統再重啟以后，就會自動加載我編譯的oot驅動了。
這里，modprobe加載oot驅動的演示就不再給出，感興趣的小伙伴可以自行嘗試。
2、規律二
如果initramfs中包含相關驅動且系統硬盤驅動庫目錄下存在同名的驅動，則系統重啟時，會加載initramfs中的該驅動(in-tree或oot 均適用)。
實戰演示如下：
#?創建test2目錄，并將dracut?-f生成的initramfs鏡像拷貝到該目錄下 [root@localhost?test2]#?cp?/boot/initramfs-4.18.0-500.el8.x86_64.img?. [root@localhost?test2]#?ls initramfs-4.18.0-500.el8.x86_64.img #?解壓initramfs鏡像到當前目錄下 [root@localhost?test2]#?/usr/lib/dracut/skipcpio?./initramfs-4.18.0-500.el8.x86_64.img?|?zcat?|?cpio?-ivd . bin dev dev/console dev/kmsg ...... [root@localhost?test2]#?ls bin??etc???init?????????????????????????????????lib????opt???root??sbin??????sys??????tmp??var dev??home??initramfs-4.18.0-500.el8.x86_64.img??lib64??proc??run???shutdown??sysroot??usr #?解壓的initramfs鏡像的lib/modules/4.18.0-500.el8.x86_64/extra/目錄下含有nfp.ko，該驅動為oot驅動 [root@localhost?test1]#?ls?./lib/modules/4.18.0-500.el8.x86_64/extra/ nfp.ko #?系統硬盤驅動庫目錄下屬目錄中存在同名的驅動,該驅動為in-tree驅動 [root@localhost?~]#?ls?/lib/modules/$(uname?-r)/kernel/drivers/net/ethernet/netronome/nfp/ nfp.ko.xz #?重啟系統 [root@localhost?~]#?reboot #?根據nfp驅動的大小，可知重啟后加載的驅動為oot驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????585728??0
根據實戰演示的結果可知，當initramfs鏡像和系統硬盤驅動庫目錄下存在同名的驅動時，重啟操作系統后，加載的是位于initramfs鏡像內的oot驅動。
3、規律三
如果initramfs中包含多個同名驅動(in-tree或oot)，則會根據這些同名驅動的優先級(/etc/depmod.d/dist.conf中含有優先級)，系統啟動時選擇優先級最高的驅動加載。
實戰演示如下：
[root@localhost?~]#?vi?/etc/depmod.d/dist.conf [root@localhost?~]#?vi?/etc/depmod.d/auto_define.conf [root@localhost?~]#?cat?/etc/depmod.d/auto_define.conf external?*??/home/xxx/nfp-drv-kmods-private/src #?external位于extra和built-in之前，表示其優先級高于后兩者 [root@localhost?~]#?cat?/etc/depmod.d/dist.conf # #?depmod.conf # #?override?default?search?ordering?for?kmod?packaging search?updates?external?extra?built-in?weak-updates #更新模塊依賴列表 [root@localhost?~]#?depmod?-a #?查看模塊依賴列表，優先級最高的是external設定的/home/xxx/nfp-drv-kmods-private/src/目錄下的nfp驅動 [root@localhost?~]#?cat?/lib/modules/$(uname?-r)/modules.dep?|?grep?nfp /home/xxx/nfp-drv-kmods-private/src/nfp.ko: #?更新initramfs鏡像 [root@localhost?~]#?dracut?-f #?創建test3目錄，并將dracut?-f生成的initramfs鏡像拷貝到該目錄下 [root@localhost?test3]#?cp?/boot/initramfs-4.18.0-500.el8.x86_64.img?. [root@localhost?test3]#?ls initramfs-4.18.0-500.el8.x86_64.img #?解壓initramfs鏡像到當前目錄下 [root@localhost?test3]#?/usr/lib/dracut/skipcpio?./initramfs-4.18.0-500.el8.x86_64.img?|?zcat?|?cpio?-ivd . bin dev dev/console dev/kmsg ...... [root@localhost?test3]#?ls bin??etc???init?????????????????????????????????lib????opt???root??sbin??????sys??????tmp??var dev??home??initramfs-4.18.0-500.el8.x86_64.img??lib64??proc??run???shutdown??sysroot??usr #?initramfs鏡像中含有/etc/depmod.d/auto_define.conf中定義的external目錄下含義oot驅動 [root@localhost?test3]#?ls?-l?./home/xxx/nfp-drv-kmods-private/src/?|?grep?nfp.ko -rw-r--r--.?1?root?root?52119640?Nov?18?21:51?nfp.ko #?initramfs鏡像中含有驅動庫目錄下的in-tree驅動 [root@localhost?test3]#?ls?./lib/modules/$(uname?-r)/kernel/drivers/net/ethernet/netronome/nfp/ nfp.ko.xz #?重啟系統 [root@localhost?~]#?reboot #?由已加載驅動的大小與前面均不同可知，加載的為external指定的目錄下加載的oot驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????589824??0
根據實戰演示結果可知，當initramfs中包含多個同名驅動(in-tree或oot)時，則會根據這些同名驅動的優先級，選擇優先級最高的驅動加載，無論其是in-tree或oot驅動。
4、規律四
如果initramfs中不包含相關驅動，而系統硬盤驅動庫下存在同名的驅動，則系統啟動時會選擇系統硬盤驅動庫目錄下的該同名驅動加載。
實戰演示如下：
#?創建一個臨時目錄test4，存放initramfs鏡像及解壓后的文件 [root@localhost?tmp]#?mkdir?test4 #?構造系統上不包含任何nfp驅動的當前內核對應的initramfs鏡像并拷貝到test4目錄下 [root@localhost?test4]#?cp?/boot/initramfs-$(uname?-r).img?. [root@localhost?test4]#?ls initramfs-4.18.0-500.el8.x86_64.img #?使用skipcpio解壓縮當前目錄下的initramfs鏡像 [root@localhost?test4]#?/usr/lib/dracut/skipcpio?./initramfs-4.18.0-500.el8.x86_64.img?|?zcat?|?cpio?-ivd . bin dev dev/console dev/kmsg dev/null dev/random dev/urandom etc etc/centos-release etc/cmdline.d etc/conf.d etc/conf.d/systemd.conf ... #?查看當前目錄解壓后包含的文件 [root@localhost?test4]#?ls bin??etc???init?????????????????????????????????lib????opt???root??sbin??????sys??????tmp??var dev??home??initramfs-4.18.0-500.el8.x86_64.img??lib64??proc??run???shutdown??sysroot??usr #?查看解壓后的initramfs中是否存在nfp驅動及依賴 [root@localhost?test4]#?cat?./lib/modules/4.18.0-500.el8.x86_64/modules.dep?|?grep?nfp #?解壓后的initramfs中，連extra目錄都不存在 [root@localhost?test4]#?ls?-l?./lib/modules/4.18.0-500.el8.x86_64/extra/ ls:?cannot?access?'./lib/modules/4.18.0-500.el8.x86_64/extra/':?No?such?file?or?directory #?解壓后的initramfs中，連lib/modules/4.18.0-500.el8.x86_64/kernel/drivers/net/ethernet/netronome/nfp/目錄都不存在 [root@localhost?test4]#?ls?-l?./lib/modules/4.18.0-500.el8.x86_64/kernel/drivers/net/ethernet/netronome/nfp/ ls:?cannot?access?'./lib/modules/4.18.0-500.el8.x86_64/kernel/drivers/net/ethernet/netronome/nfp/':?No?such?file?or?directory #?解壓后的initramfs中，完全檢索不到nfp.ko文件 [root@localhost?test4]#?find?./?-name?"nfp.ko" [root@localhost?test4]# #?查看當前系統驅動庫下模塊依賴列表/lib/modules/$(unaem?-r)/modules.dep中是否包含nfp驅動 #?只有該列表中包含nfp驅動記錄且硬盤驅動庫下存在nfp驅動，在系統重啟后，才能夠成功加載硬盤上驅動庫目錄下的nfp驅動， #?否則將不會加載nfp驅動。 [root@localhost?~]#?cat?/lib/modules/$(uname?-r)/modules.dep?|?grep?nfp kernel/drivers/net/ethernet/netronome/nfp/nfp.ko.xz:?kernel/net/tls/tls.ko.xz #?檢查系統硬盤驅動庫下是否存在nfp驅動 [root@localhost?~]#?ls?-l?/lib/modules/$(uname?-r)/kernel/drivers/net/ethernet/netronome/nfp/ total?176 -rw-r--r--.?1?root?root?176228?Jun?28?08:17?nfp.ko.xz #?卸載掉系統上當前安裝的nfp驅動 [root@localhost?~]#?rmmod?nfp #?重啟操作系統 [root@localhost?~]#?reboot #?查看重啟后的系統中是否成功加載nfp驅動，果然加載的是in-tree?nfp驅動，即硬盤驅動目錄下的nfp驅動 [root@localhost?~]#?lsmod?|?grep?nfp nfp???????????????????442368??0 tls???????????????????110592??1?nfp
上述實戰結果證明，initramfs 鏡像中如果不包含相關驅動，而系統驅動庫下的模塊依賴列表中含有驅動依賴記錄，且系統硬盤驅動庫下屬目錄(即/lib/modules/$(uname -r)/kernel/drivers/net/ethernet/netronome/nfp/)存在同名的驅動，則系統啟動時會選擇系統硬盤驅動庫目錄下屬目錄包含的該同名驅動進行加載。然而，如果系統驅動庫下的模塊依賴列表中不包含驅動依賴記錄，則即使系統硬盤驅動庫下屬目錄中含有相關驅動，操作系統亦不會加載。如下結果能夠證明該結論。
[root@localhost?~]#?cat?/lib/modules/$(uname?-r)/modules.dep?|?grep?nfp [root@localhost?~]# [root@localhost?~]#?ls?-l?/lib/modules/$(uname?-r)/kernel/drivers/net/ethernet/netronome/nfp/ total?176 -rw-r--r--.?1?root?root?176228?Jun?28?08:17?nfp.ko.xz [root@localhost?~]#?rmmod?nfp [root@localhost?~]#?lsmod?|?grep?nfp [root@localhost?~]#?reboot #?重啟系統后，檢查系統中是否含有nfp驅動，結果顯示沒有加載nfp驅動 [root@localhost?~]#?lsmod?|?grep?nfp [root@localhost?~]#
至此，有關modprobe加載oot驅動與重啟系統后自動加載oot驅動的分析就總結完畢了。俗話講：“好記性不如爛筆頭”；將相關知識總結成文，等日后有需要的時候可以拿出來快速回顧一下，當然這也有助于加深對這方面知識的理解。
最后，希望對于從事Linux驅動的朋友們有所幫助和啟發。
