|
次のページ
前のページ
目次へ
4. コールレベルのインターフェース
このセクションは Coda FS ドライバが Venus に行える upcall について記述し
ます。これらそれぞれの upcall は三つの構造体を使用し行われます - カーネ
ルから Venus への通信用
union inputArgs { struct cfs_in_hdr ih; /* NB: every struct below begins with an ih */ struct cfs_open_in cfs_open; struct cfs_close_in cfs_close; struct cfs_ioctl_in cfs_ioctl; struct cfs_getattr_in cfs_getattr; struct cfs_setattr_in cfs_setattr; struct cfs_access_in cfs_access; struct cfs_lookup_in cfs_lookup; struct cfs_create_in cfs_create; struct cfs_remove_in cfs_remove; struct cfs_link_in cfs_link; struct cfs_rename_in cfs_rename; struct cfs_mkdir_in cfs_mkdir; struct cfs_rmdir_in cfs_rmdir; struct cfs_readdir_in cfs_readdir; struct cfs_symlink_in cfs_symlink; struct cfs_readlink_in cfs_readlink; struct cfs_fsync_in cfs_fsync; struct cfs_inactive_in cfs_inactive; struct cfs_vget_in cfs_vget; struct cfs_rdwr_in cfs_rdwr; struct cfs_open_by_path_in cfs_open_by_path; };
union outputArgs { struct cfs_out_hdr oh; /* NB: every struct below begins with an oh */ struct cfs_root_out cfs_root; struct cfs_open_out cfs_open; struct cfs_ioctl_out cfs_ioctl; struct cfs_getattr_out cfs_getattr; struct cfs_lookup_out cfs_lookup; struct cfs_create_out cfs_create; struct cfs_mkdir_out cfs_mkdir; struct cfs_readdir_out cfs_readdir; struct cfs_readlink_out cfs_readlink; struct cfs_vget_out cfs_vget; struct cfs_purgeuser_out cfs_purgeuser; struct cfs_zapfile_out cfs_zapfile; struct cfs_zapdir_out cfs_zapdir; struct cfs_zapvnode_out cfs_zapvnode; struct cfs_purgefid_out cfs_purgefid; struct cfs_rdwr_out cfs_rdwr; struct cfs_replace_out cfs_replace; struct cfs_open_by_path_out cfs_open_by_path; };
union cfs_downcalls { /* CFS_FLUSH is also a down call */ struct cfs_purgeuser_out purgeuser; struct cfs_zapfile_out zapfile; struct cfs_zapdir_out zapdir; struct cfs_zapvnode_out zapvnode; struct cfs_purgefid_out purgefid; struct cfs_replace_out replace; }; ヘッダーはすべてのコールに共通で、プロセス、認証、opcode の情報を含みま す -
struct cfs_in_hdr { unsigned long opcode; unsigned long unique; /* Keep multiple outstanding msgs distinct */ u_short pid; /* Common to all */ u_short pgid; /* Common to all */ u_short sid; /* to become the PAG */ struct coda_cred cred; /* to become a PAG */ }; /* Really important that opcode and unique are 1st two fields! */ struct cfs_out_hdr { unsigned long opcode; unsigned long unique; unsigned long result; }; 先に進む前に、様々なフィールドの役割を説明します。inputArgs は、Venus か
ら要求されるサービスの種類を定義した 特定のコールを調べる前に、カーネルと Venus に共有される様々なデータ構造 体を知る必要があります。
4.1 カーネルと Venus に共有されるデータ構造体
struct CodaCred { vuid_t cr_uid, cr_euid, cr_suid, cr_fsuid; /* Real, efftve, set, fs uid*/ vgid_t cr_gid, cr_egid, cr_sgid, cr_fsgid; /* same for groups */ vgid_t cr_groups[NGROUPS]; /* Group membership for caller */ }; 注記 Venus 内で CodaCreds が必要かどうかは、疑問です。最終的に、 Venus は デフォルトの uid/gid を持ったファイルを作成するとはいえ、Venus は group について知りません。たぶん group メンバシップのリストは余分です。
次のアイテムは Coda ファイルを識別するために使われる基本的な識別子
cell は単一の system control machine (SCM) の保護下で 稼動する Coda サーバのグループです。
typedef struct ViceFid { VolumeId Volume; VnodeId Vnode; Unique_t Unique; } ViceFid; 構成中の各フィールド - Venus とカーネル間で共有された次に重要な構造体はファイルの属性です。続く 構造体は情報交換に使用されます。それはデバイスファイル向けのサポート (現 状 Coda にはありません) のような将来の拡張用の場所があります。
struct coda_vattr { enum coda_vtype va_type; /* vnode type (for create) */ u_short va_mode; /* files access mode and type */ short va_nlink; /* number of references to file */ vuid_t va_uid; /* owner user id */ vgid_t va_gid; /* owner group id */ long va_fsid; /* file system id (dev for now) */ long va_fileid; /* file id */ u_quad_t va_size; /* file size in bytes */ long va_blocksize; /* blocksize preferred for i/o */ struct timespec va_atime; /* time of last access */ struct timespec va_mtime; /* time of last modification */ struct timespec va_ctime; /* time file changed */ u_long va_gen; /* generation number of file */ u_long va_flags; /* flags defined for file */ dev_t va_rdev; /* device special file represents */ u_quad_t va_bytes; /* bytes of disk space held by file */ u_quad_t va_filerev; /* file modification number */ u_int va_vaflags; /* operations flags, see below */ long va_spare; /* remain quad aligned */ };
4.2 pioctl インターフェース
Coda ファイルシステムに固有の要求を、pioctl インターフェースを介して、ア
プリケーションから行うことができます。pioctl は仮想ファイル
ここでのカーネルの関与は open, close, ioctl へのメッセージ渡し、pioctl データバッファ内のパスが Coda ファイルシステムの中のファイルであることの 確認、の仕組みの提供に制限されます。 カーネルは次の形式のデータパケットを渡されます - struct { const char *path; struct ViceIoctl vidata; int follow; } data; ここで
struct ViceIoctl { caddr_t in, out; /* Data to be transferred in, or out */ short in_size; /* Size of input buffer <= 2K */ short out_size; /* Maximum size of output buffer, <= 2K */ };
注記 データ構造体およびコードはむちゃくちゃです。これを整理する必 要があります。 個々のコールを説明します -
4.3 root
引き数
詳細 このコールは Coda ファイルシステムの初期化中に Venus へ行われ
ます。
4.4 lookup
概要 ディレクトリにその ViceFid およびオブジェクトの種別が存在する か探します。 引き数
詳細 このコールはディレクトリエントリの ViceFid および filetype を
決めるために行われます。要求されたディレクトリエントリは オブジェクトの名前は最大長 CFS_MAXNAMLEN の 8 ビット文字列で、現在 CFS_MAXNAMLEN は 256 に設定されています (文字数は 0 ターミネータ文字を含 みます)。 オブジェクトがカーネルのネームキャッシュに置かれてはならないことを示す
注記 vtype の種別は現状誤りです。
4.5 getattr
概要 ファイルの属性を得ます。 引き数
詳細 このコールは fid で指定されたファイルの属性を返します。 エラー fid を持ったオブジェクトが存在しないかアクセスできない場合や 呼び出し元に属性を見るパーミッションがない場合、エラーが起きる可能性があ ります。 注記 カーネル FS ドライバ (Linux、NT, Windows 95) の多くは、内部の "inode" や "FileHandle" のインスタンスを作成する ために、Fid だけでなく属性も得る必要があります。このようなシステムでは Venus/カーネル相互作用レベルと RPC レベルの両方で、lookup と getattr コールを組合わせることによってパフォーマンスを著しく向上で きるかもしれません。 入力の引き数内の
4.6 setattr
概要 ファイルの属性を設定します。 引き数
詳細 構造体 エラー 様々なエラーが起こる可能性があります。オブジェクトが存在しな い、アクセスできない、パーミッションが Venus から与えられないなど。
4.7 access
概要 引き数
詳細 エラー オブジェクトは存在しないかもしれません、もしくは保護情報を記 載する ACL はアクセス可能ではないかもしれません。
4.8 create
概要 ファイルを作成するために呼び出されます。 引き数
詳細 この upcall はファイルの作成を要求するために呼び出されます。
ファイルは エラー 様々なエラーが起こる可能性があります。パーミッションは不十分
かもしれません。オブジェクトが存在しそれがファイルでない場合、Unix 下で
エラー 注記 パラメータの組みはとても非効率的で、システムコールの creat と
VFS 操作の create との混同を示したものと思われます。VFS 操作の create は
新しいオブジェクトの作成の際にだけコールされます。この create コールは
Unix のコールとは異なり、ファイルディスクリプタを返すために呼び出される
ことはありません。トランケートとイクスクルシブのオプション、およびモード
は、単に Unix 下でのモードの一部にできるはずです。フラグの引き数があるべ
きではありません - 現在これは、READ もしくは WRITE モード用のファイルディ
スクプリタを返すために ディレクトリの属性も、size および mtime が変更されるので、返されるはずで す。
4.9 mkdir
概要 新しいディレクトリを作成します。 引き数
詳細 このコールは エラー create と同様です。 注記 入力パラメータは属性の変わりに 親の属性は、size および mtime が変わるので、返されるはずです。
4.10 link
概要 既存ファイルへのリンクを作成します。 引き数
詳細 このコールは、名前 エラー 通常のエラーが起こる可能性があります。 4.11 symlink
概要 シンボリックリンクを作成します。 引き数
詳細 シンボリックリンクを作成します。リンクは エラー 注記 ターゲットディレクトリの属性は、size が変更されるので、返され るはずです。
4.12 remove
概要 ファイルを削除します。 引き数
詳細 エラー 注記 ディレクトリの属性は、size および mtime が変わるかもしれないの で、返されるはずです。
4.13 rmdir
概要 ディレクトリを削除します。 引き数
詳細 エラー 注記 親ディレクトリの属性は、size および mtime が変わるかもしれない ので、返されるはずです。
4.14 readlink
概要 シンボリックリンクの値を読み出します。 引き数
詳細 このルーチンは エラー 通常のエラーだけです。
4.15 open
概要 ファイルを開きます。 引き数
詳細 これは エラー 注記 現状、
4.16 close
概要 ファイルを閉じ、サーバ上でそれを更新します。 引き数
詳細 エラー 注記
4.17 ioctl
概要 ファイルに対する ioctl を行います。これは pioctl インターフェー スを含みます。 引き数
詳細 ファイルに対する ioctl 操作を行います。 エラー 注記 ここでも無用なパラメータです。
4.18 rename
概要 fid の名前を変更します。 引き数
詳細 ディレクトリ エラー
4.19 readdir
概要 ディレクトリエントリを読み出します。 引き数
詳細 ディレクトリエントリを エラー 注記 このコールは使用されません。Readdir 操作はコンテナファイルを消 費するためです。これから行うディレクトリの改良の間に、この件を再考します。
4.20 vget
概要 引き数
詳細 この upcall は エラー 注記 この操作は使用されません。しかしながら、メモリにマップされたファ
イルの読み出し/書き込みに対応するために使うことができるので、非常に有用
です。これらのファイルは
4.21 fsync
概要 ファイルの RVM 属性を更新するよう Venus に命じます。 引き数
詳細 オブジェクト エラー NOTE Linux はこのコールを実装していません。実装すべきです
4.22 inactive
概要 vnode をもう使用しないと Venus に命じます。 引き数
詳細 この操作は エラー 注記 これはたぶん削除されるはずです。
4.23 rdwr
概要 ファイルに対し読み出しか書き込みをします。 引き数
詳細 この upcall はファイルに対し読み出しか書き込みを行うよう Venus に依頼します。 エラー 注記 読み出し/書き込みの操作を Venus は行わないという Coda の主義 に逆らうことなので、これは削除されるはずです。この操作は動作しないと聞い ています。現在使用されていません。
4.24 odymount
概要 一つの Unix のマウントポイントに複数の Coda ファイルシステムを マウントすることを可能とします。 引き数
詳細 エラー 注記 このコールは dynamic set 向けに David が使っていました。これは VFS マウンティング領域のポインタを複雑にしてしまうので、削除されるはずで す。普通の Coda は使用しません。このコールは Venus では実装されていませ ん。
4.25 ody_lookup
概要 何かを調べます。 引き数
詳細 エラー 注記 中身はありません。このコールは Venus では実装されていません。
4.26 ody_expand
概要 dynamic set における何かを拡張します。 引き数
詳細 エラー 注記 中身はありません。このコールは Venus では実装されていません。
4.27 prefetch
概要 dynamic set を先読みします。 引き数
詳細 Venus の worker.cc にはこのコールのサポートがありますが、動作 しないと記されています。カーネルはサポートしていませんので、これは驚くべ きことではありません (ODY_PREFETCH は動作が定義されていません)。 エラー 注記 中身はありません。コールは動作せず、Coda で使用されません。
4.28 signal
概要 upcall に関する signal を Venus に送ります。 引き数
詳細 これは Venus への upcall の通常処理範囲外のもので、Venus が入 力キューからメッセージを読んだ後、呼び出し元のプロセスが signal を受け取っ たことを Venus に通知します。Venus は操作を完了することになっています。 エラー 応答はありません。 注記 Venus の完了処理を正しく行うために Venus が何を完了する必要が あるのかを良く理解しておく必要があります。さらに、システムコールの状態毎 に複数の upcall を正確に扱う必要があります。また、Venus で upcall の後、 カーネルから (責任範囲として) 完了の通知を行う必要のあるどのような状態が Venus で起きるのかを知ることが重要です (例えば open は間違いなくこのよう な状態変化ですが、他の多くのものはそうではないかもしれません)。
次のページ 前のページ 目次へ |
[ |