Binary file Paper/paper.pdf has changed

--- a/Paper/paper.tex	Wed May 05 18:43:47 2021 +0900
+++ b/Paper/paper.tex	Thu May 06 00:00:26 2021 +0900
@@ -101,22 +101,29 @@
 ChrsitieはGearsOSのもつGearという概念とよく似た, 別のGearというプログラミング概念を持っており, DataGearと呼ばれる変数データを接続されたノード同士が送信しあうことで分散処理を簡潔に記述することができる. DataGearは指定された型と名前を持つkeyに対応しており, プログラムが必要なkeyにデータが揃ってから初めてプログラムが処理される.
 また, ChrisiteはTopologyManagerと呼ばれる機能を持っており, 任意の形でノード同士の配線を行いTopologyを形成する機能を持っている. 
 
-
-%2
-\section{現代のファイルシステムについて}
-従来のオープンソース分散ファイルシステムソフトウェアとしてCephやGlusterFSなどが挙げられる. 
-
-CephはRADOSと言うストレージクラスタを持ち, RADOSはモニタとOSD(Object Storage Device)の二つで構成されている. モニタはストレージクラスタの構成情報であるクラスタマップをもとにOSDの構成, クラスタ管理, 情報監視を行っている. OSDはハードディスクやRAIDと1対1で対応しており, オブジェクトの配置管理, 実ストレージ へのデータ読み書き, データの冗長化を行っている. Cephは外部インターフェースであるCephFSによりアクセスすることによりファイルでのアクセスを可能にしているが, 同様にオブジェクト, ブロックでのアクセスにも対応している. また, オブジェクトへのアクセスを提供するライブラリLIBRADOSは複数の言語に対応している. 
+GearsOSの分散処理の記述方式としてChristieの仕組みを取り入れることにより, 分散ファイルシステムを構成したい. 
 
 
-%2.1
+\section{UNIXファイルシステムについて} 
+UNIXファイルシステムはUNIX系OSを始めとした多くのOSのファイルシステムの大元となっている.
+
+UNIXファイルシステムではファイルに構造を持たず,  カーネルがファイルを単純なバイト配列とみなして処理が行われ, ファイルの実際の取り扱いはプログラムが判断する.
+ユーザの視点ではファイルを取り扱う際に, OSレベルの観点からファイルを構成する必要がなく, ファイルの拡張子を任意のアプリケーションに適したものにするだけで良い. 
+全てのファイルはi-nodeと呼ばれるユニークな番号をもち, ファイルのメタデータは全てi-node内に格納されている. i-nodeはファイルの探索の際などに用いられ, ユーザはstat()と呼ばれるシステムコール により共通的にファイル情報を得ることができる.
+
+また,UNIXは階層型の仮想ファイルシステムを搭載している.  
+ネットワークを経由してファイルシステムにアクセスする際は, 木構造に構成されたディレクトリTree にリモート先のファイルシステムをマウントすることにより参照することができる. 
+
+UNIXbaseのファイルシステムを比較・検討をしながらGearsOSを構成していく. 
+
+
+
 \section{Continuation based C}
 GearsOSはC言語の下位言語であるContinuation based Cを用いて記述されている. CbCは関数呼び出しでなく, 継続を導入しており, スタック領域を用いずjmp命令でコード間を移動することにより軽量な継続を実現している. CbCではこの継続を用いてfor文などのループの代わりに再起呼び出しを行う. 実際のOSやアプリケーションを記述する際にはGCCまたはLLVM/clangのCbC実装を用いる.
 
 CbCでは関数の代わりにCodeGearという単位でプログラミングを行う. CodeGearは\texttt{\_\_code}で宣言を行い, 各CodeGearはDataGearと呼ばれる変数データを入力として受け取り, その結果を別のDataGearに書き込む. 特に入力のDataGeatをInputDataGear, 出力されるDataGearを OutputDataGearと呼ぶ. CodeGearとDataGearの関係図を図\ref{fig:cgdg}に示す. 
 CodeGearは関数呼び出しのスタックを持たないため, 一度CodeGearを遷移すると元の処理に戻ってくることができない. 
 
-CbCコードの例をソースコード\ref{src:cbc_example}に示す．%refを使う
 
 \begin{figure}[tb]
     \begin{center}
@@ -126,28 +133,28 @@
     \label{fig:cgdg}
 \end{figure}
 
-\begin{lstlisting}[frame=lrbt,label=src:cbc_example,caption={CbCの例題}]
-void syscall(void)
-#include <stdio.h>
-__code CG2(){
-  int i = 10;
-  printf("i = %d\n", i);
-}
+CbCコードの例をソースコード\ref{src:cbc_example}に示す．%refを使う
+この例題では特定のシステムコールの場合, CbC で実装された処理に goto 文をつかって継続する. 
+例題では CodeGear へのアドレスが配列 cbccodes に格納されている. 引数として渡している\texttt{cbc\_ret}は, システムコールの返り値の数値をレジスタへ代入する CodeGear である. 実際に\texttt{cbc\_ret} に継続が行われるのは、 read などのシステムコールの一連の処理の継続が終わったタイミングである. 
 
-__code CG1(){
-  printf("Hello\n");
-  goto CG2();
-}
+\begin{lstlisting}[frame=lrbt,label=src:cbc_example,caption={CbCを利用したシステムコールのディスパッチ}]
+void syscall(void)
+{
+    int num;
+    int ret;
 
-int main(){
-  goto CG1();
-}
+    if((num >= NELEM(syscalls)) && (num <= NELEM(cbccodes)) && cbccodes[num]) {
+        proc->cbc_arg.cbc_console_arg.num = num;
+        goto (cbccodes[num])(cbc_ret);
+    }
+\end{lstlisting}
 
-\end{lstlisting}
+Code\ref{src:cbc_example}の状態遷移図を図\ref{fig:dispatch}に示す。
+図中の\texttt{cbc\_read}などは、 \texttt{read}システムコールを実装しているCodeGearの集合である。
 
 
 \section{CbCを用いたOSの記述}
-CodeGearの遷移はノーマルレベルから見ると単純にCodeGearがDataGearをInput, Outputをのみ繰り返し, コードブロックを移動しているように見える.
+CodeGearの遷移はノーマルレベルから見ると単純にCodeGearがDataGearをInput, Outputを繰り返し, コードブロックを移動しているように見える.
  CodeGearが別のDataGearに遷移する際のDataGearとの関係性を図\ref{fig:meta-cgdg} に示す. ノーマルレベルではDataGearを受け取ったCodeGearを実行, 実行結果をDataGearに書き込み別のCodeGearに継続していると見える. 
 
 しかし, 実際にはCodeGearから別のCodeGearへの遷移にはデータの整合性の確認などのメタ計算が必要となる. 
@@ -191,16 +198,16 @@
 \item \|DataGearManager|（以下DGM）
 \end{itemize}
 
-CodeGearはクラスやスレッドに相当する. DataGearは変数データであり, CodeGear内でjavaのアノテーションを用いて記述する.
-
- DataGearはKeyと必ず対応しており, CodeGear内の全てのKeyにDataGearが揃った際に初めてCodeGearが動作するという仕組みになっている. 
+CodeGearはクラスやスレッドに相当する. 
+DataGearは変数データであり, CodeGear内でjavaのアノテーションを用いて記述する.
+DataGearはKeyと必ず対応しており, putと言う処理によりCG内の全てのKeyにDataGearが揃った際に初めてCGが動作するという仕組みになっている. 
 
 CodeGearManagerはいわゆるノードに相当し, CodeGear, DataGear, DataGearManagerを管理する.  
-複数のCodeGearManager同士が配線され,  DataGearを送信し合うことで分散処理を実現している. 
+複数のCodeGearManager同士が配線され,  DGを送信し合うことで分散処理を実現している. 
 
-DataGearManagerはDGを管理しているもので変数プールに相当し, CodeGearManagerの持っているDataGearのkeyとputされたデータの全てを所持している. 
-DataGearManagerはLocalとRemoteに区分することができ, LocalDataGearManagerはCodeGearManager自身が所持するDataGear(key)のプールであり, Localにputすることにより自身の持つkeyにDataGearを送ることができる.
-対するRemoteDataGearManagerはCodeGearManagerが配線されている別のCodeGearManagerが持つDataGearのプールである. つまり, 任意の接続されたRemoteDataGearにDataGearをputすると対応したノードが持つkeyにDataGearが送信される. RemoteDataGearにDataGearをputする処理が分散処理の肝となっている. RemoteDataGearの仕組みを図\ref{fig:RDGM}に示す.
+DataGearManagerはDGを管理しているもので変数プールに相当し, CGMが利用するCGのkeyとputされたデータの組み合わせを所持している. 
+DataGearManagerはLocalとRemoteに区分することができ, LocalDGMはCGM自身が所持するDGのプールであり, Localにputすることにより自身の持つkeyにDGを送ることができる.
+対するRemoteDataGearManagerはCGMが配線されている別のCGMが持つDGのプールである. つまり, 任意の接続されたRemoteDGMにDGをputすると, 対応したCGM(ノード)が持つDGMのpoolにDGが送信される. RemoteDGMにDGをputする処理が分散処理の肝となっている. RemoteDataGearManagerの仕組みを図\ref{fig:RDGM}に示す.
 
 \begin{figure}[tb]
     \begin{center}
@@ -229,10 +236,12 @@
 HelloWorldCodeGearではkey: helloWorldにputされた文字列をprint出力するという単純な処理を記述している. 
  CGM名.getLocalDGM().put("Keyname", 変数データ)にてkeyに変数データを紐付け(putし), CodeGearに設定されている全てのkeyがデータを受け取った際に初めてCodeGearは処理される. HelloWorldCodeGearではString型のhelloWorldというkeyがTake型で設定されている.
  
-以下のHelloWorldプログラムを実行した際の流れを説明する.
- まずポート10000番のCodeGearManagerを生成し, HelloWorldCodeGearをsetupさせる. 
- この時点では必要なkey(key名: helloWorld)にデータが揃っていないのでCodeGearは実行されない. cgm.getLocalDGM().put("helloWorld","hello");にてhelloWorldkeyに文字列"hello"をputすると, HelloWorldCodeGearに必要なDataGearが揃い, print表示が行われる. 
-プログラム中ではkey:helloWorldへのputは文字列"hello"と"world"の二回が行われ, print出力結果はhello worldと表示される. 
+ 
+ %以下のHelloWorldプログラムを実行した際の流れを説明する.
+ %まずポート10000番のCodeGearManagerを生成し, HelloWorldCodeGearをsetupさせる. 
+ %この時点では必要なkey(key名: helloWorld)にデータが揃っていないのでCodeGearは実行されない. cgm.getLocalDGM().put("helloWorld","hello");にてhelloWorldkeyに文字列"hello"をputすると, HelloWorldCodeGearに必要なDataGearが揃い, print表示が行われる. 
+%プログラム中ではkey:helloWorldへのputは文字列"hello"と"world"の二回が行われ, print出力結果はhello worldと表示される. 
+
 
 \begin{lstlisting}[frame=lrbt,label=codes: StartHelloWorld,caption={ChristieにおけるCGMとCGのsetup}]
 public class StartHelloWorld extends StartCodeGear {
@@ -299,48 +308,11 @@
 
 
 \begin{thebibliography}{10}
-
-\bibitem{okumura}
-奥村晴彦：改訂第5版\LaTeXe 美文書作成入門，
-技術評論社(2010).
-
-\bibitem{companion}
-Goossens, M., Mittelbach, F. and Samarin, A.:
-{\it The LaTeX Companion},
-Addison Wesley, Reading, Massachusetts (1993).
-
-\bibitem{book1}
-木下是雄：
-理科系の作文技術，
-中公新書(1981).
-
-\bibitem{book2}
-Strunk W. J. and White E.B.:
-{\it The Elements of Style, Forth Edition},
-Longman (2000).
-
-\bibitem{book3}
-Blake G. and Bly R.W.:
-{\it The Elements of Technical Writing},
-Longman (1993).
-
-\bibitem{book4}
-Higham N.J.:
-{\it Handbook of Writing for the Mathematical Sciences},
-SIAM (1998).
-
-\bibitem{webpage1}
-情報処理学会論文誌ジャーナル編集委員会：
-投稿者マニュアル(online)，
-\urlj{http://www.ipsj.or.jp/journal /submit/manual/j\_manual.html}
-(2007.04.05).
-
-\bibitem{webpage2}
-情報処理学会論文誌ジャーナル編集委員会：
-べからず集(online)，
-\urlj{http://www.ipsj.or.jp/journal/manual /bekarazu.html}
-(2011.09.15).
-
+\bibitem{aka}赤堀 貴一，河野真治 : \textbf{Christieによるブロックチェーンの実装}．琉球大学工学部情報工学科卒業論文 2019.
+\bibitem{latex}照屋 のぞみ，河野真治 : \textbf{分散フレームワークChristieの設計}．琉球大学理工学研究科修士論文 2018.
+\bibitem{latex}清水 隆博，河野真治 : \textbf{xv6 の構成要素の継続の分析}．OS研究会2019.
+\bibitem{latex}清水 隆博，河野真治 : \textbf{継続を基本とした言語による OS のモジュール化}．琉球大学理工学研究科修士論文 2020.
+\bibitem{latex}清水 隆博，河野真治 : \textbf{継続を基本とした言語による OS のモジュール化}．琉球大学理工学研究科修士論文 2020.
 \end{thebibliography}