--- a/final_main/chapter3.tex	Sat Feb 15 00:01:24 2020 +0900
+++ b/final_main/chapter3.tex	Sat Feb 15 01:45:22 2020 +0900
@@ -31,8 +31,5 @@
     \label{fig:interface}
 \end{figure}
 
-%\section{}
-
+Interface の定義で示されている CodeGear と実装側で実装されている CodeGear は対応しており、実装側で実装する CodeGear は必ず Interface で定義されている必要がある。
 
-
-%\section{}

--- a/final_main/chapter4.tex	Sat Feb 15 00:01:24 2020 +0900
+++ b/final_main/chapter4.tex	Sat Feb 15 01:45:22 2020 +0900
@@ -48,58 +48,40 @@
 %FileSystemの構造よりも重要だからこっちの方のを優先的に説明したい！
 \begin{itemize}
   \item readsb
-  \\ブロックのファイルサイズやデータブロックの数、inodeの数、log 中のブロック数などが格納されている super block を読み込む。
-  
+  \\ブロックのファイルサイズやデータブロックの数、inodeの数、log 中のブロック数などが格納されている Disk 階層の super block を読み込む。
   \item iinit
-
+  \\
   \item ialloc
   \\デバイスで指定されたタイプを新しい inode に割り当てる。
-    
   \item iupdate
   \\変更されたメモリ内の inode をディスクにコピーする。
-  
   \item idup
   \\IPの参照カウントをインクリメントする。
-  
   \item ilock 
   \\指定した inode をロックする。またその際に必要であるならば、ディスクから inode を読み込む。
-  
   \item iunlock
   \\指定された inode のロックを解除する。
-  
   \item iput
   \\メモリ内の inode への参照を削除する。
-  %それが最後の参照であった場合、iノードキャッシュエントリはリサイクルできます。それが最後の参照であり、iノードにリンクがない場合、ディスク上のiノード（およびそのコンテンツ）を解放します。
-  
   \item iunlockput
   \\指定された inode のロックを解除してから iput を実行する。
-  %後でまとめる
-  
   \item stati
   \\inode から ファイルに関する統計情報を複製する。
-  
   \item readi
-  \\inode からデータを読み込む。
-   
+  \\inode からデータを読み込む。 
   \item writei
   \\inode へデータを書き込む。
-
   \item namecmp
-  
-  
+  \\
   \item dirlookup
   \\ディレクトリ内のディレクトリエントリを探す。
-%見つかった場合は、* poffをエントリのバイトオフセットに設定します。
-  
   \item dirlink
   \\新しいディレクトリエントリ（名前、inum）をディレクトリdpに書き込む。
-  
   \item namei
-
-  
+  \\
   \item nameiparent
-
-  
+  \\
 \end{itemize}
-
+%namecmp、dirlookup、dirlookup、dirlink、namei、nameiparent は/usr/rtm/xv6/fs.cのような階層的なパスを管理、操作するための API である。
+ilock で inode をロックした場合必ず処理の終わりには iunlock が呼び出され inode のロックを解除する必要があるように、readi でinode からデータを読み込んだり iwrite で inode へデータを書き込む場合も iput で inode を参照必要がある。このように、FileSystem の API は実行される際様々な API 同士が影響を及ぼしあっているため複雑な挙動をしている。
 これらの API の CbC による書き換えを次章で説明する。

Binary file final_main/main.pdf has changed

Binary file final_sub/utf8.pdf has changed

--- a/final_sub/utf8.tex	Sat Feb 15 00:01:24 2020 +0900
+++ b/final_sub/utf8.tex	Sat Feb 15 01:45:22 2020 +0900
@@ -51,22 +51,37 @@
 \captionsetup[lstlisting]{font={small, tt}}
 
 
-
+\renewcommand{\abstractname}{Abstract}
 \begin{document}
 \title{CbC による xv6 の FileSystem の書き換え}
 \author{学籍番号 : 165723C 氏名 : 坂本昂弘 {}{} 指導教員 : 河野真治}
 \date{2020年2月17日}
+\twocolumn[
 \maketitle
 \thispagestyle{fancy}
+\centering
+\begin{onecolabstract}
+The OS is required to guarantee reliability and expandability. The Gears OS is being developed using Continuation based C (CbC) with the goal of guaranteeing reliability for normal-level computations and realizing scalability with meta-level computations.
+CbC uses a basic processing unit called Code Gear and a data unit called Data Gear. Code Gear of normal level and meta level can be described for detailed processing, and transition between CodeGear can be performed without stacking values. For Code Gear, there is an input Data Gear and an output Data Gear, and reliability is assured by checking whether the expected output is produced for the input.
+CbC's Interface is a mechanism for modularizing Gears OS. This Interface corresponds to Java Interface and Haskell type class, and can be described separately by specification and implementation by introducing. By using Interface, it is possible to expand by verification and replacement of functions.
+As a pre-stage, it rewrites xv6, which is a simple operating system that has the basic structure of Unix such as process, virtual memory, separation of kernel and user, interrupt, file system, etc., with CbC.
+In this paper, we aim to clarify the complicated FileSystem by rewriting the FileSystem of xv6 by CbC, guarantee the reliability, and realize scalability by using Interface.
 
-\section{xv6 の OS の信頼性保証}
+\end{onecolabstract}]
 
+
+\section{OS に対する信頼性の保証}
+OS には信頼性の保証と拡張性の実現が求められている。信頼性をノーマルレベルの 計算に対して保証し、拡張性をメタレベルの計算で実現することを目標に Continuation based C (CbC) を用いて Gears OS を開発中である。
+CbC は Code Gear という基本的な処理の単位と Data Gear というデータの単位を用いる。細かい処理に対してノーマルレベルとメタレベルの Code Gear を記述し、stack に 値を積む事なく CodeGear 間を遷移することができる。Code Gear に対して入力の Data Gear と 出力の Data Gear が存在し、入力に対して期待される出力がされてるか検査することで信頼性を保証する。
+CbC の Interface は Gears OS のモジュール化の仕組みである。この Interface は、Java の Interface や Haskell の型クラスに対応し、導入することで仕様と実装に分けて記述することが出来る。Interface を使うことで検証や機能の入れ替えによる拡張が可能となる。
+前段階としてシンプルであるがプロセス、仮想メモリ、カーネルとユーザーの分離、割り込み、ファイルシステムなど Unix の基本的な構造を持っている OS である xv6 を CbC で書き換えている。
+本論文では、xv6 の FileSystem を CbC によって書き換えることにより 複雑な処理である FileSystem を明確化させ信頼性を保証、 Interface を使用可能とすることで拡張性を実現することを目標とする。
 \section{xv6}
-xv6\cite{xv6}とはMITのオペレーティングコースの教育目的で2006年に開発されたオペレーティングシステムである。
+xv6とはMITのオペレーティングコースの教育目的で2006年に開発されたオペレーティングシステムである。
 xv6 はオリジナルである v6 が非常に古いC言語で書かれている為、ANSI-C に書き換えられ x86 に再実装された。 xv6 は read や write などの systemcall、プロセス、仮想メモリ、カーネルとユーザーの分離、割り込み、ファイルシステムなど Unix の基本的な構造を持っている。
 
 \section{Continuation based C}
-xv6 kernel 上で interface を実装する際、当研究室で開発されたプログラミング言語 Continuation based C \cite{cbc}(以下 CbC)を用いる。
+xv6 kernel 上で interface を実装する際、当研究室で開発されたプログラミング言語 Continuation based C (以下 CbC)を用いる。
 CbC は基本的な処理単位を CodeGearとして定義し、CodeGea間で遷移するようにプログラムを記述する C 言語と互換性のあるプログラミング言語である。
 CodeGearは返り値を持たない為、関数内で処理が終了すると呼び出し元の関数に戻ることがなく別の CodeGear へ遷移する。
 以下の Code1 に CodeGear 遷移時のコード例を示す。
@@ -97,9 +112,34 @@
 
 
 \section{CbC による xv6 FileSystem の書き換え}
+FileSystem は複雑な処理を行っている。そのため xv6 の FileSystem 部にInterface を定義、実装してやることにより OS の信頼性が向上すると考えた。本研究で定義した FileSystem の Interface とその実装について図\ref{fig:fsfilesystem}に示した。
+
+\begin{figure}[ht]
+     \begin{center}
+     \includegraphics[width=80mm]{pic/fsInterface.pdf}
+     \end{center}
+     \caption{xv6 FileSystem の Interface と実装}
+    \label{fig:fsfilesystem}
+\end{figure}
+
+書き換え方針は、if 文の中に if 文がある場合や for 文がある場合には処理を細かく分離してやり分 かりやすくする。また、CbC の Interface を用いることにより仕様と実装を分離し拡張性を実現することを目標に行った。
+
+書き換えたコードおよび書き換え部分が多いため全ては載せることができないため、具体的に FileSystem のialloc という関数の処理を書き換えた場合どのようになったか図\ref{fig:iallocloop}に示す。
+
+\begin{figure}[ht]
+     \begin{center}
+     \includegraphics[width=80mm]{pic/iallocloop.pdf}
+     \end{center}
+     \caption{allocinode の ループによる遷移図}
+    \label{fig:iallocloop}
+\end{figure}
+
+ialloc の処理は、iallocfs impl からの受け皿としての allocinode、for 文のループ条件を確認 する allocinode\_loopcheck、ループした際の処理をする allocinode\_loop、ループから抜け た際の処理をする allocinode\_noloop の 4 つの CodeGear から成り立ち。 ループの 条件に当てはまらない際は panic へと処理が移り処理が停止するように書き換えた。
+本論文では ialloc\_impl という関数を取り上げて説明したが、FileSystem が記述されている fs.c で定義されている関数に関しては全て CbC を用いることにより状態遷移ベースに 書き変え挙動を明確化した
 
 \section{まとめと今後の課題}
-
+ 本研究では xv6 の FileSystem 部分について CbC を用いて書き換えを行った。実際に FileSystem を CbC で書き換えることによって、複雑であった処理の流れを明確にすることができた。さらに、FileSystem を Interface とその実装に書き換えることによって仕様と実装に分けることができた。仕様と実装に分けることによって拡張性を高めることができた。しかし、xv6 は Gears OS を開発する前段階として開発しているので今後は書き換えた xv6 を Gears OS に適応した形に改良していく必要がある。xv6 の FileSystem 部分書き換え後 、デバックをまだ行っていないため正常に動くかどうか確認することが求め られる。また、正常に動作しなかった場合は修正を行い、OS として機能しているか再確認する必要がある。
+今後の課題として、現段階では FileSystem と Paging などの kernel の一部のみ書き換えられているため kernel 全体の書き換えを完了させる必要がある。また、書き換えにより実装した xv6 が実機上で動作するか確認する必要がある。
 \thispagestyle{fancy}
 %\begin{thebibliography}{9}