特許 6943954 コンテナに基づくＧＰＵ仮想化方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6943954

(24)【登録日】2021年9月13日

(45)【発行日】2021年10月6日

(54)【発明の名称】コンテナに基づくＧＰＵ仮想化方法及びシステム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20210927BHJP

   G06F 9/455 20060101ALI20210927BHJP

【ＦＩ】

   G06F9/50 120A

   G06F9/455 150

【請求項の数】5

【全頁数】9

(21)【出願番号】特願2019-518972(P2019-518972)

(86)(22)【出願日】2018年12月28日

(65)【公表番号】特表2020-537197(P2020-537197A)

(43)【公表日】2020年12月17日

(86)【国際出願番号】KR2018016810

(87)【国際公開番号】WO2020075919

(87)【国際公開日】20200416

【審査請求日】2019年4月3日

(31)【優先権主張番号】10-2018-0169620

(32)【優先日】2018年12月26日

(33)【優先権主張国】KR

【早期審査対象出願】

【前置審査】

(73)【特許権者】

【識別番号】519121186

【氏名又は名称】レブルアップ インコーポレーテッド

【氏名又は名称原語表記】Ｌａｂｌｕｐ Ｉｎｃ．

(74)【代理人】

【識別番号】100130111

【弁理士】

【氏名又は名称】新保 斉

(72)【発明者】

【氏名】キム、ジュン ギ

(72)【発明者】

【氏名】シン、ジョン ギュ

(72)【発明者】

【氏名】パク、ジョン ヒョン

【審査官】 三坂 敏夫

(56)【参考文献】

【文献】 米国特許出願公開第２００７／００９７１３２（ＵＳ，Ａ１）

【文献】 韓国公開特許第１０−２０１８−００４５３４７（ＫＲ，Ａ）

【文献】 韓国公開特許第１０−２００９−００２６５７９（ＫＲ，Ａ）

【文献】 松本 赳明，GPU Container as a Serviceを実現するための最新OSS徹底比較，[online]，ＮＴＴコミュニケーションズ，2017年07月，スライド番号：1,5-7,13-15,37,40-44,55-57，[令和2年10月21日検索]、インターネット＜ＵＲＬ：https://www.slideshare.net/VirtualTech-JP/gpu-container-as-a-serviceoss-openstack-20177＞

【文献】 TOKUDA,Takuya，Kubernetes道場 3日目 - Podについてとkubectlの簡単な使い方，[online]，2018年12月03日，第1頁−第4頁，[令和2年10月21日検索]、インターネット＜ＵＲＬ：https://cstoku.dev/posts/2018/k8sdojo-03/＞

【文献】 伊吹 勇郎，短期間でＡＩモデルを作成・提供可能とする深層学習基盤の開発，ＮＴＴ ＤＯＣＯＭＯテクニカル・ジャーナル，一般社団法人電気通信協会，2018年01月，第25巻 第4号，第12頁−第18頁

【文献】 森 和之，今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2，[online]，株式会社トップゲート，2014年05月12日，第1頁−第19頁，[令和2年10月21日検索]、インターネット＜ＵＲＬ：https://www.publickey1.jp/blog/14/dockerdockerfiledocker_meetup_tokyo_2.html＞

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５−９／５４

(57)【特許請求の範囲】

【請求項1】

コンテナに基づくＧＰＵ（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）仮想化方法において、
コンテナが生成されると、ノードコントローラがＧＰＵ資源制約情報を含む設定ファイルとＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）設定ファイルを前記コンテナに送信する段階と、
前記コンテナが実行されると、前記コンテナに設けられるライブラリコントローラがライブラリ呼出しを横取りしてＧＰＵ資源使用可能量因子を変更し、システムコールコントローラがシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する段階と、を含み、
前記ノードコントローラは、
ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化し、管理部に資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信するが、前記ノードコントローラの資源使用可能量情報を要請した量だけ差し引いて更新し、
前記ＧＰＵ資源の使用可能量は、実数で表される割合でＧＰＵ資源を部分的に使用可能な量である
ことを特徴とするコンテナに基づくＧＰＵ仮想化方法。

【請求項2】

前記ノードコントローラは、
コンテナが生成されると、資源制約情報を含む設定ファイルをコンテナに保存し、コンテナの実行後、終了が感知されると、ノードコントローラの資源使用可能量情報を要請した量だけ回収して更新する
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。

【請求項3】

前記ライブラリコントローラは、
ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源使用可能量因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出す
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。

【請求項4】

前記システムコールコントローラは、
ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプログラムにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩ設定ファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。

【請求項5】

コンテナに基づくＧＰＵ仮想化システムにおいて、
資源制約情報を含む設定ファイルとシステムコール／ＡＰＩ設定ファイルをコンテナに伝達してコンテナ内に伝達するノードコントローラを含む運営体制と、
ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源使用可能量因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出すライブラリコントローラと、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩ設定ファイルにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩ設定ファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更するシステムコールコントローラとを含むコンテナと、で構成され、
前記ノードコントローラは、
ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化し、管理部に資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信するが、前記ノードコントローラの資源使用可能量情報を要請した量だけ差し引いて更新し、
前記ＧＰＵ資源の使用可能量は、実数で表される割合でＧＰＵ資源を部分的に使用可能な量である
ことを特徴とするコンテナに基づくＧＰＵ仮想化システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテナに基づくＧＰＵ（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）仮想化方法及びシステムに係り、特に、コンテナ内のライブラリコントローラ及びシステムコールコントローラにより、ＧＰＵ資源と関連した因子値等を変更してＧＰＵ仮想化を具現するコンテナに基づくＧＰＵ仮想化方法及びシステムに関する。

【背景技術】

【0002】

最近、マルチユーザのための大規模コンピューティングの効率性、保安性、及び互換性の向上のために、仮想化技術が多く用いられている。代表的に、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）があり、アプリケーション、サーバ、ストレージ、及びネットワーク等の多様な分野に適用されている。しかし、仮想マシンは、ＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）からディスク、ネットワーク、Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）まで物理的なハードウェア要素を全て仮想化するので、互換性と隔離レベルは最も高いが、コンピューティング資源の追加消耗量（オーバーヘッド）が大きいという短所をあった。

【0003】

一方、コンテナは、仮想化ではなく、運営体制レベルの隔離技術を用いて、仮想マシンの短所を克服する仮想化技術として浮上している。コンテナは、カーネルレベルの実行環境はホストの運営体制カーネルを共有するが、ユーザレベルの実行環境は完全に隔離されたファイルシステムと、カーネルが提供する資源要素の仮想化した名前空間を用いる方式で具現される。隔離されたファイルシステムの内容は、アプリケーションとそれを駆動するために必要な全ての従属物、ライブラリ、その他のバイナリと構成ファイル等を一つのパッケージにまとめて構成される。仮想化した名前空間に区分され、コンテナに提供されるカーネルの資源要素には、プロセスＩＤ、ネットワークソケット、ユーザアカウント、プロセス間通信（ＩＰＣ、ｉｎｔｅｒｐｒｏｃｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ）のための共有メモリ等がある。その他のハードウェアアクセスは、コンテナでない場合と同様に処理されるので、ホストハードウェアの性能をオーバーヘッド無しに完全に活用することができる。ここで、運営体制は、コンテナ別に最大使用可能なハードウェア資源の量を制限できるオプションを提供する。

【0004】

最近、深層学習技術の発達と大規模な演算需要の増加につれて、コンピューティング資源を最適に共有して管理する技術が要請されている。性能向上のために、深層学習の演算特性に最適化した演算加速ハードウェアが登場しており、ＧＰＵも、その一つである。しかし、既存の運営体制において提供するコンテナに基づく仮想化技術は、コンテナ別にＣＰＵ、メモリ、ディスク、及びファイルシステムに対する資源共有及び制限のみを支援しており、ＧＰＵのような演算加速ハードウェアについては、多くのコンテナが同時に共有できる技術が提供されていない。このため、ＧＰＵを効率的に共有及び管理し難いという問題が発生した。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明は、上記問題点に鑑みなされたものであり、コンテナを用いて、物理的仮想化ではなく、運営体制レベルの仮想化により、ＧＰＵ資源を動的に割当及び共有可能なコンテナに基づくＧＰＵ仮想化方法及びシステムを提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法は、コンテナが生成されると、ノードコントローラがＧＰＵ資源制約情報を含む設定ファイルとＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）プロファイルを前記コンテナに送信する段階と、前記コンテナが実行されると、前記コンテナに設けられるライブラリコントローラがライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラがシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する段階と、を含む。

【0007】

本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムは、資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルをコンテナに伝達してコンテナ内に伝達するノードコントローラを含む運営体制と、ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出すライブラリコントローラと、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプロファイルにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更するシステムコールコントローラとを含むコンテナと、で構成される。

【発明の効果】

【0008】

本発明によれば、コンテナ仮想化技術を拡張することにより、シングルコンテナにシングルＧＰＵを割り当て、またはシングルコンテナにマルチＧＰＵを割り当て、またはシングルＧＰＵをマルチコンテナが共有し、またはマルチＧＰＵをマルチコンテナが共有するＧＰＵコンピューティンシステムの具現が可能である。

【0009】

また、コンテナを用いて具現することにより、仮想マシンに比べて、システム資源をさらに効率的に用いることができ、アプリケーション移動が可能であり、スケーリングが簡単であり、アップデートが容易であるという効果がある。

【図面の簡単な説明】

【0010】

【図1】本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムのソフトウェア構造の説明図

【図2】本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法のフローチャート

【図3】本発明の一実施例に係るノードコントローラの動作方法のフローチャート

【図4】本発明の一実施例に係るライブラリコントローラの動作方法のフローチャート

【図5】本発明の一実施例に係るシステムコールコントローラの動作方法のフローチャート

【発明を実施するための形態】

【0011】

本明細書に開示されている本発明の概念による実施例についての特定の構造的または機能的説明は、単に本発明の概念による実施例を説明するための目的で例示されたものであり、本発明の概念による実施例は、様々な形態で実施されてもよく、本明細書に説明された実施例に限定されない。

【0012】

本発明の概念による実施例は、様々な変更が加えられてもよく、様々な形態を有し得るので、実施例を図面に例示し、本明細書において詳述する。しかし、これらは、本発明の概念による実施例を特定の開示形態に限定するものではなく、本発明の思想及び技術範囲に含まれる全ての変更、均等物、または代替物を含む。

【0013】

本明細書において用いられた用語は、単に特定の実施例を説明するために用いられたものであって、本発明を限定するものではない。単数の表現は、文脈上明らかに異なる意味を有さない限り、複数の表現を含む。本明細書において、「含む」または「有する」との用語は、本明細書に記載された特徴、数字、段階、動作、構成要素、部分品、またはそれらの組合せが存在することを指定するものであり、一つまたはそれ以上の他の特徴や数字、段階、動作、構成要素、部分品、またはそれらの組合せの存在または付加可能性を予め排除するものではない。

【0014】

以下、添付された図面を参照して、本発明の好適な実施例について詳述する。
図１は、本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムのソフトウェア構造を説明するための図である。

【0015】

図１を参照すると、ＧＰＵ仮想化システム１００のソフトウェア構造は、物理的ＧＰＵ（ＰＨＹＳＩＣＡＬ ＧＰＵ）１１０、運営体制１２０、多数個のコンテナ１３０で構成される。

【0016】

運営体制１２０は、ノードコントローラ１２１、コンテナエンジン１２３、運営体制カーネル１２５で構成される。運営体制１２０は、運営体制カーネル１２５内にインストールされたＧＰＵドライバ１２７を介して物理的ＧＰＵ１１０と通信する。

【0017】

ノードコントローラ１２１は、資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルをコンテナ１３０に伝達してコンテナ内に保存する。ノードコントローラ１２１は、ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化する。前記ＧＰＵ資源は、ＧＰＵプロセッシングユニットとＧＰＵメモリであってもよいが、これに限定するものではない。ノードコントローラ１２１は、管理部（Ｍａｎａｇｅｒ）に確認された資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信する。ノードコントローラ１２１は、ＧＰＵ資源の使用可能量情報を更新し、このとき、要請した量だけ差し引く。ノードコントローラ１２１は、コンテナが生成されると、資源制約情報を含む設定ファイルをコンテナに伝達し、コンテナの実行後、終了が感知されると、ノードコントローラの資源使用可能量情報を要請した量だけ回収して更新する。ノードコントローラ１２１は、ユーザのコード実行要請をコンテナ内で実行する。

【0018】

コンテナエンジン１２３は、コンテナ１３０を生成して配布し、各コンテナ１３０が該当する応用プログラムを実行するようにＧＰＵ資源を割り当てる役割を行う。コンテナエンジン１２３は、コンテナを実行して終了する。

【0019】

コンテナ１３０は、ユーザプログラムを駆動するために必要な、各種のプログラム、ソースコードと、ライブラリをまとめたイメージを含む空間である。ユーザプログラムの駆動は、運営体制１２０で実質的に行われる。すなわち、運営体制１２０は、コンテナエンジン１２３を介してそれぞれのコンテナ１３０にアクセスし、該当するユーザプログラムを実行して処理する。

【0020】

コンテナ１３０は、ユーザプログラム１３１、ＧＰＵライブラリ１３３、ＧＰＵランタイム１３５、ライブラリコントローラ１３７、システムコールコントローラ１３９で構成される。
ユーザプログラム１３１は、ノードコントローラのユーザのコード実行要請をコンテナ内で実行するように動作する。

【0021】

ＧＰＵライブラリ１３３は、深層学習フレームワークが動作するようにライブラリを含み、例えば、テンソルフロー（ＴｅｎｓｏｒＦｌｏｗ）、Ｃａｆｆｅ、Ｐｙｔｏｒｃｈ、ＣＮＴＫ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｇｎｉｔｉｖｅ Ｔｏｏｌｋｉｔ）、Ｃｈａｉｎｅｒのような深層学習フレームワークの少なくとも一つが動作してもよい。

【0022】

ＧＰＵランタイム１３５は、ＧＰＵで行う並列処理アルゴリズムであるＣＵＤＡ（Ｃｏｍｐｕｔｅ Ｕｎｉｆｉｅｄ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＯｐｅｎＣＬ（Ｏｐｅｎ Ｃｏｍｐｕｔｉｎｇ Ｌａｎｇｕａｇｅ）、ＲＯＣｍ（Ｒａｄｅｏｎ Ｏｐｅｎ Ｃｏｍｐｕｔｅ）がインストールされて使用されてもよい。前記ＣＵＤＡは、マシンランニング分野で活用されるＧＰＵミドルウェアとしてＧＰＵランタイムで動作する。前記ＯｐｅｎＣＬは、マシンランニング分野と高性能コンピューティン（ＨＰＣ、Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｍｐｕｔｉｎｇ）において活用する並列コンピューティングとクロスプラットフォームにより動作する。

【0023】

ライブラリコントローラ１３７は、ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更して元のライブラリ関数を呼び出す。ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しでなければ、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする。

【0024】

システムコールコントローラ１３９は、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプログラムにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する。予め定義されたＡＰＩプロファイルによる許容、遮断、変更の少なくとも一つのシステムコール呼出しでなければ、元のシステムコールを因子変更無しに呼び出し、返還値をそのままリターンする。

【0025】

すなわち、コンテナ内のライブラリコントローラ１３７がライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラ１３９がシステムコール呼出しを横取りして因子及び返還値を変更することにより仮想ＧＰＵを具現する。

【0026】

図２は、本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法を説明する順序図である。

【0027】

図２を参照すると、コンテナが生成されると（Ｓ２０１）、ノードコントローラ１２１がＧＰＵ資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルを前記コンテナに送信する（Ｓ２０３）。コンテナ内のライブラリコントローラとシステムコールコントローラが資源制約情報を含む設定ファイルを受信して保存する。

【0028】

コンテナが実行されると、前記コンテナに設けられるライブラリコントローラ１３７がライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラ１３９がシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する（Ｓ２０５）。このとき、ライブラリコントローラ１３７は、ＧＰＵ資源量と関連した因子のみならず、構造体フィールド、返還値を変更して元のライブラリ関数を呼び出す。

【0029】

図３は、本発明の一実施例に係るノードコントローラの動作方法を説明する順序図である。

【0030】

図３を参照すると、ノードコントローラは、先ずＧＰＵの資源使用可能量を確認する（Ｓ３０１）。また、ノードコントローラは、資源情報を初期化する（Ｓ３０３）。

【0031】

サーバ実行ループにより、以下のプロセスが繰り返して進行される（Ｓ３０５）。確認されたＧＰＵ資源使用可能量を管理部に報告し（Ｓ３０７）、前記管理部から割り当てられた作業（ｊｏｂ ｓｐｅｃ）を受信する（Ｓ３０９）。ノードコントローラ１２１は、資源使用可能量情報を更新する（Ｓ３１１）。このとき、要請した量だけ差し引かれる。以降、コンテナが生成され（Ｓ３１３）、ライブラリコントローラとシステムコールコントローラが読み出す資源制約情報を含む設定ファイルをコンテナに送信して保存する（Ｓ３１５）。以降、コンテナが実行され（Ｓ３１７）、コンテナの終了が感知されると、ノードコントローラの資源使用可能量情報を更新する（Ｓ３１９）。このとき、要請した量を回収する。

【0032】

図４は、本発明の一実施例に係るライブラリコントローラの動作方法を説明する順序図である。

【0033】

図４を参照すると、ユーザプログラムのライブラリ関数呼出しイベントを受信する（Ｓ４０１）。以降、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールであるかを判断する（Ｓ４０３）。

【0034】

判断結果により、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールである場合は、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更する（Ｓ４０５）。このとき、内蔵されたＡＰＩプロファイル及びコンテナ設定ファイルに基づいて変更される。
以降、変更後、元のライブラリ関数を呼び出す（Ｓ４０７）。

【0035】

判断結果により、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールでなければ、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする（Ｓ４０９）。

【0036】

図５は、本発明の一実施例に係るシステムコールコントローラの動作方法を説明する順序図である。

【0037】

図５を参照すると、ユーザプログラムのシステムコール呼出しイベントを受信する（Ｓ５０１）。予め定義されたＡＰＩプロファイルに変更が必要なシステムコールであるかを判断する（Ｓ５０３）。このとき、変更のみならず、許容、遮断すべき場合であるかを判断する。判断結果により、許容、遮断、及び変更が必要なシステムコールであれば、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する（Ｓ４０５）。

【0038】

判断結果により、許容、遮断、及び変更が必要ではないシステムコールであれば、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする（Ｓ４０７）。

【0039】

本発明は、図示された実施例を参考として説明されたが、これは、例示的なものに過ぎず、本技術分野における通常の知識を有する者であれば、これに基づいて様々な変形及び均等な他の実施例が可能である。したがって、本発明の真正の技術的保護範囲は、添付された登録請求の範囲の技術的思想により定められなければならない。

【図1】

【図2】

【図3】

【図4】

【図5】