--- a/paper/anatofuz-sigos.md	Tue May 05 14:41:53 2020 +0900
+++ b/paper/anatofuz-sigos.md	Tue May 05 14:55:01 2020 +0900
@@ -128,6 +128,8 @@
 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。
 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。
 
+本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、　仮想メモリなどのOSの根幹部分でそれぞれ行った。
+
 
 # xv6のシステムコールの継続の分析
 xv6の処理を継続を中心とした記述で再実装を行う。
@@ -140,14 +142,18 @@
 
 CbCで再実装した`read`システムコールは、 xv6の`read`システムコールのディスパッチ部分から、 `cbc_read`CodeGearに`goto`文で軽量継続される。
 継続後はreadする対象によって`cbc_readi`や、 `cbc_consoleread`などに状態が変化していく。
+各CodeGearの遷移時にはDataGearがやり取りされる。
+DataGearはxv6のプロセス構造体に埋め込まれたcontextを経由してCodeGearに渡される。
+
 この実装の利点として、 CodeGearの命名と状態が対応しており、 状態遷移図などに落としても自然言語で説明が可能となる点が挙げられる。
 しかし実際には`cbc_readi`の状態はさらに複数のCodeGearに分離しており、 実際に`read`システムコールを実装するCodeGearの数は図の状態より多い。
 この事から、 複数のCodeGearを1つにまとめた上で見た状態と、 各CodeGearそれぞれの状態の2種類の状態があるといえる。
 
 信頼性を向上させる観点から見ると、　複数のCodeGearをまとめた状態は実装した関数を組み合せてアルゴリズムに問題が無いかの確認として使用出来る。
 対して各CodeGearそれぞれはモデル検査や、 特定の関数の中の処理が適しているかどうかの検査として見ることが出来ると考えられる。
-この事からGearsOSでは、 各CodeGearのモジュール化の仕組みであるInterface機能を導入した。
 
+この事からGearsOSでは、 各CodeGearのモジュール化の仕組みであるInterface機能を導入している。
+Interfaceの導入によってCodeGearを定義することで状態数を増やしても、 抽象化されたAPIを利用することで細部の状態まで意識する必要が無くなった。
 
 # xv6のシステムコール以外の継続の分析
 

Binary file paper/anatofuz-sigos.pdf has changed

--- a/paper/anatofuz-sigos.tex	Tue May 05 14:41:53 2020 +0900
+++ b/paper/anatofuz-sigos.tex	Tue May 05 14:55:01 2020 +0900
@@ -228,6 +228,8 @@
 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。
 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。
 
+本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、　仮想メモリなどのOSの根幹部分でそれぞれ行った。
+
 
 \section{xv6のシステムコールの継続の分析}
 xv6の処理を継続を中心とした記述で再実装を行う。
@@ -246,14 +248,18 @@
 
 CbCで再実装した\texttt{read}システムコールは、 xv6の\texttt{read}システムコールのディスパッチ部分から、 \texttt{cbc\_read}CodeGearに\texttt{goto}文で軽量継続される。
 継続後はreadする対象によって\texttt{cbc\_readi}や、 \texttt{cbc\_consoleread}などに状態が変化していく。
+各CodeGearの遷移時にはDataGearがやり取りされる。
+DataGearはxv6のプロセス構造体に埋め込まれたcontextを経由してCodeGearに渡される。
+
 この実装の利点として、 CodeGearの命名と状態が対応しており、 状態遷移図などに落としても自然言語で説明が可能となる点が挙げられる。
 しかし実際には\texttt{cbc\_readi}の状態はさらに複数のCodeGearに分離しており、 実際に\texttt{read}システムコールを実装するCodeGearの数は図の状態より多い。
 この事から、 複数のCodeGearを1つにまとめた上で見た状態と、 各CodeGearそれぞれの状態の2種類の状態があるといえる。
 
 信頼性を向上させる観点から見ると、　複数のCodeGearをまとめた状態は実装した関数を組み合せてアルゴリズムに問題が無いかの確認として使用出来る。
 対して各CodeGearそれぞれはモデル検査や、 特定の関数の中の処理が適しているかどうかの検査として見ることが出来ると考えられる。
-この事からGearsOSでは、 各CodeGearのモジュール化の仕組みであるInterface機能を導入した。
 
+この事からGearsOSでは、 各CodeGearのモジュール化の仕組みであるInterface機能を導入している。
+Interfaceの導入によってCodeGearを定義することで状態数を増やしても、 抽象化されたAPIを利用することで細部の状態まで意識する必要が無くなった。
 
 \section{xv6のシステムコール以外の継続の分析}