從檔案系統看系統架構

struct vop_vector {

struct vop_vector *vop_default; //定義乙個預設的操作結構，注意型別也是vop_vector

int (*vop_bypass)(struct vop_generic_args *ap);

int (*vop_open)(struct vop_open_args);

int (*vop_access)(struct vop_access_args);

int (*vop_read)(struct vop_read_args);

struct vop_generic_args { //bsd將引數也給封裝了，這個是引數的「基類」

struct vnodeop_desc *a_desc;

struct vnodeop_desc { //操作描述結構

char *vdesc_name;

int vdesc_flags;

vop_bypass_t *vdesc_call; //bypass中具體要呼叫的函式

struct vnodeop_desc vop_read_desc {

"vop_read",

0,(vop_bypass_t *)vop_read_ap,//往下傳遞了吧，竟然呼叫的也是vop_read_ap

static __inline int vop_read(struct vnode *vp, struct uio *uio, int ioflag, struct uccred *cred)

struct vop_read_args a;

a.a_gen.a_desc = &vop_read_desc;

a.a_vp = vp;

a.a_uio = uio;

a.a_ioflag = ioflag;

a.a_cred = cred;

return (vop_read_apv(vp->v_op,&a));

int vop_read_apv(vop_vector *vop, struct vop_read_args *a)

...//如果找不到就呼叫default裡面的例程

while(vop != null && vop->vop_read == null && vop->vop_bypass == null)

vop = vop->vop_default;

if(vop->vop_read != null)

rc = vop->vop_read(a);

else

rc = vop->vop_bypass(&a->a_gen);//呼叫bypass，給了程式存放鉤子的地點

以上**一目了然，不用多說什麼，乙個系統呼叫發出以後，路經是：pread->preadv->dofileread->fo_ops->fo_read->vn_read->vop_read->vop_read_apv->vop->vop_read->nfs->read

其中dofileread，fo_ops->fo_read，vop_read是常用的幾個多路復用的地點，實際上，有了引數封裝，指標通訊機制，任何地方都是多路復用點。bsd實現了這套機制真是方便了開發驅動的人。

很早以前聽有人說c語言實現不了物件導向，看看linux和unix的**吧，之後再重新審視物件導向的意義何在。從檔案系統的實現裡面我們可以看出，bsd為何要這麼做，這是基於當時歷史背景考慮的，因為在當時很多檔案系統都不成熟，彼此的依賴性很大，所以很顯然要彼此呼叫來完成自己沒有實現的功能，但是linux就不一樣了，時機成熟了。再者linux根本沒有乙個統一的規劃，因此才會出現那種很「野」的局面，但是這些鬆散的小物件卻奇蹟般的超越了一切。看來linux沒有必要學習bsd或windows的那一套，也不可能學會，那必須要很多人經過正規的過程討論，最後開始在統一管理下進行設計，開發，而linux沒有那種環境，因此，linux就是linux，bsd就是bsd，windows就是windows，學了別人它就不純了，所以評價一款作業系統的好壞不要一味的從一方面比如使用者習慣啊等等去談，而應該考慮到它自身的一切東西。

最好就是不要評價，要從比較當中學習各家的長處，而不要一味指責這個或那個。

注：我剛買了一本《**之美》，感覺特棒，看了好幾章，上文就是一篇讀後感吧。

從檔案系統看系統架構

從人事檔案系統看需求

檔案系統檔案系統的架構

重新看檔案系統

從檔案系統看系統架構

從人事檔案系統看需求

檔案系統 檔案系統的架構

重新看檔案系統

相關推薦

檔案系統檔案系統的架構