今天我一切按老師的步驟走著，開始的程式是自己寫的。make後也形成了相應的first_drv.ko檔案，然後將這個檔案拷到first_fs中。同樣我的板子上電後就直接掛載到nfs指定的檔案系統。到這裡一切還很正常。所以我很自信的輸入了insmod first_drv.ko 但是當我用cat /proc/devices 檢視時，卻怎麼也找不到相應的first_drv的字元裝置。
這個時候我開始懷疑是不是自己的**寫錯了，所以我將自己的**跟老師的**比對了好幾遍，都沒有發現有什麼不一樣的地方。所以我決定用老師的**試試。相同的操作下來，我發現輸入insmod first_drv.ko 但用cat /proc/devices 檢視時還是找不到相應的first_drv的字元裝置。這個時候我知道我的**沒有問題。那這是**出了問題啊。
我第乙個想到的是根檔案系統出了問題，但是我用linux系統向單板發檔案正常，這說明nfs掛接沒有問題。
那是什麼問題那？？
我去網上查了一下，各種說法都有，還有很多人出過相同的錯誤，但他們大多是**出現錯誤。而在乙個求助帖子中我無意間看到乙個網友說可能是核心版本號不一樣。我立馬看了一下我的核心版本。發現是一樣的。但我也反應過來，確實可能是由於核心沒有編譯好。因為對應於老師的驅動要使用他提供的核心。所以我就按著老師的指示從新編寫了一次核心。結果這次居然真的可以了。
所以，通過今天的事，我想建議各位學習的同學。驅動是在核心上跑的，所以乙個正確完好的核心很重要。
將自己寫的驅動新增到核心中
主要以自己寫的leds s5pv210.c為例 具體步驟 1 將leds s5pv210.c加入到driver leds中，但是直接放進去並不會進行編譯。2 在driver leds中的makefile中新增相應的依賴 obj config leds s5pv210 leds s5pv210.o3 ...
使用usbfs與核心驅動之間的衝突
usb驅動分為通過usbfs操作裝置的使用者空間驅動，核心空間的核心驅動。兩者不能同時進行，否則容易引發對共享資源訪問的問題，死鎖！使用了核心驅動，就不能在usbfs裡驅動該裝置。libusb中須要先detach核心驅動後，才能claim inte ce，否則claim會返回的vice busy的錯...
編譯驅動模組時遇見的問題記錄
1 寫驅動程式，編譯驅動模組時，出現 make 1 entering directory usr src linux headers 2.6.32 5 amd64 usr src linux headers 2.6.32 5 common arch x86 makefile 81 stack pro...