從檔案到字元裝置

在/dev下面有很多裝置,其中也有大家廣為使用的字元裝置,呢裡面的檔案是如何與字元裝置掛鉤的呢~  平時我們使用的open函式是如何動態載入字元裝置的操作集的呢~

下面就讓我們慢慢剖析~ (以核心2.6.26為參考) 一.

首先是檔案系統~   需要動態解析檔案路徑名  像/dev/ts0  在檔案系統裡分為3個部分  1./(根檔案目錄)  2.dev(根檔案目錄下的dev目錄)  3.ts0(dev目錄下的ts0檔案)

我們使用open(「/dev/ts0」,」開啟方式」)之後~  就進入了系統呼叫sys_open之中~,如下圖左a所示~  呼叫一直深入到do_file_open中後開始真正的路徑解析

現在只簡單的講述一下~  path_look_open這個函式用於路徑解析與nameidata結構的賦值   nameidata_to_filp這個函式用於nameidata轉換為file結構

在這些步驟裡~  我只點出幾步比較重要的賦值~

a.首先是path_lookup_open函式

1.在real_lookup中(/fs/namei.c): 

520     result = dir->i_op->lookup(dir,dentry,nd);  //這一步是根據檔案所在的檔案系統呼叫相應的lookup函式~  我使用的檔案系統為ext3~  則呼叫ext3_lookup

2.在ext3_iget中(/fs/ext3/inode.c):

檢測檔案標識inode->i_mode~  不為普通檔案,目錄及鏈結檔案則判定為字元檔案,接著呼叫init_special_inode函式

3.在init_special_inode中(/fs/inode.c):

繼續判斷檔案識別符號,我們關心的是判斷為字元檔案這一段

1427    inode->i_fop   =  &def_chr_fops;

1428    inode->i_rdev  =  rdev;

這裡賦了操作集與裝置號,為後面的裝置查詢判斷埋下伏筆

b.現在path_lookup_open函式呼叫完成~ 進入到nameidata_to_filp函式中

1.        在__dentry_open中(/fs/open.c):

825           f->f_op = fops_get(inode->i_fop); //在這裡進行賦值,f->f_op = &def_chr_fops,注意上文inode->i_fop中的賦值

832           if(!open && f->f_op)        //在呼叫__dentry_open時open賦值為空,所以!open為真 

833                    open = f->f_op->open;    //在這裡將open賦為chrdev_open

835           error = open(inode,f);         //這裡呼叫chrdev_open

2.        在chrdev_open中(/fs/char_dev.v):

371                        kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);     //執行kobj_lookup函式,在cdev_map裡尋找相應的inode->i_rdev裝置

cdev_map是乙個256個probe結構組成的陣列,用於查詢具有相應裝置號的裝置,如何查詢這個結構,將在後面的文章中詳細介紹

inode->i_rdev為裝置號  在前面已經提示了  

374                new = container_of(kobj, struct cdev, kobj);                //從kobj的位置倒算出cdev的記憶體位址.獲得包含相應kobj的cdev

378     inode->i_cdev = p = new;                              //到這裡p已經為我們要的裝置cdev了

390                filp->f_op = fops_get(p->ops);                         //終於拿到了夢寐以求的cdev操作集,至此~  以後read,write操作都通過file->f_op直接與我們要的裝置操作集掛鉤了

二現在詳細講述cdev_map這個重要的結構

cdev_map是管理linux中字元裝置的陣列,它的描述為static struct kobj_map *cdev_map;

而kobj_map的相關**在/drivers/base/map.c裡

struct kobj_map *probes[255];

struct mutex *lock;

};這就是kobj_map的結構

下面來看一下操作函式,首先是初始化函式kobj_map_init,這個函式在chrdev_init中呼叫(/fs/char_dev.c)

cdev_map = kobj_map_init(base_probe, &chrdevs_lock);   //初始化cdev_map

struct kobj_map *kobj_map_init(kobj_probe_t *base_probe, struct mutex *lock)

//檢測分配是否成功

base->dev = 1; 

base->range = ~0;   //~0為4294967295

base->get = base_probe;   //以上三項初始化probe

for (i = 0; i < 255; i++)

p->probes = base;    //將kobj_map中的256項probe均指向base

p->lock = lock;

return p;

}初始完後的陣列如下圖

然後是分配函式kobj_map,該函式負責插入乙個包含私有資料的probe到陣列裡

在新增字元裝置的時候cdev_add負責呼叫此函式

int cdev_add(struct cdev *p, dev_t dev, unsigned count)

其中比較重要的是exact_match這個函式,他用於提取私有資料中的kobj

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)

//初始化取得的probe結構

mutex_lock(domain->lock);

for (i = 0, p -= n; i < n; i++, p++, index++)

mutex_unlock(domain->lock);

return 0;

}插入乙個probe後的陣列如下圖

關於kobj_map的題外話,在插入中我們可以看到,**並不對裝置號進行檢測,也就說有可能有兩個完全一樣的裝置號裝置,如下圖

linux並沒有這樣的檢測機制~  只能全憑人工分配裝置號的時候進行仔細的檢查,也可能是我沒發現其中的檢測機制,望大家指出,萬分感謝

現在到了大家最關心的,如何使用裝置號查詢對應的裝置呢?

這個函式是kobj_lookup,它負責進行查詢

struct kobject *kobj_lookup(struct kobj_map *domain, dev_t dev, int *index)

mutex_unlock(domain->lock);

kobj = probe(dev, index, data);  //提取私有資料中的kobj

/* currently ->owner protects _only_ ->probe() itself. */

module_put(owner);

if (kobj)   

return kobj;     //返回kobj

goto retry;

}mutex_unlock(domain->lock);

return null;}

從檔案到字元裝置

在 dev下面有很多裝置,其中也有大家廣為使用的字元裝置,呢裡面的檔案是如何與字元裝置掛鉤的呢 平時我們使用的open函式是如何動態載入字元裝置的操作集的呢 下面就讓我們慢慢剖析 以核心2.6.26為參考 一.首先是檔案系統 需要動態解析檔案路徑名 像 dev ts0 在檔案系統裡分為3個部分 1....

從檔案到字元裝置

從檔案到字元裝置 在 dev下面有很多裝置,其中也有大家廣為使用的字元裝置,呢裡面的檔案是如何與字元裝置掛鉤的呢 平時我們使用的open函式是如何動態載入字元裝置的操作集的呢 下面就讓我們慢慢剖析 以核心2.6.26為參考 一.首先是檔案系統 需要動態解析檔案路徑名 像 dev ts0 在檔案系統裡...

作業系統 再識 Linux從檔案到字元裝置

在 dev下面有很多裝置,其中也有大家廣為使用的字元裝置,呢裡面的檔案是如何與字元裝置掛鉤的呢 平時我們使用的open函式是如何動態載入字元裝置的操作集的呢 下面就讓我們慢慢剖析 以核心2.6.26為參考 一.首先是檔案系統 需要動態解析檔案路徑名 像 dev ts0 在檔案系統裡分為3個部分 1....