如果你可以在用戶空間使用outb/inb，Linux字符設備驅動程序有什麼意義？

Question

我很難明白什麼時候應該編寫設備驅動程序，而不是直接通過我的用戶空間程序中的outb將操作碼發送到硬件。我最初認爲應該爲硬件創建簡單的例程，但現在我開始認爲算法應該留在用戶空間中。

假設我正在編程一個假想的機器人手臂。我可以在Linux內核模塊中編寫幾個函數來自動執行常見任務所需的硬件輸出（例如，將arm移動到HOME位置，在裝配線開始時從已知位置拾取新塊等）。然而，在閱讀了關於設備驅動程序的更多信息之後，看起來經驗法則是讓設備驅動程序儘可能接近硬件特定的代碼，而將「繁重」算法留給用戶空間。

這讓我困惑，因爲如果通過設備驅動程序實現的唯一功能是簡單的操作碼的呼叫，什麼是一個用戶空間程序使用的設備文件，而不是outb/inb直接調用的原因是什麼？

我想我想弄清楚的是：我該如何決定哪些功能在kernelspace而不是用戶空間？

Answer 1

好問題。我摔跤過 - 我甚至寫了驅動程序來控制機器人手臂，當我知道事實並非如此。我可以通過串口或outb（）等方便地發送命令，我只是爲了教育目的而編寫這些驅動程序。

設備驅動程序有很多很好的理由。想象一下，試圖從用戶空間直接控制你的網卡！首先，驅動程序在操作系統級別（eth0等）提供了很好的抽象。但是從性能角度來看，嘗試處理用戶空間中的數據包發送/接收中斷將是非常不切實際的 - 甚至可能是不可能的。只需要響應用戶空間中的中斷就可以將界面拖垮。

想象一下，你購買了一張新的網卡。加載新的驅動程序並繼續與用戶空間的eth0通信而不更改代碼會不太好？

所以，如果你沒有看到需要，我會在寫一個驅動程序時說「沒有意義」。我認爲驅動程序的存在是由需求驅動的（如NIC驅動程序示例），而不是相反。

這聽起來像你的應用程序，outb（）將比創建驅動程序更直接。最後，我甚至沒有使用我的機器人手臂驅動程序 - 只是寫入字節到串行端口也工作 - 並且只需要幾行代碼;-)

Answer 2

設備驅動程序必須只實現機制處理硬件（這與操作系統無關）。 解決方案的所有智能必須存在於用戶空間中。

是的，你可以做在用戶空間的一切，但：

• 它不重複使用;其他用戶空間程序必須重新實現的機制來訪問的機械臂（例如）

• 糟糕的表現;這取決於應用程序，也許它不是一個機械臂（慢）的問題，但它可以是一個網卡，磁盤有問題，顯卡

因此，對於機械臂，您應該在驅動器中執行機制（移動電機，從傳感器獲取信息）。所以，你的程序和其他程序可以使用驅動程序來使手臂變得聰明。聰明的東西是由用戶空間程序完成的：繪製Gioconda，準備蛋糕，小心地移動炸藥。驅動程序是實現基本功能以允許其用戶使用硬件。

但很明顯，這取決於硬件和環境。

Answer 3

如果在用戶空間使用outb和inb，那麼你的用戶空間將是x86的具體 - 用戶空間outb()和inb()宏與x86彙編實現。在另一方面，如果你寫一個內核驅動程序比你的驅動程序可在任何PCI-支持架構的工作 - 在內核中inb()和outb()功能在一個特定架構的方式來實現。內核還爲您提供了像request_region()這樣的功能，以確保您的IO端口不會與任何其他驅動程序發生衝突。

而且，你的用戶空間的驅動程序將需要以root身份運行（或技術上與CAP_SYS_RAWIO能力，這是根當量）。內核中的字符設備驅動程序意味着您可以在字符設備文件上使用UNIX權限來控制哪些用戶空間用戶可以訪問設備。