--- a/Paper/chapter/3-GearsOS.tex	Thu Feb 10 10:03:41 2022 +0900
+++ b/Paper/chapter/3-GearsOS.tex	Thu Feb 10 11:28:41 2022 +0900
@@ -1,53 +1,67 @@
 \chapter{GearsOS}
-GearsOSは当研究室が開発する、OS自体の信頼性の確保と拡張性の高さを目指したOSである。
-GearsOSはContinuation based Cを用いることにより、ノーマルレベルとメタレベルの分離を行い、
-プログラマが記述したノーマルレベルのコードをメタレベルから信頼性の検査を行えるような仕組みを作ることにより、
-OS自身の信頼性の向上を目指している。
-メタレベルのプログラムはPerlスクリプトによるトランスコンパイラにて自動生成されるように構成されており、
-基本的にユーザーはノーマルレベルのプログラムの記述のみ行うことで、メタレベル分離の恩恵を受けられる仕組みとなっている。
-プログラマは.cbcファイルに対して記述を行うことでプログラムの構成を行うが、
-実際に動作するプログラムはトランスコンパイラによりmeta部分の記述が行われた純粋な.cファイルが動作する。
-
-現状ではCbCの言語フレームワークとして実装されており、OSとして実際に起動するためには実装が必要となる機能が多く存在している。
-必要な機能をCbCによる記述により実装していくことでOSの完成を目指す。
+GearsOS のメタレベルのプログラムはPerlスクリプトによるトランスコンパイラにて自動生成されるように構成されている。
+基本的にユーザーはノーマルレベルのプログラムの記述のみ行う。
+メモリ管理あるいはプロセス、あるいは検証やモデル検査はメタレベルで分離する仕組みとなっている。
+プログラマは.cbcファイルに対して記述を行うことでプログラムの構成い、
+実際に動作するプログラムはトランスコンパイラによりmeta部分の記述追加した.cファイルが動作する。
 
 \section{Interface}
-GearsOSの重要な仕様としてInterfaceが存在する。
-Interfaceの役割の一つとして、通常のプログラミングにおけるモジュール化の仕組みと同様の役割を持つ。
+GearsOSの重要な仕様としてInterfaceが存在する。Interaceは DataGear をCの構造体として定義し、
+そのDataGearを操作する method のAPI(codeGearの型)を提供する。これは Java などの 
+Interfaceのモジュール化の仕組みと同様の役割を持つ。
+
+CbCはstackをもたないので、APIで呼び出された引数はstackではなく、プロセスごとのContextというmetaDataGear
+に置かれる。つまり引数はInterface構造体の中にすべて用意される。これはAPIなので、
+DataGearの中身に相当するDataGearが別に動的に確保する必要がある。これはDataGearの実装であり Impl として
+別に用意する。つまり、同じAPIだが、異なる実装を持つ DataGear がある。例えば、SingleLinkedQueue と SyncrhonizedQueueu などが
+そういうものである。
+
 GearsOSに実装されているQueueのInterfaceをソースコード\ref{src:Queue.h}に示す。
 
 \lstinputlisting[label=src:Queue.h, caption=Queueのインターフェース]{src/Queue.h}
 
-GearsOSにおけるInterfaceはヘッダファイルに対して記述を行い、APIとして用いたいCodeGearとそのCodeGearに入出力されるDataGearを記述する。
-5から10行目はCodeGearの宣言である。
-また、2, 3行目のunion Data型の変数はAPIのCodeGearで使用されるDataGearを記述する。
+\verb+__code+で始まる5から10行目はCodeGearの宣言である。
+2, 3行目のunion Data型の変数はAPIのCodeGearで使用されるDataGearを記述する。
+
+コード内のCodeGearの第1引数はImpl*型の変数となっており、Interfaceを実装するImplementへのポインタとなる。
+CbCはスタックを持たず、複数のCodeGear間をまたいで必要な情報はDataGearのポインタとして持ち運ぶ必要がある。
 
-コード内のCodeGearの第1引数はImpl*型の変数となっており、Interfaceを引き継いだImplementのポインタとなる。
-これはCbCはスタックを持たず、複数のCodeGear間をまたいで必要な情報はDataGearとして持ち運ぶ必要があるため、
-DataGearとしてImplementのポインタを設定している。
-また、このImplementのポインタはgotoでの遷移の際はトランスコンパイラによる補完により、gotoの引数として記述する必要はない。
+このInterfaceは以下のように呼び出される。queue はInterfaceへのポインタで、そのAPIであるputを
+呼び出す。queue は引数を格納するための構造体で、実装はその中にポインタを通して格納されている。
+この構造体は呼び出し毎に書き換えられるので再帰的に使うことはできない。つまり、CbCのInterface
+は基本的にループであって、再帰呼び出しを行うには明示的にスタックを用意する必要がある。
+
+\begin{lstliting}[frame=lrbt,caption{Interfaceの呼び出し}]
+    goto queue->put(task, next(...));
+\end{lstliting}
 
 \texttt{\_\_code next(...)}は
 そのCodeGearが呼び出される際に入力される別のCodeGearへのポインタであり、
-そのAPIのCodeGearの処理後の遷移先のCodeGearを指定することができる。
+そのAPIのCodeGearの処理後の遷移先のCodeGearを指定することができる。\verb+...+ の意味は
+呼び出した引数の構造体を全部含んでいるということで、関数型プログラミングのclosureに近いが、
+再帰しないという違いがある。一段だけの関数呼び出しだと思ってもよい。
 \texttt{\_\_code whenEmpty(...)}も同様に別CodeGearへのポインタである。
 9行目のCodeGearではnextとWhenEmptyと二つのCodeGearのポインタを入力することにより、
-処理の結果に応じた複数の遷移先を用意するように構成している。
+処理の結果に応じた複数の遷移先を用意するように構成している。これによりCbCの例外処理を
+きれいに記述することができる。Javaのtry/catchのような仕組みは必要ない。
 
-Interfaceに加え、ImplementationはDataGearとみなすことができる。
-また、GearsOSでは後述のContextと呼ばれる環境内に全てのDataGearとCodeGearが保持されている。
-Context内ではInterfaceやImplementで定義されたAPIと変数は構造体として記録され、
-またそれら全ての構造体は共用体(union)のData型に登録されている。
-そのため、InterfaceとImplementはDataGearもしくはCodeGearの一時的な保管場所と見なすこともできる。
+Interfaceと同様にImplementationもDataGearである。
+Context内では使用するInterfaceやImplementで定義する
+すべての構造体は共用体(union)のData型に登録されている。
+InterfaceはDataGearもしくはCodeGearの一時的な保管場所で、Implementationは持続的な保管場所である。
+
+実際には CodeGear / DataGear は、Context内ですべて番号で管理されているので、メタ側から
+全部に均等にアクセスすることができる。これにより、OSのプロセス管理、あるいはモデル検査などを
+MetaDataGearであるContextを処理する MetaCodeGearとして定義できる。
 
 
 \section{Implementation}
-GearsOSはInterfaceの実装となるImplementの形定義ファイルが実装されている。
-Implementの定義にはInterfaceと同様にヘッダファイルを記述する。
+GearsOSはInterfaceの実装となるImplementの型定義ファイルが実装されている。
+Implementationの定義にはInterfaceと同様にヘッダファイルを記述する。
 ソースコード\ref{src:SynchronizedQueue.h}にQueueインターフェースの実装の型定義となるSynchronizedQueue.hを示す。
-Implementは実装元のInterfaceを必ず決定する必要があるため、1行目のようにimpl名の後に実装元のInterface名を記述する必要がある。
+Implementationは実装元のInterfaceを必ず決定する必要があるため、1行目のようにimpl名の後に実装元のInterface名を記述する必要がある。
 
-作成したImplementは実装元のInterface名のImpl型として使用することが可能となり、
+作成したImplementationは実装元のInterface名のImpl型として使用することが可能となり、
 Impl内で記述した変数は後述のコンストラクタで行われる処理によって、プログラム上でimpl*型変数\texttt{->}変数名で参照が行えるようになる。
 また、GearsOSは全てのInterface, Implの情報を構造体としてコンパイルする際にContextに記録するため、
 ソースコード中2,3,4行ではImplに別のInterfaceを構造体として記述することで、

--- a/Paper/chapter/abstract.tex	Thu Feb 10 10:03:41 2022 +0900
+++ b/Paper/chapter/abstract.tex	Thu Feb 10 11:28:41 2022 +0900
@@ -1,32 +1,37 @@
 \chapter*{要旨}
-当研究室ではOSの信頼性の検証を目的としたOSであるGearsOSを開発している。GearsOSはユーザレベルとメタレベルを分離して記述を行うことで拡張性と信頼性の補償を目指している。
+
+GearsOSはユーザレベルとメタレベルを分離して記述を行うことで拡張性と信頼性の保証を目指している。
 GearsOSはContinuation based C(以下CbC)で記述されており,Gearというプログラミング概念を持つ。
-GearsOSは現在開発途上であるため、現在は言語フレームワークとして実装されている。OSとして起動するためにこれから実装が必要な機能が多く存在しており、その中の一つとして分散ファイルシステムが挙げられる。
-GearsOSの分散ファイルシステムでは、当研究室が開発している分散フレームワークChristieの仕組みを用いる。
-ChrisitieはGearsOSと異なるGearというプログラミング概念をもち、DataGearManagerというDataPoolをノード間でsocket接続することで通信を実装している。
-GearsOSのファイルはDataGearManagerと同様な構成として、ファイルであると同時に通信処理そのものに相当する。
-本研究ではChristieのDataGearManagerをファイルとして用い、その通信のAPIの構成を行った。
-
-GearsOSのファイルシステムは従来のファイルシステムの問題点を解決した実装を取り込めるような構成にしたい。
-従来のファイルシステムの問題点の一部として、ファイルシステムはデータベースでなくレコード単位での操作が行えない、バックアップや証明書などの機能はアプリケーションに依存している点などが挙げられる。
-将来的な実装を鑑みてファイルシステムの実装を行う。
-
-また、GearsOSを純粋に利用して記述を行うプロジェクトは本研究が初めてとなる。
+GearsOSはx.v6を参考にした実装と、Unix上の言語フレームワークとして実装のがある。
+OSとして重要なものとしてファイルシステムがある。とくにGearsOSでは通信とファイルシステムを同時に扱えるようにし、
+分散ファイルシステムとしても使えるように設計実装している。
+当研究室が開発している分散フレームワークChristieでは DataGearManagerというDataGearのPoolをノード間で接続して通信する。
+これを、GearsOS のファイルAPIの構成に使う。
+DataGearに対して、DGM毎にkeyを使ってTake/Put/Peek を行う。これにより、
+ファイルあるいは通信、つまり分散ファイルシステムを、トランザクションとして扱うことができるようになる。
+従来のファイルシステムではレコード単位の操作をトランザクションするのはOSの機能ではなかった。
+例えばバックアップや証明書などの機能はアプリケーションに依存していた。
+本研究ではGearsOSを用いて単一のDataGearMager通信路を実装して
 分散ファイルシステムの構成を行うと同時に、GearsOSの言語フレームワークとしての評価と検討を行った。
+また、これは GearsOSのアプリケーション実装の例としても見ることできる。
 
 
 \chapter*{Abstract}
-In our laboratory, we are developing GearsOS, an operating system for verifying the reliability of operating systems, which aims to compensate for scalability and reliability by separating user-level and meta-level descriptions.
-GearsOS is written in Continuation based C (CbC) and has the programming concept of Gears.
-Since GearsOS is still under development, it is currently implemented as a language framework, and there are many functions that need to be implemented in order to run as an OS, one of which is a distributed file system.
-The distributed file system of GearsOS uses the distributed framework Christie, which is developed by our laboratory.
-Christie has a different programming concept called "Gear" from GearsOS, and implements communication by connecting a DataPool called DataGearManager to a socket between nodes.
-The files in GearsOS are structured in the same way as DataGearManager, so that they are not only files but also correspond to the communication process itself.
-In this study, we used Christie's DataGearManager as a file and configured the API for its communication.
 
-The file system of GearsOS should be configured in such a way that it can incorporate implementations that solve the problems of conventional file systems.
-Some of the problems with conventional file systems are that they are not databases and cannot be manipulated on a record-by-record basis, and that functions such as backup and certificates are dependent on the application.
-The file system will be implemented in view of future implementations.
+GearsOS is an operating system designed to guarantee scalability and reliability by separating user-level and meta-level descriptions.
+GearsOS is written in Continuation based C (CbC) and has a programming concept called Gear.
+There are two implementations of GearsOS, one based on x.v6 and the other as a language framework on Unix.
+An important part of the OS is the file system. 
+In particular, GearsOS is designed and implemented so that it can handle communication and file system at the same time, 
+and can be used as a distributed file system.
+In the distributed framework Christie developed in our laboratory, a DataGearManager, 
+a pool of DataGear, is connected between nodes for communication.
+This is used to configure the file API of GearsOS.
+Take/Put/Peek is performed on DataGear using a key for each DGM. 
+The file or communication, or distributed file system, can be handled as a transaction.
+In the conventional file system, it is not a function of the OS.
+For example, such as backup and certificates were functions of applications.
+We implemented a single DataGearMager communication channel using GearsOS and
+evaluated GearsOS as a language framework.
+This can also be seen as an example of an application implementation of GearsOS.
 
-In addition, this research is the first project that purely uses GearsOS for description.
-While constructing the distributed file system, we also evaluated and examined GearsOS as a language framework.