前言
最近做的事情很多地方用到Linux驅動層與應用層的通信，在此總結下常見的並且在我工作中用到的通信方法。
總結
由於每種方法都可以找到大量的示例代碼，同時還有詳細的函數手冊，我就不貼代碼了。只列下相關的方法和一個鏈接。
procfs
netlink
syscall
IOCTL
syscall的范圍就廣了，通過注冊字符設備可以使用mmap和ioctl等來進行操作，要注意的是在內核態ioctl已經被廢棄，現在應該使用unlocked_ioctl，需要自己來加鎖。
用戶態通過系統暴露出來的系統調用來進行操作，如mmap，ioctl，open，close，read，write，內核態通過建立共享內存remap_pfn_range或者copy_to_user, copy_from_user來進行操作。
選擇哪種方式需要考慮是用戶態單進程與內核態通信還是多進程的通信，還要考慮通信的數據量。根據不同的需求來使用不同的方法。
PROCFS
/proc目錄是系統模擬出來的一個文件系統，本身並不存在於磁盤上，其中的文件都表示內核參數的信息，這些信息分兩類，一類是可都可寫的，這類參數都在“/proc/sys”目錄下，另一類是只讀的，就是“/proc/sys”目錄之外的其他目錄和文件，當然這只是一種慣例，實際在其他目錄下建立可讀寫的/proc文件也是可以的。
/proc文件系統是一個特殊的軟件創建的文件系統, 內核用來輸出消息到外界. /proc 下的每個文件都綁到一個內核函數上, 當文件被讀的時候即時產生文件內容. 我們已經見到一些這樣的文件起作用; 例如, /proc/modules, 常常返回當前已加載的模塊列表.
/proc 在 Linux 系統中非常多地應用. 很多現代 Linux 發布中的工具, 例如 ps, top, 以及 uptime, 從 /proc 中獲取它們的信息. 一些設備驅動也通過 /proc 輸出信息.
在 /proc 下添加文件是不鼓勵的. /proc 文件系統在內核開發者看作是有點無法控制的混亂, 它已經遠離它的本來目的了(是提供關於系統中運行的進程的信息). 建議新代碼中使信息可獲取的方法是利用 sysfs. 如同建議的, 使用 sysfs 需要對 Linux 設備模型的理解.
內核和用戶空間進行通信，大概有如下幾種方式可以考慮：
采用內存映射的方式，將內核地址映射到用戶態。這種方式最直接，可以適用大量的數據傳輸機制。這種方式的缺點是很難進行“業務控制”，沒有一種可靠的機制保障內核和用戶態的調動同步，比如信號量等都不能跨內核、用戶層使用。因此內存映射機制一般需要配合一種“消息機制”來控制數據的讀取，比如采用“消息”類型的短數據通道來完成一個可靠的數據讀取功能。
ioctl機制，ioctl機制可以在驅動中擴展特定的ioctl消息，用於將一些狀態從內核反應到用戶態。Ioctl有很好的數據同步保護機制，不要擔心內核和用戶層的數據訪問沖突，但是ioctl不適合傳輸大量的數據，通過和內存映射結合可以很好的完成大量數據交換過程。但是，ioctl的發起方一定是在用戶態，因此如果需要內核態主動發起一個通知消息給用戶層，則非常的麻煩。可能需要用戶態程序采用輪詢機制不停的ioctl。
其他一些方式比如系統調用必須通過用戶態發起，proc方式不太可靠和實時，用於調試信息的輸出還是非常合適的。
通過前面的項目背景，我需要一種可以在內核態主動發起消息的通知方式，而用戶態的程序最好可以采用一種“阻塞調用”的方式等待消息。這樣的模型可以最大限度的節省CPU的調度，同時可以滿足及時處理的要求，最終選擇了netlink完成通信的過程。
