Linux Driver 思考

剛突然找一篇很不錯的文章,雖然字數很少,但裡面的內容讓我有種被啟發的感覺...

====================

傳統意義上的Linux Driver僅僅是設備驅動，簡言之，和設備有關，如LCD，Camera等等。 但是， 筆者認為，Linux Driver的作用不僅僅侷限於此，從廣義上講， Linux Driver提供了一種User Space訪問 Kernel中特定Function的通用編程模型，即，平民（User Space中的Application， Process， Lib等）通向皇宮（Kernel）的大道。

如果一個模塊提供的Function必須運行於Kernel Space中（可能是設備相關的Function，從而需要訪問特權指令或者特權地址空間； 抑或者Function本身是設備無關的，但是訪問到了其他的一些運行於Kernel的Function； 甚至於吃飽了沒事幹，就喜歡把原本可以在User Space中運行的API實現在Kernel中，就是喜歡，你管的著嗎？！）。 同時，又希望User Space中的Client能訪問使用這些Function， 那麼， 將其Adapt成Driver是再合理不過的解決方案了。 這是為什麼那？？

因為，從理論上來說，Kernel中的API，User Space中的Client是無法直接訪問的，只能利用系統調用陷入到內核態後調用。 Linux的系統調用非常多，均已經固定， 如何支持新的Kernel Function的調用那？ 有兩種方式：

1。 在Kernel中實現一個新的系統調用（添加新的系統調用號），用來支持你實現的新功能。 這真是殺雞用牛刀的幹活，吃力不討好。 你需要全全負責User Space到Kernel Space的切換，系統調用號的傳遞，系統調用上下文的保存， 調用後的系統上下文的恢復，Kernel Space向User Space的切換。

2。 復用一個現有的系統函數/調用，來支持你的新功能。 具有抽象意義的系統調用莫過於read，write，open這些為Driver定製的API了。 所以，我們可以簡單的將我們的Function Wrapper成Driver需要的open，read，write等，然後，再按照Driver的要求，將我們的Module Wrapper成一個Driver的設備文件並註冊到系統中。 這樣，User Space中的Client，可以採用傳統的Driver的模式來間接訪問到我們新加的這些Function，並且，可能這些Function根本和實際的設備沒有任何聯繫。

所以，我們不應該把Linux的Driver狹義的理解為設備驅動， 其實，它是一種通用的User Space訪問Kernel Space Function的編程模式。 只要你有這種需求，你就可以實現為Driver，而不需要關心和實現複雜的系統調用過程。 比如Android中的Binder Driver， 根本不是真正的和物理設備打交道， 而僅僅是一個運行於Kernel的Binder Function，但是適配成了Driver，方便User Space中的Client調用。