從上面列出的三個因素中只有第一個是真正正確的。至於其餘 - 不是真的。用戶空間代碼可以執行DMA操作 - 沒有問題。有很多硬件家電公司在他們的產品中使用這種技術。即使所有I/O都使用完整的內核旁路完成,也可以有一箇中斷驅動的用戶空間應用程序。當然,僅僅在/dev/mem
上做一個mmap()
並不容易。
您必須在內核中擁有驅動程序的最小部分 - 這是爲了爲您的用戶空間提供內核所需的最低限度所需的內存所需的(因爲如果您仔細考慮它 - /dev/mem
也是由字符設備驅動程序備份)。
對於DMA,實際上它太容易了 - 您只需處理mmap
請求並將DMA緩衝區映射到用戶空間。對於中斷 - 這有點棘手,中斷必須由內核來處理,不管怎樣,內核可能不會做任何工作,只需喚醒調用進程即epoll_wait()
即可。另一種方法是像DOSEMU一樣向流程發送信號,但這非常緩慢並且不被推薦。
至於你的實際問題,你應該考慮的一個因素是資源共享。只要您不必在多個應用程序之間共享設備,並且您在用戶空間中無法做到的任何事情 - 請進入用戶空間。由於編寫用戶空間代碼非常簡單,您可能會在開發週期中節省大量時間。但是,當兩個或更多的應用程序需要共享設備(或其資源)時,那麼您可能會花費大量時間使其成爲可能 - 只需設想多個進程分叉,崩潰,同時映射(相同)內存等等畢竟,IPC通常是通過內核完成的,所以如果應用程序需要開始相互「交談」,性能可能會大大降低。儘管如此,對於某些性能至關重要的應用,這仍然是在現實生活中完成的,但我不想詳細說明這些細節。
另一個因素是內核基礎架構。假設你想寫一個網絡設備驅動程序。在用戶空間中這不是問題。但是,如果你這樣做了,那麼你需要編寫一個完整的網絡堆棧,因爲用戶不能使用Linux內核中的默認網絡堆棧。
如果可能的話,我會說去用戶空間,並努力使事情的工作量少於編寫內核驅動程序,並記住總有一天可能需要將代碼移入內核。實際上,根據是否定義了一些宏,爲用戶空間和內核空間編譯相同的代碼是一種常見的做法,因爲用戶空間中的測試更加令人愉快。
安全性:用戶可以打開/讀取/寫入設備的設備節點控制的文件權限。文件操作拒絕或允許併發操作。 – sawdust 2013-03-08 06:47:41
這個決定可能很大程度上取決於你在PWM中是什麼,並且使用什麼硬件。 – 2013-03-12 16:55:07