來自網址http://www.kerneltravel.net/jiaoliu/005.htm
用戶程序和內核的信息交換是雙向的，也就是說既可以主動從用戶空間向內核空間發送信息，也可以從內核空間向用戶空間提交數據。當然，用戶程序也可以主動地從內核提取數據。下面我們就針對內核和用戶交互數據的方法做一總結、歸納。
信息交互按信息傳輸發起方可以分為用戶向內核傳送/提取數據和內核向用戶空間提交請求兩大類，先來說說：由用戶級程序主動發起的信息交互。
用戶級程序主動發起的信息交互
A編寫自己的系統調用
系統調用是用戶級程序訪問內核最基本的方法。目前linux大致提供了二百多個標准的系統調用（參見內核代碼樹中的include/ asm-i386/unistd.h和arch/i386/kernel/entry.S文件），並且允許我們添加自己的系統調用來實現和內核的信息交換。比如我們希望建立一個系統調用日志系統，將所有的系統調用動作記錄下來，以便進行入侵檢測。此時，我們可以編寫一個內核服務程序。該程序負責收集所有的系統調用請求，並將這些調用信息記錄到在內核中自建的緩沖里。我們無法在內核里實現復雜的入侵檢測程序，因此必須將該緩沖里的記錄提取到用戶空間。最直截了當的方法是自己編寫一個新系統調用實現這種提取緩沖數據的功能。當內核服務程序和新系統調用都實現后，我們就可以在用戶空間里編寫用戶程序進行入侵檢測任務了，入侵檢測程序可以定時、輪訓或在需要的時候調用新系統調用從內核提取數據，然后進行入侵檢測了。
B編寫驅動程序
Linux/UNIX的一個特點就是把所有的東西都看作是文件(every thing is a file)。系統定義了簡潔完善的驅動程序界面，客戶程序可以用統一的方法透過這個界面和內核驅動程序交互。而大部分系統的使用者和開發者已經非常熟悉這種界面以及相應的開發流程了。
驅動程序運行於內核空間，用戶空間的應用程序通過文件系統中/dev/目錄下的一個文件來和它交互。這就是我們熟悉的那個文件操作流程：open() —— read() —— write() —— ioctl() —— close()。（需要注意的是也不是所有的內核驅動程序都是這個界面，網絡驅動程序和各種協議棧的使用就不大一致，比如說套接口編程雖然也有open()close()等概念，但它的內核實現以及外部使用方式都和普通驅動程序有很大差異。）
設備驅動程序在內核中要做的中斷響應、設備管理、數據處理等等各種工作這篇文章不去關心，我們把注意力集中在它與用戶級程序交互這一部分。操作系統為此定義了一種統一的交互界面，就是前面所說的open(), read(), write(), ioctl()和close()等等。每個驅動程序按照自己的需要做獨立實現，把自己提供的功能和服務隱藏在這個統一界面下。客戶級程序選擇需要的驅動程序或服務（其實就是選擇/dev/目錄下的文件），按照上述界面和文件操作流程，就可以跟內核中的驅動交互了。其實用面向對象的概念會更容易解釋，系統定義了一個抽象的界面（abstract interface），每個具體的驅動程序都是這個界面的實現（implementation）。
所以驅動程序也是用戶空間和內核信息交互的重要方式之一。其實ioctl, read, write本質上講也是通過系統調用去完成的，只是這些調用已被內核進行了標准封裝，統一定義。因此用戶不必向填加新系統調用那樣必須修改內核代碼，重新編譯新內核，使用虛擬設備只需要通過模塊方法將新的虛擬設備安裝到內核中（insmod上）就能方便使用。關於此方面設計細節請查閱參考資料5，編程細節請查閱參考資料6。
在linux中，設備大致可分為：字符設備，塊設備，和網絡接口（字符設備包括那些必須以順序方式，像字節流一樣被訪問的設備；如字符終端，串口等。塊設備是指那些可以用隨機方式，以整塊數據為單位來訪問的設備，如硬盤等；網絡接口，就指通常網卡和協議棧等復雜的網絡輸入輸出服務）。如果將我們的系統調用日志系統用字符型驅動程序的方式實現，也是一件輕松愜意地工作。我們可以將內核中收集和記錄信息的那一部分編寫成一個字符設備驅動程序。雖然沒有實際對應的物理設備，但這並沒什么問題：Linux的設備驅動程序本來就是一個軟件抽象，它可以結合硬件提供服務，也完全可以作為純軟件提供服務（當然，內存的使用我們是無法避免的）。在驅動程序中，我們可以用open來啟動服務，用read()返回處理好的記錄，用ioctl()設置記錄格式等，用close()停止服務，write()沒有用到，那么我們可以不去實現它。然后在/dev/目錄下建立一個設備文件對應我們新加入內核的系統調用日志系統驅動程序。
C: 使用proc 文件系統
proc是Linux提供的一種特殊的文件系統，推出它的目的就是提供一種便捷的用戶和內核間的交互方式。它以文件系統作為使用界面，使應用程序可以以文件操作的方式安全、方便的獲取系統當前運行的狀態和其它一些內核數據信息。
proc文件系統多用於監視、管理和調試系統，我們使用的很多管理工具如ps,top等，都是利用proc來讀取內核信息的。除了讀取內核信息，proc文件系統還提供了寫入功能。所以我們也就可以利用它來向內核輸入信息。比如，通過修改proc文件系統下的系統參數配置文件（/proc/sys），我們可以直接在運行時動態更改內核參數；再如，通過下面這條指令：
echo 1 > /proc/sys/net/ip_v4/ip_forward
開啟內核中控制IP轉發的開關，我們就可以讓運行中的Linux系統啟用路由功能。類似的，還有許多內核選項可以直接通過proc文件系統進行查詢和調整。
除了系統已經提供的文件條目，proc還為我們留有接口，允許我們在內核中創建新的條目從而與用戶程序共享信息數據。比如，我們可以為系統調用日志程序（不管是作為驅動程序也好，還是作為單純的內核模塊也好）在proc文件系統中創建新的文件條目，在此條目中顯示系統調用的使用次數，每個單獨系統調用的使用頻率等等。我們也可以增加另外的條目，用於設置日志記錄規則，比如說不記錄open系統調用的使用情況等。關於proc文件系統得使用細節，請查閱參考資料7。
D: 使用虛擬文件系統
有些內核開發者認為利用ioctl（）系統調用往往會似的系統調用意義不明確，而且難控制。而將信息放入到proc文件系統中會使信息組織混亂，因此也不贊成過多使用。他們建議實現一種孤立的虛擬文件系統來代替ioctl()和/proc，因為文件系統接口清楚，而且便於用戶空間訪問，同時利用虛擬文件系統使得利用腳本執行系統管理任務更家方便、有效。
我們舉例來說如何通過虛擬文件系統修改內核信息。我們可以實現一個名為sagafs的虛擬文件系統，其中文件log對應內核存儲的系統調用日志。我們可以通過文件訪問特普遍方法獲得日志信息：如
# cat /sagafs/log
使用虛擬文件系統——VFS實現信息交互使得系統管理更加方便、清晰。但有些編程者也許會說VFS 的API 接口復雜不容易掌握，不要擔心2.5內核開始就提供了一種叫做libfs的例程序幫助不熟悉文件系統的用戶封裝了實現VFS的通用操作。有關利用VFS實現交互的方法看參考資料。
E: 使用內存映像
Linux通過內存映像機制來提供用戶程序對內存直接訪問的能力。內存映像的意思是把內核中特定部分的內存空間映射到用戶級程序的內存空間去。也就是說，用戶空間和內核空間共享一塊相同的內存。這樣做的直觀效果顯而易見：內核在這塊地址內存儲變更的任何數據，用戶可以立即發現和使用，根本無須數據拷貝。而在使用系統調用交互信息時，在整個操作過程中必須有一步數據拷貝的工作——或者是把內核數據拷貝到用戶緩沖區，或只是把用戶數據拷貝到內核緩沖區——這對於許多數據傳輸量大、時間要求高的應用，這無疑是致命的一擊：許多應用根本就無法忍受數據拷貝所耗費的時間和資源。
我們曾經為一塊高速采樣設備開發過驅動程序，該設備要求在20兆采樣率下以1KHz的重復頻率進行16位實時采樣，每毫秒需要采樣、DMA和處理的數據量驚人，如果要使用數據拷貝的方法，根本無法達成要求。此時，內存映像成為唯一的選擇：我們在內存中保留了一塊空間，將其配置成環形隊列供采樣設備DMA輸出數據。再把這塊內存空間映射到在用戶空間運行的數據處理程序上，於是，采樣設備剛剛得到並傳送到主機上的數據，馬上就可以被用戶空間的程序處理。
實際上，內存影射方式通常也正是應用在那些內核和用戶空間需要快速大量交互數據的情況下，特別是那些對實時性要求較強的應用。X window系統的服務器的虛擬內存區域，就可以被看做是內存映像用法的一個典型例子：X服務器需要對視頻內存進行大量的數據交換，相對於lseek/write來說，將圖形顯示內存直接影射到用戶空間可以顯著提高效能。
並不是任何類型的應用都適合mmap，比如像串口和鼠標這些基於流數據的字符設備，mmap就沒有太大的用武之地。並且，這種共享內存的方式存在不好同步的問題。由於沒有專門的同步機制可以讓用戶程序和內核程序共享，所以在讀取和寫入數據時要有非常謹慎的設計以保證不會產生干繞。
mmap完全是基於共享內存的觀念了，也正因為此，它能提供額外的便利，但也特別難以控制。
內核主動發起的信息交互
從內核空間調用用戶程序
即使在內核中，我們有時也需要執行一些在用戶級才提供的操作：如打開某個文件以讀取特定數據，執行某個用戶程序從而完成某個功能。因為許多數據和功能在用戶空間是現有的或者已經被實現了，那么沒有必要耗費大量的資源去重復。此外，內核在設計時，為了擁有更好的彈性或者性能以支持未知但有可能發生的變化，本身就要求使用用戶空間的資源來配合完成任務。比如內核中動態加載模塊的部分需要調用kmod。但在編譯kmod的時候不可能把所有的內核模塊都訂下來（要是這樣的話動態加載模塊就沒有存在意義了），所以它不可能知道在它以后才出現的那些模塊的位置和加載方法。因此，模塊的動態加載就采用了如下策略：加載任務實際上由位於用戶空間的modprobe程序幫助完成——最簡單的情形是modprobe用內核傳過來的模塊名字作為參數調用insmod。用這種方法來加載所需要的模塊。
內核中啟動用戶程序還是要通過execve這個系統調用原形，只是此時的調用發生在內核空間，而一般的系統調用則在用戶空間進行。如果系統調用帶參數，那將會碰到一個問題：因為在系統調用的具體實現代碼中要檢查參數合法性，該檢查要求所有的參數必須位於用戶空間——地址處於0x0000000——0xC0000000之間，所以如果我們從內核傳遞參數（地址大於0xC0000000）,那么檢查就會拒絕我們的調用請求。為了解決這個問題，我們可以利用set_fs宏來修改檢查策略，使得允許參數地址為內核地址。這樣內核就可以直接使用該系統調用了。
例如：在kmod通過調用execve來執行modprobe的代碼前需要有set_fs(KERNEL_DS):
......
set_fs(KERNEL_DS);
/* Go, go, go... */
if (execve(program_path, argv, envp) < 0)
return -errno;
上述代碼中program_path 為"/sbin/modprobe"，argv為{ modprobe_path, "-s", "-k", "--", (char*)module_name, NULL }，envp為{ "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }。
從內核中打開文件同樣使用帶參數的open系統調用，所需的仍是要先調用set_fs宏。
B 利用brk系統調用來導出內核數據
內核和用戶空間傳遞數據主要是用get_user(ptr)和put_user(datum,ptr)例程。所以在大部分需要傳遞數據的系統調用中都可以找到它們的身影。可是，如果我們不是通過用戶程序發起的系統調用——也就是說，沒有明確的提供用戶空間內的緩沖區位置——的情況下，如何向用戶空間傳遞內核數據呢？
顯然，我們不能再直接使用put_user()了，因為我們沒有辦法給它指定目的緩沖區。所以，我們要借用brk系統調用和當前進程空間：brk用於給進程設置堆空間的大小。每個進程擁有一個獨立的堆空間，malloc等動態內存分配函數其實就是進程的堆空間中獲取內存的。我們將利用brk在當前進程(current process)的堆空間上擴展一塊新的臨時緩沖區，再用put_user將內核數據導出到這個確定的用戶空間去。
還記得剛才我們在內核中調用用戶程序的過程嗎？在那里，我們有一個跳過參數檢查的操作，現在有了這種方法，可以另辟蹊徑了：我們在當前進程的堆上擴展一塊空間，把系統調用要用到的參數通過put_user()拷貝到新擴展得到的用戶空間里，然后在調用execve的時候以這個新開辟空間地址作為參數，於是，參數檢查的障礙不復存在了。
char * program_path = "/bin/ls" ;
/* 找到當前堆頂的位置*/
mmm=current->mm->brk;
/* 用brk在堆頂上原擴展出一塊256字節的新緩沖區*/
ret = brk(*(void)(mmm+256));
/* 把execve需要用到的參數拷貝到新緩沖區上去*/
put_user((void*)2,program_path,strlen(program_path)+1);
/* 成功執行/bin/ls程序！*/
execve((char*)(mmm+2));
/* 恢復現場*/
tmp = brk((void*)mmm);
這種方法沒有一般性（具體的說，這種方法有負面效應嗎），只能作為一種技巧，但我們不難發現：如果你熟悉內核結構，就可以做到很多意想不到的事情！
C: 使用信號：
信號在內核里的用途主要集中在通知用戶程序出現重大錯誤，強行殺死當前進程，這時內核通過發送SIGKILL信號通知進程終止，內核發送信號使用send_sign(pid,sig)例程，可以看到信號發送必須要事先知道進程序號（pid），所以要想從內核中通過發信號的方式異步通知用戶進程執行某項任務，那么必須事先知道用戶進程的進程號才可。而內核運行時搜索到特定進程的進程號是個費事的工作，可能要遍歷整個進程控制塊鏈表。所以用信號通知特定用戶進程的方法很糟糕，一般在內核不會使用。內核中使用信號的情形只出現在通知當前進程（可以從current變量中方便獲得pid）做某些通用操作，如終止操作等。因此對內核開發者該方法用處不大。類似情況還有消息操作。這里不羅嗦了。
總結 由用戶級程序主動發起的信息交互，無論是采用標准的調用方式還是透過驅動程序界面，一般都要用到系統調用。而由內核主動發起信息交互的情況不多。也沒有標准的界面，操作大不方便。所以一般情況下，盡可能用本文描述的前幾種方法進行信息交互。畢竟，在設計的根源上，相對於客戶級程序，內核就被定義為一個被動的服務提供者。因此，我們自己的開發也應該盡量遵循這種設計原則。