Binary file Paper/figs/cgdg.pdf has changed

--- a/Paper/paper.tex	Mon May 02 15:46:24 2022 +0900
+++ b/Paper/paper.tex	Tue May 03 13:52:01 2022 +0900
@@ -104,7 +104,7 @@
 GearsOSは，OSの信頼性を定理証明やモデル検査を行うことで保証することを目指している\cite{modelcheck}．
 同じく，当研究室で開発しているプログラム言語であるCbC(Continuation based C)で記述されており，
 ノーマルレベルとメタレベルを簡単に切り分けることを可能としている．
-CbCでメタレベルの処理を切り出したものに対して，定理証明やモデル検査を行うことで信頼性を保証する．
+そのようにして，CbCでメタレベルの処理を切り出したものに対して，定理証明やモデル検査を行うことで信頼性を保証する．
 
 GearsOSは現在OSとして重要な機能がいくつか未実装であり，その一つとしてファイルシステムが挙げられる．
 ファイルシステムはファイルやディレクトリといった構造を持ち，データの保存，整理を行う．
@@ -116,7 +116,7 @@
 同様に，inodeの仕組みを用いてGearsOSのファイルシステムを実装したい．
 また，インターフェースについても，cd，ls，mkdirというようにUnix likeに実装したい．
 当研究室ではxv6のCbCでの書き換えを行なっているが，今回はxv6のルーチンをCbCで書き換えるのではなく
-GearsOSへUnixのFile systemの仕組みを取り入れるアプローチをとりたい．
+GearsOSへUnixのファイルシステムの仕組みを取り入れるアプローチをとりたい．
 それはGearsOSとCbCで書き換えたxv6の比較や，互いにファイルシステムの機能の移植が行える様にするためである．
 また，当研究室で開発している分散フレームワークChristieの仕組みを用いて，分散ファイルシステムを実装したい．
 
@@ -126,16 +126,16 @@
 CbCでは関数の代わりにCodeGearという単位でプログラミングを行う．
 CodeGearは\emph{\_\_code}という記述で宣言することができる．
 また，データの単位にはDataGearと呼ばれる変数データを用いる．
-図\ref{fig:dgcg}はCodeGearとDataGearの関係を表している．
+図\ref{fig:dgcg}はCodeGearと入出力の関係を表している．
 CodeGearはDataGearを入力として受け取り，別のDataGearに書き込み出力することができる．
-特に入力のDataGearをInput DataGear，出力のDataGearをOutput DataGearと呼ぶ．
-gotoで次のCodeGearに遷移することができ，その際Output DataGearを次のCodeGearのInput DataGearとして渡すことができる．
+特に，入力のDataGearをInput DataGear，出力のDataGearをOutput DataGearと呼ぶ．
+gotoで次のCodeGearに遷移することができ，その際，Output DataGearを次のCodeGearのInput DataGearとして渡すことができる．
 
 \begin{figure}[ht]
   \begin{center}
-      \includegraphics[width=80mm]{figs/dgcgdg.png}
+      \includegraphics[width=80mm]{figs/cgdg.pdf}
   \end{center}
-  \caption{CodeGearとDataGearの関係}
+  \caption{CodeGearと入出力の関係図}
   \label{fig:dgcg}
 \end{figure}
 
@@ -145,41 +145,22 @@
 他方，CbCの継続はfunction callをせずにgotoによるjmpで行われる．
 jmpはfunction callと異なり，call stackのような環境を保存しない．
 よって，CbCのgotoによる継続はfunction callによる継続と比較して軽量であるといえる．
-そのことからCbCにおける継続をfunction callにおける継続と区別して，軽量継続と呼ぶ．
+そのことから，CbCにおける継続をfunction callによる継続と区別して，軽量継続と呼ぶ．
 これらの仕組みにより，ノーマルレベルとメタレベルの処理を容易に切り分けることが可能となる．
 
 \section{GearsOS}
 
-GearsOS\cite{gears,gearsos,cr}は 信頼性と拡張性の両立を目的として，開発されている．
-Gearという概念があり，実行の単位をCodeGear，データの単位をDataGearと呼ぶ．
+GearsOS\cite{gears,gearsos,cr}は当研究室で開発している，信頼性と拡張性の両立を目的としたOSである．
+GearsOSにはGearという概念があり，実行の単位をCodeGear，データの単位をDataGearと呼ぶ．
 軽量継続を基本とし，stackを持たない代わりに全てをContext経由で実行する．
-ノーマルレベルとメタレベルの処理を切り分けることができ，同様にGearの概念を持つCbC(Continuation based C)で記述されている．
-GearsOSは現在開発途上であり，OSとして動作するために今後実装しなければならない機能がいくつか残っている．
-
-図\ref{fig:meta-cgdg}はCodeGearの遷移とMetaCodeGearの関係を表している．
-OSのプログラムはユーザーが実際に行いたい処理を表現するノーマルレベルと，
-カーネルが行う処理を表現するメタレベルが存在する．
-ノーマルレベルで見るとCodeGearがDataGearを受け取り，
-処理後にDataGearを次のCodeGearに渡すという動作をしているように見える．
-実際にはデータの整合性の確認や資源管理などのメタレベルの処理が存在し，
-それらの計算はMetaCodeGearで行われる．
-その際，MetaCodeGearに渡されるDataGearのことは特にMetaDataGearと呼ばれる．
-CodeGearの前に実行されるMetaCodeGearは特にstubCodeGearと呼ばれ，
-メタレベルを含めるとstubCodeGearとCodeGearを交互に実行する形で遷移していく．
-\begin{figure}[ht]
-  \begin{center}
-      \includegraphics[width=80mm]{figs/meta-cg-dg.pdf}
-  \end{center}
-  \caption{CodeGearとMetaCodeGearの関係}
-  \label{fig:meta-cgdg}
-\end{figure}
+同様にGearの概念を持つCbC(Continuation based C)で記述されており，ノーマルレベルとメタレベルの処理を切り分けることが容易である．
+また，GearsOSは現在開発途上であり，OSとして動作するために今後実装しなければならない機能がいくつか残っている．
 
 ContextはGearsOS上全てのCodeGear，DataGearの参照を持ち，CodeGearとDataGearの接続に用いられる．
 OS上の処理の実行単位で，従来のOSにおけるプロセスに相当する機能であるといえる．
-CodeGearをDataGearの一種であると考えると，
-ContextはGearの概念ではMetaDataGearに当たる．
+また，CodeGearをDataGearの一種であると考えると，ContextはGearの概念ではMetaDataGearに当たる．
 Contextはノーマルレベルから直接参照されず，必ずMetaDataGearとしてMetaCodeGearから参照される．
-ノーマルレベルのCodeGearがContextを直接参照してしまうと，
+それは，ノーマルレベルのCodeGearがContextを直接参照してしまうと，
 メタレベルを切り分けた意味がなくなってしまうためである．
 
 図\ref{fig:context}はContextを参照する流れを表したものである．
@@ -198,11 +179,29 @@
   \label{fig:context}
 \end{figure}
 
+図\ref{fig:meta-cgdg}はCodeGearの遷移とMetaCodeGearの関係を表している．
+OSのプログラムはユーザーが実際に行いたい処理を表現するノーマルレベルと，
+カーネルが行う処理を表現するメタレベルが存在する．
+ノーマルレベルで見るとCodeGearがDataGearを受け取り，
+処理後にDataGearを次のCodeGearに渡すという動作をしているように見える．
+しかしながら，実際にはデータの整合性の確認や資源管理などのメタレベルの処理が存在し，
+それらの計算はMetaCodeGearで行われる．
+その際，MetaCodeGearに渡されるDataGearのことは特にMetaDataGearと呼ばれる．
+また，CodeGearの前に実行されるMetaCodeGearは特にstubCodeGearと呼ばれ，
+メタレベルを含めるとstubCodeGearとCodeGearを交互に実行する形で遷移していく．
+\begin{figure}[ht]
+  \begin{center}
+      \includegraphics[width=80mm]{figs/meta-cg-dg.pdf}
+  \end{center}
+  \caption{CodeGearとMetaCodeGearの関係}
+  \label{fig:meta-cgdg}
+\end{figure}
+
 \section{Christie}
 
 Christieは当研究室で開発を行っているJavaで記述された分散フレームワークである\cite{christie}．
 GearsOSの分散ファイルシステムを構築する際に用いる．
-CbCと似ているが別物のGearという概念や，任意のTopologyを形成するためのTopologyManagerがある．
+これには，CbCと似ているが別物のGearという概念や，任意のTopologyを形成するためのTopologyManagerがある．
 
 Christieには以下の4つのGearという概念が存在する．
 
@@ -213,88 +212,59 @@
   \item DataGearManager（以下DGM）
 \end{itemize}
 
-CodeGearはクラスやスレッドに相当する．DataGearは変数データに相当し，Javaのアノテーションを用いて記述される．
+CodeGearはクラスやスレッドに相当する．また，DataGearは変数データに相当し，Javaのアノテーションを用いて記述される．
 CGMはいわゆるノードに相当し，CodeGear，DataGear，DGMを管理する．
-複数のCGM同士が配線され，DataGearを送信し合うことで分散処理を実現している．
-DGMはDataGearを管理しているもので変数プールに相当する．
+このCGM同士が配線され，DataGearを送信し合うことで分散処理を実現している．
+DGMはDataGearを管理しているもので，変数プールに相当する．
 
 DataGearManagerはkey value storeの構造を持つ．
 CGMが利用するCGのkeyとputされたDataGearの組み合わせでDataGearを管理する．
-DGMはLocalDGMとRemoteDGMに区別することができる．
+また，DGMはLocalDGMとRemoteDGMに区別することができる．
 LocalDGMはCGM自身が所持するDataGearのプールである．
 ReomoteDGMはCGMが配線されている別のCGMがもつDGのプールである．
 
 \section{Unixのファイルシステム}
 
-UnixのFile systemはBTreeとinodeで構成されており，xv6もその仕組みを用いている．
-
+UnixのファイルシステムはBTreeとinodeで構成されており，xv6もその仕組みを用いている．
 xv6\cite{xv6}はMITで教育用の目的で開発されたOSで，Unixの基本的な構造を持つ．
 当研究室ではxv6のCbCでの書き換え，分析を行なっている\cite{xv6component,xv6kernel}．
-xv6はUnix系のOSであるため，File systemでは\emph{inode}の仕組みが用いられている．
 
-主にUnix系のファイルシステムで用いられる，ファイルの属性情報が書かれたデータである．
-inodeにおけるファイルの属性情報は表\ref{table:inode}のようなものがある．
-またinodeは識別番号としてinode numberを持つ．
+inodeは主にUnix系のファイルシステムで用いられる，ファイルの属性情報が書かれたデータである．
+inodeにおけるファイルの属性情報はFile Type，Permissions，File Sizeなどが上げられる．
+また，inodeは識別番号としてinode numberを持つ．
 inode numberは一つのファイルシステム内で一意の番号であり，\emph{ls -i}コマンドで確認可能である．
 inodeはファイルシステム始動時にinode領域をディスク上に確保する．
-そのためinode numberには上限があり，それに伴いファイルシステム上で扱えるファイル数の上限も決まる．
+そのため，inode numberには上限があり，それに伴いファイルシステム上で扱えるファイル数の上限も決まる．
 inode numberの最大値は\emph{df -i}コマンドで確認可能である．
 
-\begin{table}[htpb]
-  \begin{center}
-    \small
-    \begin{tabular}[htpb]{|c||c|}
-      \hline
-      File Types & directoryやregular fileなど，ファイルの種類 \\
-      \hline
-      Permissions & read write executeの実行可否\\
-      \hline
-      UID & ファイル所有者のID \\
-      \hline
-      GID & ファイル所有グループのID \\
-      \hline
-      File Size & ファイルのサイズ \\
-      \hline
-      Time Stamps & ファイル作成，編集日時 \\
-      \hline
-      Number of link & ハードリンクの数 \\
-      \hline
-      Location on hard disk & データのアドレス\\
-      \hline
-    \end{tabular}
-    \caption{inodeでのファイル属性情報}
-    \label{table:inode}
-  \end{center}
-\end{table}
-
 \section{GearsFileSystemにおけるディレクトリの構成}
 
 当研究室ではxv6のCbCでの実装を行なっているが，今回はxv6のFileルーチンをCbCで書き換えるのではなく
-GearsOSへUnixのFile systemの仕組みを取り入れるアプローチをとる．
-ファイルシステムを大まかにディレクトリシステムとファイルの二つに分けて考える．
+GearsOSへUnixのファイルシステムの仕組みを取り入れるアプローチをとる．
+まず，ファイルシステムを大まかにディレクトリシステムとファイルの二つに分けて考える．
 ディレクトリシステムはUnixのinodeの仕組みを取り入れる．
 今回作成した，GearsOSのディレクトリシステムであるgearsDirectoryについて説明する．
-ファイルについては次章で述べる．
+ファイルについては後の章で述べる．
 
 FileSystemTreeはdirectory構造，inodeの仕組みを取り入れる際に用いるTreeである．
 ソースコード\ref{src:ftree}はFileSystemTreeのinterfaceである．
 gearsOSにおけるinterfaceはCodeGearと各CodeGearが用いるI/O DataGearの集合を記述する．
-FileSystemTreeのinterfaceはfTreeとnodeのDataGearとput，get，remove，nextのCodeGearを持つ．
+よって，FileSystemTreeのinterfaceはfTreeとnodeのDataGearとput，get，remove，nextのCodeGearを持つ．
 FileSystemTreeのfTreeはgearsOSの永続データを構築する際に使用されるRedBlackTreeであり，put，get，removeはRedBlackTreeの操作を行うためのCodeGearである．
-nextは遷移先のCodeGearを参照するために用いる．
+また，nextは遷移先のCodeGearを参照するために用いる．
 \lstinputlisting[caption=FTreeのinterface,label=src:ftree]{src/FTree.h}
 
 ディレクトリ構造は2つのFileSystemTreeで実装する．
 1つ目はinode numberとfileのポインタのペアを持つ木である．
-inode numberをkey，inodeをvalueとして持つためinode numberからinodeを検索するために用いる(以下，inode treeとする)．
+それは，inode numberをkey，inodeをvalueとして持つためinode numberからinodeを検索するために用いる(以下，inode treeとする)．
 2つ目はfilenameとinode numberのペアを持つ木である．
-filenameをkey, inode numberをvalueとして持つため，filenameからinode numberを検索するために用いる．
-これはinodeをfilenameで検索するためのindex treeであるといえる(以下，index treeとする)．
+それは，filenameをkey, inode numberをvalueとして持つため，filenameからinode numberを検索するために用いる．
+また，inodeをfilenameで検索するためのindex treeであるといえる(以下，index treeとする)．
 
 図\ref{fig:inode}はindex treeを用いたinodeの検索の流れを表す．
 まずindex treeからkeyがfilenameのnodeをgetする．
-keyがfilenameのnodeのvalueよりinode numberががわかる．
-次に取得したinode numberをkeyとしてinode treeを検索する．
+keyがfilenameのnodeのvalueよりinode numberがわかる．
+次に，取得したinode numberをkeyとしてinode treeを検索する．
 keyがinode numberのnodeはvalueとしてinodeを持っていて，inodeを参照することができる．
 
 \begin{figure}[ht]
@@ -305,7 +275,9 @@
   \label{fig:inode}
 \end{figure}
 
-ファイルやディレクトリの操作を行うinterfaceをUnix Likeに実装を行った．
+\section{GearsFileSystemにおけるインターフェース}
+
+ファイルやディレクトリの操作を行うインターフェースをUnix Likeに実装を行った．
 実装を行ったmkdir, ls, cdを説明する．
 
 \subsection{mkdir}