2013-03-08 168 views
24

我正在尋找一個PWM驅動程序。我知道有兩種方法可以控制硬件驅動程序:用戶空間vs內核空間驅動程序

  1. 用戶空間驅動程序。
  2. 內核空間的驅動程序

如果在一般(不考慮PWM驅動器的情況下),我們必須作出決定是否去用戶空間或內核空間的驅動程序。那麼除了這些之外,我們還需要考慮哪些因素?

  1. 用戶空間驅動程序可以直接將mmap()/ dev/mem內存映射到其虛擬地址空間,不需要上下文切換。
  2. 用戶空間驅動程序不能實現中斷處理程序(它們必須輪詢中斷)。
  3. 用戶空間驅動程序無法執行DMA(因爲可從內核空間分配DMA的內存)。
+1

安全性:用戶可以打開/讀取/寫入設備的設備節點控制的文件權限。文件操作拒絕或允許併發操作。 – sawdust 2013-03-08 06:47:41

+1

這個決定可能很大程度上取決於你在PWM中是什麼,並且使用什麼硬件。 – 2013-03-12 16:55:07

回答

31

從上面列出的三個因素中只有第一個是真正正確的。至於其餘 - 不是真的。用戶空間代碼可以執行DMA操作 - 沒有問題。有很多硬件家電公司在他們的產品中使用這種技術。即使所有I/O都使用完整的內核旁路完成,也可以有一箇中斷驅動的用戶空間應用程序。當然,僅僅在/dev/mem上做一個mmap()並不容易。

您必須在內核中擁有驅動程序的最小部分 - 這是爲了爲您的用戶空間提供內核所需的最低限度所需的內存所需的(因爲如果您仔細考慮它 - /dev/mem也是由字符設備驅動程序備份)。

對於DMA,實際上它太容易了 - 您只需處理mmap請求並將DMA緩衝區映射到用戶空間。對於中斷 - 這有點棘手,中斷必須由內核來處理,不管怎樣,內核可能不會做任何工作,只需喚醒調用進程即epoll_wait()即可。另一種方法是像DOSEMU一樣向流程發送信號,但這非常緩慢並且不被推薦。

至於你的實際問題,你應該考慮的一個因素是資源共享。只要您不必在多個應用程序之間共享設備,並且您在用戶空間中無法做到的任何事情 - 請進入用戶空間。由於編寫用戶空間代碼非常簡單,您可能會在開發週期中節省大量時間。但是,當兩個或更多的應用程序需要共享設備(或其資源)時,那麼您可能會花費大量時間使其成爲可能 - 只需設想多個進程分叉,崩潰,同時映射(相同)內存等等畢竟,IPC通常是通過內核完成的,所以如果應用程序需要開始相互「交談」,性能可能會大大降低。儘管如此,對於某些性能至關重要的應用,這仍然是在現實生活中完成的,但我不想詳細說明這些細節。

另一個因素是內核基礎架構。假設你想寫一個網絡設備驅動程序。在用戶空間中這不是​​問題。但是,如果你這樣做了,那麼你需要編寫一個完整的網絡堆棧,因爲用戶不能使用Linux內核中的默認網絡堆棧。

如果可能的話,我會說去用戶空間,並努力使事情的工作量少於編寫內核驅動程序,並記住總有一天可能需要將代碼移入內核。實際上,根據是否定義了一些宏,爲用戶空間和內核空間編譯相同的代碼是一種常見的做法,因爲用戶空間中的測試更加令人愉快。

+0

很好的回答。我正在尋找這些信息,你的回答非常有幫助。 – 2013-09-12 16:47:10

+0

然而,epoll有一個快速的機制,最後它是一個輪詢結構而不是中斷處理程序。它可能會導致時間關鍵型操作問題。 – obayhan 2016-11-30 09:24:17

6

另一個考慮:調試用戶空間驅動程序要容易得多。您可以使用GDB,Valgrind的,等等哎呀,你甚至不用寫你的驅動器C.

有不僅僅是用戶空間或內核空間的驅動程序第三種選擇:一些兩者。你可以在內核驅動程序中只執行內核空間的東西,並在用戶空間中執行其他任何操作。如果您使用Linux UIO驅動程序框架,則可能甚至不必編寫內核空間驅動程序(請參閱https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html)。

我已經有幸在用戶空間中幾乎完全寫了一個支持DMA的驅動程序。 UIO提供基礎設施,因此您可以在文件上讀取/選擇/ epoll以等待中斷。

您應該認識到從用戶空間編程DMA描述符所帶來的安全隱患:除非您在設備本身或IOMMU中擁有某種保護,否則用戶空間驅動程序可以使設備讀取或寫入任何地址在物理內存中。

相關問題