JP5986585B2 - 下位互換性アグリゲートファイルシステムの動作性能の向上方法、及び装置 - Google Patents

Description

本発明は、ファイルディレクトリを含むファイルシステムを操作するための方法及びその方法を使用した装置に関し、特にレジデンシャルゲートウェイに関する。

エンドユーザーの住宅ネットワークをインターネットに接続するレジデンシャルゲートウェイが現在広く使用されている。レジデンシャルゲートウェイは通常、デジタル加入者線（ＤＳＬ）及びＰＯＴＳ（従来の普通の電話サービス）と呼ばれる電話通信を介してブロードバンドサービスを提供しており、さらに住宅のネットワークのための例えばイーサネット（登録商標）などの有線伝送及び無線伝送（Ｗｉ−Ｆｉ）を含んでいる。レジデンシャルゲートウェイは、サービスを提供するために、ＵＮＩＸ（登録商標）系のオペレーティングシステム上で動作するマイクロプロセッサシステム（ＣＰＵ）を含んでいる。

オペレーティングシステムには、マスター制御プログラム、即ちカーネルと共にアプリケーションやユーティリティが含まれている。カーネルは、プログラムを起動および停止するためのサービスを提供し、ファイルシステムと殆どのアプリケーションが共有する他の一般的な「低レベル」のタスクを処理し、アプリケーション間の競合を回避するためにアクセスをスケジュールする。このようなアクセスの仲立ちをするために、カーネルはその仮想メモリがユーザ空間とシステム空間とに分離されることに反映されている特別な権利を有する。カーネル、カーネルエクステンション、および殆どのデバイスドライバを実行するためにシステム空間が厳密に予約されている。これとは対照的に、ユーザ空間は全てのユーザモードアプリケーションが動作し、必要に応じてメモリの全てがスワップアウト可能なメモリ空間である。

ファイルシステムの重要な概念は、異なる種類のファイルシステムを相互運用可能にする、固定のアプリケーションプログラミングインターフェイス（ＡＰＩ）を有することである。ファイルシステムを利用するアプリケーションにとっては、ファイルシステムのフォーマット、例えばＦＡＴ３２、ＮＴＦＳ、ｅｘｔ３には違いが無く、アプリケーションがこれらを気にするべきでない。オペレーティングシステムがＵＮＩＸ系の場合は、ファイルシステムのＡＰＩは、ＩＥＥＥで定める標準規格のファミリーである移植性の高いオペレーティングシステムインタフェース（ＰＯＳＩＸ）規格に準拠している。

ファイルシステムＡＰＩはファイルシステム間の相互運用を些細なものとし、これは実際有利なことであるが、同様にあるアプリケーションにとっては弱点でもあり得る。ある非常に基本的な操作が直接可能ではなく、ＡＰＩの利用可能な関数でエミュレートする必要があり、リソースの面で高価過ぎることになる。

ファイルシステムは、オペレーティングシステムの一部であり、従ってそれらはシステム空間で動作する。一方、アプリケーションは特権性がより低いユーザ空間で動作する。ユーザ空間とシステム空間との境界を越えるために、図１に示すように、オペレーティングシステムは、システムコールインターフェースを提供する。システムコールは、アプリケーションがオペレーティングシステムのカーネルからのサービスを要求する方法である。一般的に、オペレーティングシステムによって使用されるシステムコールを例えば標準Ｃライブラリ等の関数によってユーザ空間にアクセス可能にする中間ライブラリが存在する。

アプリケーションは、システムコールを直接呼び出すか、またはシステムコールを呼び出すライブラリから関数を呼び出すとき、ユーザ空間とシステム空間の切り替えが必要である。他の手法も存在するけれども、ユーザ空間からシステム空間への切り替えを行うための一般的な方法の１つは、ソフトウェア割り込みによるものである。ソフトウェア割り込みの実行において、システムコールの番号をマイクロプロセッサのレジスタにロードする必要があり、カーネルに制御を移すためにソフトウェア割り込みが実行される。

ファイルシステムが特権的なシステム空間に存在するため、それらはどのライブラリも使用することができない。このように、ファイルシステムを実現することは非常に複雑である。例えば、メモリ管理は、ユーザ空間における場合に比べ、システム空間においてより困難である。かかる制限を克服するために、ファイルシステムは、ユーザ空間においても同様に実現することができる。ユーザ空間におけるファイルシステムの実装を可能にする実装の一例は、ユーザ空間ファイルシステム（ＦＵＳＥ）である。ＦＵＳＥは、ＵＮＩＸ系コンピュータのオペレーティングシステム用のロード可能なカーネルモジュールである。図２に示すように、これは、通常のファイルシステム５と同様に動作するＦＵＳＥカーネルドライバ４と、ユーザ空間内のファイルシステム３とＦＵＳＥカーネルドライバ４の間の通信のためのＦＵＳＥライブラリ６を備える。ファイルシステムの実装は、ユーザ空間に存在し、ファイルシステムのインターフェースを実装する役割を受け持つ。従って、ＦＵＳＥは、ＦＵＳＥカーネルドライバ４がオペレーティングシステムのカーネルにブリッジを提供している間、ユーザ空間におけるファイルシステムコードの実行を可能にする。

アプリケーションがユーザ空間で実装されているファイルシステム３と連携動作しているときに、それぞれのシステムコールは、システム空間に存在する任意のファイルシステムと同様に開始される。カーネル内部では、システムコールは、ＦＵＳＥカーネルドライバ４によって処理される。ＦＵＳＥカーネルドライバ４は、システムコールをシリアル化し、ＦＵＳＥキャラクタ型デバイスを介してユーザ空間に伝送し戻し、ＦＵＳＥライブラリ６は、ユーザ空間内のファイルシステム３によって実装された、対応する関数を起動する。リターンパスは逆の順序で同じ経路を辿る。

ＦＵＳＥはユーザ空間でファイルシステムを実装することができる実装の一例に過ぎず、ここで強調すべき点はユーザ空間内のファイルシステムのすべての種類のコンテキストスイッチを必要とすることである。コンテキストスイッチは、後で同じポイントからその実行再開できるようにマイクロプロセッサの状態を記憶し復元する演算処理である。これにより、複数のプロセスが単一のＣＰＵを共有することが可能になるものであり、コンテキストスイッチは、マルチタスクオペレーティングシステムの本質的な特徴である。コンテキストスイッチは、通常は計算集約的であり、オペレーティングシステムの設計の多くの部分はコンテキストスイッチの使用を最適化することにある。コンテキストスイッチは、レジスタコンテキストスイッチ、タスクコンテキストスイッチ、スレッドコンテキストスイッチ、またはプロセスコンテキストスイッチであり得る。

プロセスコンテキストスイッチは、１つのプロセスから別プロセスへのコントロールの切り替えである。このようなコンテキストスイッチを生成することは、先ずプロセスの状態を後で再開可能なように記憶し、第２のプロセスの状態を開始することができるようにすることを含んでいる。ユーザ空間におけるファイルシステム３の実装のため、システムコールの各々は、２つのコンテキストスイッチが生じる結果となる。即ち、システムコールを実行するアプリケーションは、別のプロセスとして実装されているファイルシステムがコールを処理できるようにサスペンドされ、コールが復帰されると、呼び出し側のアプリケーションが再開される。

このようにして、ユーザ空間に実装されているファイルシステムの範囲において、必要とする膨大な数のコンテキストスイッチによって最大のオーバーヘッドが導入される。図２における大きな矢印１、２は、超えなければならない境界を示している。縦の矢印１は、すべてのファイルシステムコールについて、それらがシステム空間内で実装されているかまたはユーザ空間で実装されているかに拘わらず超えなければならないユーザ空間とシステム空間との境界を示している。水平方向の矢印２は、ファイルシステムがユーザ空間で実装されるときに導入される余分なオーバーヘッドであるプロセス間の境界を示している。

ここで、その結果多数のシステムコールを生じる、ファイルシステム使用について、３つの例を説明する。これらの例がユーザ空間に存在するファイルシステム３に適用される場合、コンテキストスイッチの数が実行不可能な数に増大する結果となる。

ｂ．１）ディレクトリ内の要素のカウント
次の擬似コードは、どのようにしてディレクトリ／ｆｏｏ／ｂａｒ内の要素の数がカウント可能であるかを示している。システムコールを呼び出す関数は太字で示されている。

ディレクトリ／ｆｏｏ／ｂａｒにｎ個の要素が存在する場合、このコードフラグメントによって起動されるシステムコールの数は２＋ｎとなる。／ｆｏｏ／ｂａｒがユーザ空間で実装されているファイルシステム内のディレクトリである場合、２（２＋ｎ）個のコンテキストスイッチが生じる結果となる。

ｂ．２）ディレクトリ内の全ての直接のサブディレクトリの要素のカウント
この例は、前の例の直接の結果として見えるかもしれないけれども、ｄ．２節で説明するように、それはわずかに異なる方法で解決される。この例は人工的な問題のように見えるかもしれないけれども、実際のユースケース（例えばＵＰｎＰ ＡＶ ＢｒｏｗｓｅＤｉｒｅｃｔＣｈｉｌｄｒｅｎ ａｃｔｉｏｎ）を有するものである。

／ｆｏｏ／ｂａｒに各サブディレクトリｍがｍｉ個の要素を有するｎ個のサブディレクトリが有る場合、擬似コード片は

個のシステムコールを呼び出す。／ｆｏｏ／ｂａｒが再びユーザ空間ファイルシステムに存在する場合、

個のコンテキストスイッチを生じる結果となる。

ｂ．３）オフセットからのディレクトリ要素の読み取り／チャンク単位での完全なディレクトリの読み取り

ＰＯＳＩＸファイルシステムＡＰＩは、ファイルハンドルのためにあるような、ディレクトリハンドル内で模索するための同様の方法を提供していない。ファイルの場合、ファイル内の任意の位置に位置インジケータを設定することができる。ディレクトリハンドルのために提供されたシーク機能は、以前に保存された位置に戻すことのみが可能である。このため、ディレクトリアイテムを飛び越えることはアイテムを無視することによってのみ達成することが可能である。

アプリケーションが多くのアイテムを有するディレクトリのサブセットを読み出す必要が有り、このアプリケーションはディレクトリハンドルが開いたままにできないと仮定する。たとえば、一度にＮ個の要素を表示することのみが可能であり、スクロールボックス内のディレクトリの内容を表示する必要があるＷｅｂページが挙げられる。スクロールバーの位置に応じて、Ｗｅｂサービスは、特定のオフセットでＮ個の項目を読み出す必要が有る。最初のＮ個の項目を表示するための、コンテキストスイッチの数は２（Ｎ＋２）である。このように次のＮ個のアイテムを読むことは、Ｎ個のアイテムをスキップし、続いてＮ個のアイテムを読み出すことであり、２（２Ｎ＋２）個のコンテキストスイッチが必要になる。全体として、これらの２Ｎ個のディレクトリアイテムを読み出すためのコンテキストスイッチの数は２（３Ｎ＋４）となる。

一般的に、ディレクトリがｍ×Ｎ個の項目を含む場合、一度にＮ個のアイテムを読み出して完全なディレクトリを読み出すために必要なコンテキストスイッチの数は、ディレクトリ内の要素数に対して２次のオーダーになる。ディレクトリの要素をカウントすることは本質的には線形演算であり、膨大なコストがかかる操作である。

これは、以下の計算によって示される。

米国特許第６３８９４２７Ｂ１号明細書

特許文献１は、コンピュータのファイルシステムでの読み取り専用操作のパフォーマンスを向上させる方法及び装置を開示している。この方法は、初期設定が完了した後、オペレーティングシステムによってトランスペアレントなしかたで実行可能なものである。初期設定は、どのディレクトリやファイルを、それらのファイルへのアクセス要求をインターセプトするために監視するかを識別し、強化された性能でそれらの要求に応答することが含まれる。システム管理者は、どのディレクトリやファイルを監視するかを指定することができる。監視対象ファイルが開かれると、ファイル識別子が使用され、それによってディレクトリメタデータ情報へのアクセスがバイパスされる。一実施形態では、監視対象のファイルへのアクセスがファイルシステムのキャッシュマネージャによって維持されているデータキャッシュ内のファイルを固定することによって強化される。

実ファイルを有するファイルディレクトリを含むファイルシステムを操作する方法は、最小数のシステムコールでファイルシステムから情報を取得することが可能である。これを達成するために、本発明による方法は、仮想ファイルを設計して多くのシステムコールを必要とするファイルディレクトリから結果を提供するステップと、ファイルディレクトリの実ファイルから固有の名前で仮想ファイルを区別するステップと、仮想ファイルを開いて仮想ファイルの内容を読み取ることによりファイルディレクトリから結果を取得するステップを含む。仮想ファイルは特にファイルシステム操作のために設計されている。

本発明の更なる態様において、本発明による方法は、ファイルディレクトリの内容が変更されたとき、仮想ファイルの結果を更新するステップを含む。仮想ファイルは、ファイルディレクトリの実ファイルから固有のファイル拡張子によって有利に区別され、仮想ファイルはファイルディレクトリ内に配置される。

第１の好ましい実施形態においては、本発明による方法は、ファイルディレクトリの要素を数えるファイルシステム操作のために仮想ファイルを設計するステップを含む。第２の好ましい実施形態においては、本発明による方法は、ファイルディレクトリの全ての直接のサブディレクトリの要素を数えるファイルシステム操作のために仮想ファイルを設計するステップを含む。第３の好ましい実施形態においては、本発明による方法は、オフセットからファイルディレクトリのディレクトリ要素を読み取るファイルシステム操作のために仮想ファイルを設計するステップを含む。更なる好ましい実施形態において、本発明による方法はチャンク単位で完全なファイルディレクトリを読み取るファイルシステム操作のために仮想ファイルを設計するステップを含む。

本発明は、さらにファイルシステムを操作する方法を用いた装置に関する。本発明による装置は特に、アプリケーション、ユーティリティ、ファイルシステムの処理の制御プログラムを含むオペレーティングシステムを実行するマイクロプロセッサシステムを含む。本発明による装置は、例えば住宅用ゲートウェイ、ＤＳＬモデムまたはセットトップボックスである。

本発明の好ましい実施形態について模式的な図面を参照しながら以下により詳細に説明する。
マイクロプロセッサシステム上で実行されるオペレーティングシステムおよびアプリケーションを含むファイルシステムを示す図である。 ユーザ空間でファイルシステムを提供するためのＦＵＳＥカーネルモジュールとＦＵＳＥライブラリを更に含む図１のファイルシステムを示す図である。

本発明の好ましい実施形態は、ＲＯＭ及びＲＡＭメモリを含むマイクロプロセッサシステムを含むレジデンシャルゲートウェイで利用され、例えばＵＮＩＸ系オペレーティングシステムで実行される。オペレーティングシステムは、マスター制御プログラム、即ちカーネルと共に、実ファイルを表すアプリケーションとユーティリティを含む。本発明による方法は、必要な結果と適合するように特化した仮想ファイルを設計し、ファイルシステムの名前空間を汚染せず、ファイルシステム内の実ファイルと干渉しないように、ファイルシステム内でこれらのファイルを利用可能にすることを提案している。仮想ファイルの内容は、ユーザの要求に依存しており、そのため、この内容は、両者の間で規則が合意されなければならないプロトコルとして考えることができる。

従って、本発明は、ファイルシステムの実装に使用して、ファイルシステムを利用するアプリケーションが利用可能なアプリケーションプログラミングインターフェース（ＡＰＩ）で不足している機能をエミュレートする必要が生じることを避けることができる汎用的な方法を記載している。本発明は、本発明無しには同じことを達成するために多数のシステムコールが必要となるとき、最小数のシステムコールでファイルシステムから情報を取得することを可能にしている。ｂ節の例によって示されるように、標準ＡＰＩを使用した場合、システムコールの数が多大になる可能性がある。ユーザ空間に実装されたファイルシステムでは、これらのシステムコールに起因するコンテキストスイッチによって、ファイルシステムが使用できなくなる場合が有る。本発明は、ユーザ空間とシステム空間の境界およびユーザ空間内のプロセス間の境界を通過することによって引き起こされるオーバーヘッドを最小限に減少させる。相互運用性を壊さないために、本発明は標準化されたファイルシステムＡＰＩに従っている。

前のｂ節に記載されている例について、考えられる規則を本節で説明する。

ｄ．１）ディレクトリ内の要素のカウント
考えられる規則は、仮想ファイルシステム内のすべてのディレクトリは、ディレクトリ要素の数（サブディレクトリ、ファイル、シンボリックリンク）コンテンツとして有するファイルを利用できるようにするということである。このようなファイルの論理名は、「ｓｉｚｅ」、「ｃｈｉｌｄｃｏｕｎｔ」、「ｄｉｒｓｉｚｅ」等で良く、ｂ．１節で記述されている問題は、以下の擬似コードで解決することができる。

これは、かかる問題がディレクトリ内の要素の数に関わらず、わずか３つのシステムコールで解決できることを示している。大文字Ｏの表記法では、問題がシステムコールの数に対してＯ（ｎ）からＯ（１）に削減されたと言うことができる。ファイルシステムの実装が、この情報を持っている、すなわち、／ｆｏｏ／ｂａｒ内の要素の数が使えると仮定すると、その提案は一般的に複雑度Ｏ（１）となる。

ｄ．２）ディレクトリ内のサブディレクトリすべての直接の要素のカウント
ディレクトリ内のサブディレクトリすべての直接の要素をカウントする可能な規則は、各ラインにサブディレクトリ名、区切り文字列、サブディレクトリ内の要素数を含むファイルである。このようなファイルの論理名は、「ｃｏｎｔｅｎｔｓ」、「ｄｉｒｃｏｎｔｅｎｔ」、「ｄａｔａ」、「ｓｕｂｓｉｚｅ」等であっても良い。

ディレクトリ／ｆｏｏ／ｂａｒが、それぞれが３、２、および５のディレクトリ要素を持つ３つのサブディレクトリ、ｄｉｒ＿ａ、ｄｉｒ＿ｂ及びｄｉｒ＿ｃを有していると仮定する。このとき、ファイル／ｆｏｏ／ｂａｒ＠ｃｏｎｔｅｎｔは、例えば次のような内容を有することができる。
ｄｉｒ＿ａ＝３
ｄｉｒ＿ｂ＝２
ｄｉｒ＿ｃ＝５

ｂ．２節における元の問題に比較すると、問題が再びＯ（ｎ）からＯ（１）に減少している。このことは、この問題は、ｂ．２節で述べたような、以前のものとは異なる理由を説明している。＠ｃｏｎｔｅｎｔファイルが無ければ、問題は簡単になったであろうけれども、擬似コードの次の部分に示すように、複雑度はＯ（ｎ）のままであった筈である。

ｄ．３）オフセットからのディレクトリ要素の読み取り／チャンク単位での完全なディレクトリの読み取り
ディレクトリ内の所定のオフセットから限られた数の要素を読み取る場合に考えられる規則は、オフセットとリミットパラメータを示す変数ファイル名（例えば２から１０の要素を読む場合、ｄｉｒ＿２＿１０）を使用可能な仮想ファイルを持つことである。このファイルは、単に一致する要素の名前を含むことが可能である。このようなファイルの論理名は、「ｄｉｒ＿＜ｆｒｏｍ＞＿＜ｔｏ＞」、「ｃｏｎｔｅｎｔ＿＜ｆｒｏｍ＞＿＜ｔｏ＞ 」、「ｉｔｅｍｓ＿＜ｆｒｏｍ＞＿＜ｔｏ＞」等であっても良い。これは、擬似コードの次の部分に示されている。

元の問題はＯ（ｎ２）の複雑度を有していたけれども、これはＯ（ｎ／Ｎ）まで減少している。最悪の場合はチャンクサイズＮが１である場合であり、複雑度がＯ（ｎ）である。Ｎが少なくともｎであるときが最良の場合であり、複雑度が再びＯ（１）である。まだＮを大とすることができるときのように、メモリに制限が無い場合において、または大部分の時間にディレクトリの要素の数が少ない場合（ｎが小さい値の場合）において、最良の性能が達成される。

これらの例では、ｂ節で説明した問題のためだけに例示された規則であるが、主要な概念は、これら３つの実施例に限定されるものでは無い。

本発明の他の部分は、これらの仮想ファイルをファイルシステム内の実ファイルに干渉しない方法で、仮想ファイルシステム内において利用可能にすることである。それには次のような多くの可能性がある。

・上の例において示されたようなパス拡張ファイル名
この実現例においては、特別な仮想ファイルは同じファイルシステムに実装される（例えば／ｆｏｏ／ｂａｒがそのディレクトリのパスである場合には、パス／ｆｏｏ／ｂａｒ＠ｃｏｎｔｅｎｔｓが仮想ファイルを表す）。唯一の欠点は、パス長が制限されることであり、パスを拡張することは必ずしも常に可能ではない。

・仮想ファイルを有するミラーリングファイルシステム
仮想ファイルを提供するために、専用のミラーリングファイルシステムについて検討することも可能である。このようなミラーリングファイルシステムは、ミラーリングファイルシステムによって基礎となるファイルシステムに仮想ファイルが追加される、既存のファイルシステム上のオーバーレイとして考えることができる。

・拡張可能なプラグインファイルシステム
これは、プラグインインターフェースによってミラーリングファイルシステムの内容を動的に入力することができるミラーリングファイルシステムのためのより一般的なアプローチである。プラグインは、ミラーリングファイルシステムに仮想のコンテンツを追加できるものであり、ファイルシステムにロードすることが可能である。

ファイルシステムの仮想ファイルと実ファイルの名前の衝突を避けるためには、仮想ファイルへのパスから実際のパスを区別するために区切り文字または区切り文字列を使用することができる。上記の例において区切り文字は、例えば競合の可能性を軽減するために「＠」、又は「．＠．」のような可能性の低い文字列であり、例えば、下記のようなものである。
・／ｆｏｏ／ｂａｒ＠ｓｉｚｅ
・／ｆｏｏ／ｂａｒ＠ｃｏｎｔｅｎｔｓ
・／ｆｏｏ／ｂａｒ＠ｃｏｎｔｅｎｔ＿１＿１０

しかし、ＰＯＳＩＸファイルシステムにおいては、パス区切り文字自体（「／」）を除いて、パス名において出現してはならない文字や文字列は無い。

従って、選択した区切り文字、または区切り文字列は、実ファイルへのパスではエスケープする必要がある。これは、仮想ファイルシステムの些細な要件である。

これらの仮想ファイル、３つのシステムコールのみ（設けられたバッファが、ファイル内のすべてのデータを格納するのに十分な大きさであるとき）、またはユーザ空間に実装されたファイルシステムの場合には６つのコンテキストスイッチのみを必要とする通常のファイル操作で読み取ることができる。

干渉を回避するために、仮想ファイルシステムが、選択された区切り文字が仮想ファイルシステムの些細な要件であるディレクトリ名に生じないことのみを保証しなければならないことに留意されたい。

本発明は、以下の利点を有する。

・ファイルシステムからデータを取得するために呼び出されるシステムコールの数が最小化される。

・本発明は、相互運用性を破壊せず、本発明を実施するファイルシステムは追加された機能を認識していないアプリケーションによって依然として何ら制限なしに用いることができる。

・全く新しいシステムコールは、必要とされない。

・関数ＡＰＩにシステムコールをカプセル化している中間ライブラリは、変更する必要が無い。

・すべてのファイルシステム操作は、コールがシェル内で直接開始されるか、シェルスクリプト内から開始されるか、またはいかなるプログラミング言語で書かれたものでも、アプリケーション内から開始されるか、に関係なく以前と同様に動作する。

・新たに導入された仮想ファイルはネットワークの共有下でも同様に参照可能であり、このネットワークファイルシステムを使用するリモートアプリケーションも、本発明から利益を得ることができる。

・可能な用途がここでは３つのみ記載されているけれども、本発明は一般的に適用可能である。

・ファイルシステムが、オーバーヘッドが大きく使用不能になるとき、コンテキストスイッチの減少によってユーザ空間にファイルシステムを実装することが可能になる。

・システム空間内のファイルシステムよりもユーザ空間でファイルシステムを実装することがより容易であり、開発コストが節約される。

また、本発明の他の実施形態は、本発明の範囲から逸脱することなく当業者によって利用され得る。本明細書に記述された方法は、特に、住宅用ゲートウェイで使用することができるが、ファイルシステムを利用したセットトップボックスまたは携帯電話などの他の機器にも本発明を使用することができる。本発明は、従って本明細書の後に添付された特許請求の範囲に存する。
［付記１］
実ファイルを有するファイルディレクトリを含むファイルシステムを操作するための方法であって、
仮想ファイルを設計して複数のシステムコールが必要な前記ファイルディレクトリからの結果を提供するステップと、
前記ファイルディレクトリの実ファイルから固有の名前で前記仮想ファイルを区別するステップと、
前記仮想ファイルを開き、前記仮想ファイルの内容を読み取ることにより、前記ファイルディレクトリから前記結果を取得するステップと、
を有する、前記方法。
［付記２］
複数のシステムコールが必要とされるファイルシステム操作のために前記仮想ファイルを設計するステップをさらに有する、付記１に記載の方法。
［付記３］
前記ファイルディレクトリの内容が変更されたときに、前記仮想ファイルの結果を更新するステップをさらに有する、付記１又は２に記載の方法。
［付記４］
前記仮想ファイルは、前記ファイルディレクトリの実ファイルからの固有のファイル拡張子によって区別される、付記１乃至３のいずれかに記載の方法。
［付記５］
前記ファイルディレクトリ内に前記仮想ファイルを配置するステップを有する、付記１乃至４のいずれかに記載の方法。
［付記６］
前記ファイルディレクトリの要素をカウントする前記ファイルシステム操作のために前記仮想ファイルを設計するステップを有する、付記１乃至５のいずれかに記載の方法。
［付記７］
前記ファイルディレクトリのすべての直接のサブディレクトリの要素をカウントする前記ファイルシステム操作のために前記仮想ファイルを設計するステップを有する、付記１乃至６のいずれかに記載の方法。
［付記８］
オフセットから前記ファイルディレクトリのディレクトリ要素を読み取る前記ファイルシステム操作のために前記仮想ファイルを設計するステップを有する、付記１乃至７のいずれかに記載の方法。
［付記９］
チャンク単位で完全な前記ファイルディレクトリを読み取る前記ファイルシステム操作のために前記仮想ファイルを設計するステップを有する、付記１乃至８のいずれかに記載の方法。
［付記１０］
付記１乃至９のいずれかに記載の方法を利用した装置。
［付記１１］
前記装置は、前記ファイルシステム、アプリケーション、およびユーティリティを処理する制御プログラムを含むオペレーティングシステムを実行するマイクロプロセッサシステムを備えた、付記１０に記載の装置。
［付記１２］
前記装置は、住宅用ゲートウェイ、ＤＳＬモデムまたはセットトップボックスである、付記１０又は１１に記載の装置。

Claims (8)

1. レジデンシャルゲートウェイであって、
   該レジデンシャルゲートウェイが、これに含まれているファイルシステムを操作するマイクロプロセッサシステムを備え、
   また、該レジデンシャルゲートウェイが、アプリケーションを備えたユーザ空間とオペレーティングシステムを備えたシステム空間とを有し、
   前記オペレーティングシステムが、前記ユーザ空間と前記システム空間との間の境界を超えるためのシステムコールインタフェースを有し、
   前記ファイルシステムが前記ユーザ空間に実装され、そして、実ファイルを有するファイルディレクトリを備え、
   前記マイクロプロセッサシステムが、
   各々が前記ユーザ空間と前記システム空間との間の移行を要求する複数のシステムコールが必要とされる、前記ファイルディレクトリから結果を提供するファイルシステム操作のために、仮想ファイルを設計するステップと、
   前記仮想ファイルを固有の名前によって、前記ファイルディレクトリの前記実ファイルから識別するステップと、
   前記仮想ファイルを開き、前記仮想ファイルの内容を読み取ることにより、前記ファイルディレクトリから前記結果を取得するステップと、
   を備えるように構成された、前記レジデンシャルゲートウェイ。
2. 前記ファイルディレクトリの内容が変更されたときに、前記マイクロプロセッサシステムが前記仮想ファイルの結果を更新する、請求項１に記載のレジデンシャルゲートウェイ。
3. 前記仮想ファイルが、固有のファイル拡張子によって、前記ファイルディレクトリの前記実ファイルから識別される、請求項１又は２に記載のレジデンシャルゲートウェイ。
4. 前記マイクロプロセッサシステムが前記ファイルディレクトリ内に前記仮想ファイルを配置する、請求項１乃至３のいずれかに記載のレジデンシャルゲートウェイ。
5. 前記マイクロプロセッサシステムが、前記ファイルディレクトリの要素をカウントする、前記ファイルシステム操作のために前記仮想ファイルを設計する、請求項１乃至４のいずれかに記載のレジデンシャルゲートウェイ。
6. 前記マイクロプロセッサシステムが、前記ファイルディレクトリのすべての直接のサブディレクトリの要素をカウントする、前記ファイルシステム操作のために前記仮想ファイルを設計する、請求項１乃至５のいずれかに記載のレジデンシャルゲートウェイ。
7. 前記マイクロプロセッサシステムが、前記ファイルディレクトリのディレクトリ要素をオフセットから読み取る、前記ファイルシステム操作のために前記仮想ファイルを設計する、請求項１乃至６のいずれかに記載のレジデンシャルゲートウェイ。
8. 前記マイクロプロセッサシステムが、完全な前記ファイルディレクトリをチャンク単位で読み取る、前記ファイルシステム操作のために前記仮想ファイルを設計する、請求項１乃至７のいずれかに記載のレジデンシャルゲートウェイ。

Images