真是蠻複雜的，我分三步走，力求講得比較清楚。
以字元裝置為例，相對於塊裝置要簡單些。
基於2.6.26的核心
一）驅動註冊open函式都幹了些什麼？
register_chrdev -> cdev_add -> kobj_map
file: fs/char_dev.c
int register_chrdev(unsigned int major, const char *name,
const struct file_operations *fops)
file: fs/char_dev.c
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
file: fs/char_dev.c
static struct kobject *exact_match(dev_t dev, int *part, void *data)
file: drivers/base/map.c
int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
struct module *module, kobj_probe_t *probe,
int (*lock)(dev_t, void *), void *data)
mutex_lock(domain->lock);
for (i = 0, p -= n; i < n; i++, p++, index++)
mutex_unlock(domain->lock);
return 0;
}二）從系統呼叫往核心走，看當初驅動裡註冊的file_operations裡的open函式怎麼被呼叫的
這個跟具體的檔案系統有關係的。
現在/dev/下的裝置節點都是通過udev動態建立的，udev會去呼叫mknod（假定是ext2，核心會呼叫ext2_mknod），
如果是char裝置，會把def_chr_fops附給inode->i_fop，而ext2_mknod會呼叫init_special_inode()，函式
的部分實現如下：
file: fs/ext2/namei.c
static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, dev_t rdev)
...}
file: fs/char_dev.c
const struct file_operations def_chr_fops = ;
系統呼叫Open 函式的核心追蹤 上篇
from open函式相信大家都用過，這裡就不多說它的使用方法等事項，現直接進入正題.使用者態程式呼叫open函式時，會產生乙個中斷號為5的中斷請求，其值以該巨集 nr open進行標示.而後該程序上下文 processcontext 將會被切換到核心空間。待核心中的相關操作完成後，就會從核心返回，...
二。向核心中新增系統呼叫
核心版本 3.4.24 大家發現什麼問題一定要告訴我，大家一起學習啦 向核心中新增系統呼叫 1.系統呼叫是和平台相關的 arm平台的系統呼叫的彙編 路徑 vim 從333行開始 2.新增系統呼叫的步驟 存著系統呼叫表，系統呼叫的函式入口就是這 系統呼叫號就是基於基位址的配偏移位址 vim linux...
open 系統呼叫的實現
open系統呼叫的服務例程是sys open 函式，它接受三個引數 要開啟檔案的路徑名filename,訪問模式的表示flags和檔案許可權掩碼mode。在核心中，sys open實際呼叫do sys open函式來完成所有操作。do sys open主要執行如下操作 1，通過getname 從程序...