static int
first_drv_open
(struct inode *inode, struct file *file)
static int
first_drv_read(struct file *filp, char __user *buff,
size_t count, loff_t *offp)
static ssize_t
first_drv_write(struct file *file, const char __user *buf, size_t count, loff_t * ppos)
將上面的函式告訴核心
a.需要定義乙個結構體：
static struct
file_operations
first_drv_fops= ;
b. 註冊，告訴核心
register_chrdev( major, "first_drv",
first_drv_fops
); //主裝置號，名字，結構體名字
c.通過入口函式呼叫
register_chrdev，通過出口函式呼叫unregister_chrdev
int first_drv_init(void)
void first_drv_exit(void)
d.修飾入口函式/出口函式
module_init(
first_drv_init
); //定義乙個結構體，呼叫其中函式指標
指向入口函式
first_drv_init
module_exit(first_drv_exit);
下面是應用程式和驅動之間通過主裝置號，file_optation結構體連線起來的示意圖
kern_dir = /work/system/linux-2.6.22.6//編譯使用的核心路徑，核心要編譯完成才可用
all:
make -c $(kern_dir) m=`pwd` modules //-c會轉到
kern_dir目錄中去，用目錄中的makefile編譯。m=當前路徑是什麼。
modules是目標
clean:
make -c $(kern_dir) m=`pwd` modules clean
rm -rf modules.order
obj-m
+= myleds.o
2 6字元裝置驅動
chardev.c include include for file f op include include for copy to user include for cdev cdev init,cdev add module license gpl module author helight ...
字元裝置驅動3 字元類裝置驅動框架分析
前面的博文循規蹈矩按照無驅動框架的步驟分析了乙個簡單的字元裝置驅動，但是現如今更多是使用核心開發者提供的驅動框架來完成驅動的註冊，這樣的做法即可減少 的錯誤率，也能避免錯誤例如記憶體申請忘記釋放的問題，更能簡化驅動的開發難度，這裡就以乙個簡答的led類裝置驅動架構為例，分析字元裝置驅動框架 驅動框架...
驅動實驗（1）字元裝置驅動實驗
練習字元裝置驅動的兩種模板之後，編寫乙個字元驅動程式 chartest虛擬裝置 由驅動程式4管理，所指向的裝置是64號裝置，類似於串列埠終端或者字元裝置終端 include include include include include include define chrdevbase major...