スポンサーリンク

NAMEI(9) FreeBSD カーネル開発者マニュアル NAMEI(9)

名称

namei, NDINIT, NDFREE − パス名の変換および検索操作

書式

#include <sys/param.h>
#include <sys/proc.h>
#include <sys/namei.h>

int

namei(struct nameidata *ndp);

void

       NDINIT(struct nameidata *ndp, u_long op, u_long flags,enum uio_seg segflg, const char *namep, struct thread *td);
void

NDFREE(struct nameidata *ndp, const uint flags);

解説

namei の仕組みはクライアントによるパス名の変換および検索の操作を可能にし ます。 namei 関数は対象の vnode のための参照カウントをインクリメントしま す。その参照カウントは、 LOCKLEAF フラグが指定されたかどうかに依存して、 vrele(9) または vput(9) のどちらかを使用して、その vnode の使用後にデクリ メントされなければなりません。

NDINIT() 関数は namei の要素を初期化するために使用されます。これは以下の 引数を取ります。

       ndp

初期化されるべき struct nameidata 構造体です。

op
namei
() が実行する操作です。 LOOKUP, CREATE, DELETE および RENAME の操作が有効です。後者 3 つはこれらの効果のためのセットアップだけ です。 namei() の呼び出しだけでは VOP_RENAME() が呼び出されたよう な結果にはなりません。

flags
操作フラグです。これらの内の幾つかは、同時に有効化されることが可 能です。

segflg
UIO セグメントのインジケータです。これはオブジェクトの名前がユー ザ空間 (UIO_USERSPACE) にあるのかカーネルアドレス空間 (UIO_SYSSPACE) にあるのかを示します。

namep
構成要素のパス名バッファへのポインタです (検索されるファイル名ま たはディレクトリ名)。

td
namei
の操作およびロックのために使用されるスレッドコンテキストで す。

NAMEI 操作フラグ

namei() は操作がどのような影響を及ぼすかという、以下の ‘‘操作フラグ’’ の セットを取ります。

       LOCKLEAF

戻るときに vnode をロックします。これはその vnode の完全な ロックで、ロックを解放するためには VOP_UNLOCK(9) を使用するべ きです。 (または vrele(9) が後に続く VOP_UNLOCK(9) の呼び出し を一緒に行うことと等価である vput(9) を使用するべきです。)

LOCKPARENT
このフラグは ni_vp が一致しない場合には、 namei() 関数に親 ( ディレクトリ) の vnode である ni_dvp がロックされた状態で返さ れるようにします。この場合、これ自体では ni_dvp はロックされ ません (が、 LOCKLEAF のためロックされるかもしれません)。ロッ クが実施された場合には、 vput(9) または VOP_UNLOCK(9)vrele(9) を使用してロックが解放されるべきです。

WANTPARENT
このフラグは namei() 関数が親 (ディレクトリ) の vnode をロッ クされていない状態で、返すようにします。その親の vnode は vrele(9) を使用して個別に解放されなければなりません。

NOCACHE
名前キャッシュのエントリが既に存在していない場合には、 namei() が名前キャッシュにこのエントリを作成することを回避し ます。通常、そこにエントリが未だない場合には、 namei() は名前 キャッシュにエントリを追加します。

FOLLOW
このフラグがあると、 namei() は与えられたパス名の最後の部分が シンボリックリンクであれば、シンボリックリンクを辿ります (す なわち、リンクそれ自体の vnode の代わりに、リンクが指している ところの vnode が返されます)。

NOOBJ
たとえ VM サポートのための要求された基準を満たしているとして も、返される vnode のために vfs_object_create() を呼び出しま せん。

NOFOLLOW
シンボリックリンクを辿りません (擬似フラグ)。このフラグは実際 のコードによって期待されません。コードは FOLLOW の有無をみま す。 NOFOLLOW は、シンボリックリンクが辿られないことを、ソー スコードの読者に対して意図的に示すために使用されます。

SAVENAME
呼出し側がそのパス名のバッファにアクセスするかもしれない時の ために、 namei() の実行の最後で、パス名のバッファを解放しませ ん。代わりに後で NDFREE() でその名前バッファを解放します。詳 細は下記を参照してください。

SAVESTART
親ディレクトリへの追加の参照を維持します。パス名のバッファを 解放しません。詳細は下記を参照してください。

割当てられた要素

nameidata 構造体は以下のフィールドで構成されます。

       ni_startdir

通常の場合、これは現在のディレクトリまたはルートディレク トリのどちらかです。渡された名前が ‘/’ で始まっておら ず、絶対パスのシンボリックリンクを通り抜けていない場合に は現在のディレクトリで、そうでない場合にはルートです。

この場合、 lookup() によってのみ使用され、 namei() への 呼出しの後で利用可能だとみなされるべきではありません。 SAVESTART が設定されている場合には、追加の vref(9) を伴 なった ni_dvp と同様に設定されます。 ni_startdir の解放 から NDFREE() をブロックするために、 NDF_NO_STARTDIR_RELE を設定することが可能です。

ni_dvp
検索が実行されているオブジェクトのディレクトリへの vnode ポインタです。 LOCKPARENT または WANTPARENT が設定されて いる場合に、成功して戻った時に利用可能です。 LOCKPARENT が設定されている場合にはロックされます。 NDF_NO_DVP_RELE, NDF_NO_DVP_PUT または NDF_NO_DVP_UNLOCK によって、(明らかな効果を伴って) NDFREE() 内の ni_dvp の 解放を抑制することが可能です。

ni_vp
オブジェクトが返されるための vnode ポインタで、そうでな ければ NULL です。この vnode の v_usecount フィールドが インクリメントされます。 LOCKLEAF が設定されている場合に は、ロックもされます。

NDF_NO_VP_RELE, NDF_NO_VP_PUT または NDF_NO_VP_UNLOCK に よって、(明らかな効果を伴って) NDFREE() 内の ni_vp の解 放を抑制することが可能です。

ni_cnd.cn_pnbuf
namei
操作によって使用される、ファイルまたはディレクトリ の位置が入っているパス名のバッファです。これは uma(9) ゾーン割り当てインタフェースによって管理されます。 SAVESTART または SAVENAME フラグが設定されている場合に は、そのパス名のバッファは namei() 関数の呼び出し後も利 用可能です。

パス名のバッファ ni_cnd.cn_pnbuf によって使用されている リソースのみを解放するために、 NDF_ONLY_PNBUF フラグを NDFREE() 関数に渡すことが可能です。パス名のバッファをそ のままで保持するために、 NDF_NO_FREE_PNBUF フラグを NDFREE() 関数に渡すことが可能です。

関連ファイル

       src/sys/kern/vfs_lookup.c

関連項目

uio(9), uma(9), VFS(9), vnode(9), vput(9), vref(9)

作者

このマニュアルページは Eivind Eklund ⟨eivind@FreeBSD.org⟩ によって書か れ、その後で Hiten M. Pandya ⟨hmp@FreeBSD.org⟩ が大幅に修正しました。

バグ

LOCKPARENT フラグは常に親の vnode がロックされる結果になるとは限りませ ん。 LOCKPARENT が使用される時には、複雑化する結果となります。 LOCKPARENT および LOCKLEAF の両方が使用される場合のこの問題の解決のために、再帰的 ロックに頼ることが必要になります。

FreeBSD 10.0 May 27, 2003 FreeBSD 10.0

スポンサーリンク