Mercurial > hg > Document > Growi
changeset 91:7c70b573b54f
backup 2021-09-22
author | autobackup |
---|---|
date | Wed, 22 Sep 2021 00:10:04 +0900 |
parents | 3126bf6d9978 |
children | 31a558f00ba6 |
files | CbC/vscode.md user/masato/メモ/2021/09/21.md user/matac42/docker-xv6.md user/matac42/note/2021/09/21.md user/matac42/singularity-xv6.md user/mizuki.md user/pine/note/2021/09/21.md user/riono210/seminar/202109/0921.md |
diffstat | 8 files changed, 499 insertions(+), 20 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/CbC/vscode.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,43 @@ +# vscode on singurality + +singurality上でcbcとvscodeを動かすやつ。 + +## server上でsifファイルの準備 +amaneに移動 + +`ssh amane` + +sifファイルが置いてあるディレクトリへ移動 + +`cd /ie-ryukyu/singularity/cbcgcc_vs` + +そこの`cbcgcc_vs.sif`を自分のホームへ + +`cp /ie-ryukyu/singularity/cbcgcc_vs.sif ~/` + +## ローカルでポートフォワーディング +sshを切ってローカルでポートフォワーディングする。 +4567が空いているかをlsofなどで調べる。空いていなかったら別のポートを使う + +`ssh -L 4567:localhost:4567 amane` + +成功したらamaneにssh接続されるので、sifファイルがあるディレクトリで、 + +`singularity exec --nv cbcgcc_vs.sif code-server --port 4567` + +その後`localhost:4567`にアクセスすると、ブラウザ版のvscodeが使える! + +## パスワードについて + +`localhost:4567`へアクセスするとパスワードが求められるので、 + +`~/.config/code-server/config.yaml`に記述されているパスワードを入力する! + +## ビルドについて +何か新規でアプリケーションが欲しいとなったら、`/ie-ryukyu/singularity/cbcgcc_vs`にあるdefを手元に持ってくる。 +そして編集後に + +`singularity build --fakeroot cbcgcc_vs.sif cbcgcc_vs.def` + +すると.sifが新しくなるので、これでexecしてやるとアプリケーションが入っているはず。 +(.sifの名前は自由)
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/masato/メモ/2021/09/21.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,22 @@ +# 研究目的 +現在のゲームでは、事前に音響データを事前計算することで現実に近い音響を実現している。 + +動的(地形が変化する)な環境では事前計算を行うことができないためリアルタイムで計算する必要がある。 + +既に存在する動的環境に対応した音響システムでは、主に音の反響や遮蔽のみの再現にとどまっている。 + +本システムでは反響や遮蔽に加え、回折などによって音が壁から回り込んでくる現象を再現する。 + +- 反響、遮蔽 + - レイレースによる周囲の環境評価 +- 回折 + - 経路探索を用いてプレイヤーへの経路を算出。その経路を用いて回折経路を求める。 + + + + + +# 活動報告 +Unity上でOpenALが動かせるようになった。 + +OpenALで空間音響を行っているプロジェクトのプログラムを読んだ。 \ No newline at end of file
--- a/user/matac42/docker-xv6.md Tue Sep 21 00:10:04 2021 +0900 +++ b/user/matac42/docker-xv6.md Wed Sep 22 00:10:04 2021 +0900 @@ -43,6 +43,7 @@ RUN apt-get update && apt-get install -y \ git \ + zsh \ build-essential \ gdb-multiarch \ qemu-system-misc \ @@ -87,22 +88,6 @@ 別端末にて -`$docker exec -it xv6 /bin/sh` - -`#gdb-multiarch` - -**example** +`$docker exec -it xv6 /bin/zsh` -``` -(gdb) file kernel/fs.c -"/xv6/kernel/fs.c": not in executable format: file format not recognized -(gdb) b iget -Breakpoint 1 at 0x8000337c: file kernel/fs.c, line 244. -(gdb) c -Continuing. -[Switching to Thread 2] - -Thread 2 hit Breakpoint 1, iget (dev=1, inum=3) at kernel/fs.c:244 -244 { -(gdb) -``` \ No newline at end of file +`#gdb-multiarch` \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/matac42/note/2021/09/21.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,142 @@ +# 研究目的 + +アプリケーションの信頼性を保証するために、アプリケーションが動作するOSの信頼性を高める必要がある。 + +本研究室では、信頼性に重きを置いたGearsOSを開発している。 + +GearsOSはノーマルレベル、メタレベルの処理を切り分けることができるCbC(Continuation Based C)で記述されている。 + +信頼性とは + +- どのユーザーがどのようなファイル操作をしたかわかること +- logが残ること +- item 操作の辻褄があっていること + +を指す。 + +また、GearsOSには現在未実装の機能があり、その一つにファイルシステムが挙げられる。信頼性を確保するため、ファイルシステムは + +- ファイルシステム全体のトランザクション化 +- ファイルシステム全体のバックアップ\&ロギング + +を取り入れたDataGearManagerとして実装したい。 + +本卒業研究では、GearsOSへファイルシステムの実装を目指す。 + +# Gears + +macbook上のlldbにて + +``` +$lldb ./hello_world +(lldb) target create "./hello_world" +Current executable set to '/Users/matac/ws/src/firefly/hg/Gears/Gears/src/parallel_execution/hello_world' (x86_64). +(lldb) b main +Breakpoint 1: where = hello_world`main, address = 0x0000000100004ec2 +(lldb) r +Process 23209 launched: '/Users/matac/ws/src/firefly/hg/Gears/Gears/src/parallel_execution/hello_world' (x86_64) +Process 23209 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 + frame #0: 0x0000000100004ec2 hello_world`main +hello_world`main: +-> 0x100004ec2 <+0>: pushq %rbp + 0x100004ec3 <+1>: movq %rsp, %rbp + 0x100004ec6 <+4>: subq $0x20, %rsp + 0x100004eca <+8>: movl %edi, -0x14(%rbp) +Target 0: (hello_world) stopped. +``` + +- どうすればCbCのコードを表示してdebugできるか +- singularityの方でdebugできるっぽいのでそっちを使っていくかも + +# xv6 + +## docker & singularity + +xv6をrun & debugできるdockerとsingularityを作った + +作り方、使い方は下記参考 + +- https://growi.cr.ie.u-ryukyu.ac.jp/user/matac42/docker-xv6 +- https://growi.cr.ie.u-ryukyu.ac.jp/user/matac42/singularity-xv6 + +## user application & system call + +xv6でuser applicationやsystem callを作る方法を下記にまとめた + +- https://growi.cr.ie.u-ryukyu.ac.jp/user/matac42/xv6-add-call + +## pwd + +pwdコマンドがxv6になかったので入れ込んだ + +- pwdコマンドは既存のsystem callで作れる +- 例がたくさん転がっているので簡単 +- ほぼコピペなので理解しているかと言われるとそうでもない + +参考: https://dev.to/tyfkda/implement-pwd-command-on-xv6-gh5 + +他にやってみたいこと + +- pathを通せるようにする +- editorを作る + +## cd + +cdコマンドはuser applicationとして登録されていないにもかかわらず打てた + +- user/sh.cに下記のような記述が + +```c +// Read and run input commands. + while(getcmd(buf, sizeof(buf)) >= 0){ + if(buf[0] == 'c' && buf[1] == 'd' && buf[2] == ' '){ + // Chdir must be called by the parent, not the child. + buf[strlen(buf)-1] = 0; // chop \n + if(chdir(buf+3) < 0) + fprintf(2, "cannot cd %s\n", buf+3); + continue; + } + if(fork1() == 0) + runcmd(parsecmd(buf)); + wait(0); + } +``` + +- なぜcdをuser applicationとして切り出さないのか +- 命令の簡素化をしているのでは、という話を聞いた + +## filesystem + +- inode + - kernel/fs.cに書いてある + - ファイルのメタ情報をinode numberとともに持っている + - メタ情報 + - lsやstatした時に表示されるような情報 + - 所有者 + - 更新日時 + - ファイルサイズ + - アクセス権 + - inodeをdataとは別の所定の位置に保存する + - inodeはdataのアドレスを持っているのでinode numberでdataにアクセスすることができる + - macbook上(APFS)でもinodeの確認ができる + - `$ls -i` + - `$df -i` + - `$stat` + - しかしAFSがinode番号を適当に返しているという話が + - macOSのfilesystemのsource code探したけど見つからない(あれば知りたい) + - inode数はあらかじめ決定されている + - inode数上限を超えるとファイルやディレクトリが作成できなくなる +- spinlock + - kernel/fs.cなどではacquireとreleaseを繰り返すような形でコードが書かれている + - spinlockはlockされた資源が解放されるまでアクセスできなくなるような方法 + - 待たされている他のプログラムなどはループチェックで資源が解放されるのを待つ + +# その他 + +- 蚊に刺されすぎてつらい +- 胸骨が痛い +- brainf\*ckのexampleがアスキーアートしてて面白かった + - https://github.com/fabianishere/brainfuck/blob/master/examples/compiler/awib.bf + +
--- a/user/matac42/singularity-xv6.md Tue Sep 21 00:10:04 2021 +0900 +++ b/user/matac42/singularity-xv6.md Wed Sep 22 00:10:04 2021 +0900 @@ -6,7 +6,7 @@ `amane:/ie-ryukyu/singularity/xv6`においてある -### 単にxv6を起動する +### 単にxv6を起動したい場合 `$cd /ie-ryukyu/singularity/xv6` @@ -16,7 +16,7 @@ `Singularity> make qemu` -### debugする +### debugしたい場合 `$cd /ie-ryukyu/singularity/xv6` @@ -36,6 +36,8 @@ ## sif作成の手順 +自分でsifを作りたいときはこのセクションを参考にすると良い + ### defファイルを作成する `$cd /ie-ryukyu/singularity/xv6`
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/mizuki.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,2 @@ +# mizuki +This is mizuki's page \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/pine/note/2021/09/21.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,175 @@ +# 研究目的 +- アプリケーションの信頼性を保証するために、アプリケーションが動作するOSの信頼性を高める必要がある。 + +- 本研究室では、Continuation Based C(CbC)を用いて、信頼性と拡張性を両立するOSであるGearsOSを開発している。 + +- ソフトウェア開発においてエラー・バグは付き物であり、その発見が重要である。現在GearsOSにはデバッガーが未実装であるため、円滑なOS開発を行うために、GearsOSのデバッガーを作成する。 + +## やったこと +- 論文読みつつGearsOSのコードリーディング + +- DataGearの表示 + +## 作業ログ +DataGearの表示をstubCodeGearで行うことにした。 + +とりあえずはmake時に生成されるcファイルにDataGearの出力ルーチンを直接書いてみた。 + +↓stub内に直接記述したDataGear表示ルーチン +``` +__code putdown_rforkPhilsImpl_stub(struct Context* context) { + PhilsImpl* phils = (PhilsImpl*)GearImpl(context, Phils, phils); + enum Code next = Gearef(context, Phils)->next; + // ここにデバッグルーチンを手書きで書いて実行してみる + // if (debug_condition(context)) { + // printf("Phils"); + // printf("next"); + // // prompt(); + // } + printf("debugger in putdown_rforkPhilsImpl_stub\n"); + printf("context address: %p\n", context); + printf("DataGear address in context: %p\n", context->data); + + printf("phils = %p\n", Gearef(context, Phils)->phils); + printf("putdown_lfork = %i\n", Gearef(context, Phils)->putdown_lfork); + printf("putdown_rfork = %i\n", Gearef(context, Phils)->putdown_rfork); + printf("thinking = %i\n", Gearef(context, Phils)->thinking); + printf("pickup_rfork = %i\n", Gearef(context, Phils)->pickup_rfork); + printf("pickup_lfork = %i\n", Gearef(context, Phils)->pickup_lfork); + printf("eating = %i\n", Gearef(context, Phils)->eating); + printf("next CodeGear = %i\n", Gearef(context, Phils)->next); + goto putdown_rforkPhilsImpl(context, phils, next); +} +``` + +出力結果が以下のようになった。 +``` +context address: 0x7fd9c3c05bb0 +DataGear address in context: 0x7fd2b3c00000 +phils = 0x7fd8b3c01260 +putdown_lfork = 0 +putdown_rfork = 0 +thinking = 0 +pickup_rfork = 0 +pickup_lfork = 0 +eating = 0 +next CodeGear = 10 +``` + +lldbで出力させたやつ +``` +(lldb) p context->data[16]->Phils +(Phils) $5 = { + phils = 0x000000011412f260 + putdown_lfork = C_checkAndSetAtomicReference + putdown_rfork = C_checkAndSetAtomicReference + thinking = C_checkAndSetAtomicReference + pickup_rfork = C_checkAndSetAtomicReference + pickup_lfork = C_checkAndSetAtomicReference + eating = C_checkAndSetAtomicReference + next = C_exit_code +} +``` +同じっぽい。 + +contextとDataGearが格納されてるData配列のアドレスは取得できた。 + +putdown_lforkやthinkingにはそれぞれのCodeGearを示すenumが入るが、全て0になってしまってる。 + +ここでenumCode.hを見てみると、0はC_checkAndSetAtomicReferenceのことである。 +``` +enum Code { + C_checkAndSetAtomicReference, + C_checkAndSetAtomicT_intImpl_int, + C_clearSingleLinkedQueue, + C_clearSingleLinkedStack, + C_clearSynchronizedQueue, + C_code1, + C_code2, + C_createTask1, +``` + +なんでC_checkAndSetAtomicReferenceが各CodeGearの最初で呼ばれる? + +DPPMCでAtomicT_intを使ってるから? + +C_checkAndSetAtomicReferenceはこんな感じ +``` +__code checkAndSetAtomicReference(struct AtomicReference* atomic, union Data** ptr, union Data* oldData, union Data* newData, __code next(...), __code fail(...)) { + if (__sync_bool_compare_and_swap(ptr, oldData, newData)) { + goto next(...); + } + goto fail(...); +} +``` + +C_checkAndSetAtomicReferenceが呼ばれるタイミングとしてはDPPMCのmainの中でのfork生成のとき。 +``` +__code createTask1(struct TaskManager* taskManager) { // without taskManager, par goto won't work + AtomicT_int* fork0 = createAtomicT_intImpl_int(context,-1); // fork0 + AtomicT_int* fork1 = createAtomicT_intImpl_int(context,-1); // fork1 + AtomicT_int* fork2 = createAtomicT_intImpl_int(context,-1); // fork2 + AtomicT_int* fork3 = createAtomicT_intImpl_int(context,-1); // fork3 + AtomicT_int* fork4 = createAtomicT_intImpl_int(context,-1); // fork4 +``` + + + +## ゼミログ +https://mattermost.ie.u-ryukyu.ac.jp/cr-ie-u-ryukyu/pl/cjp144m89j8zmnrbisrqweozzr +``` +DGの表示 +stubにデバッグルーチンを書いて表示 +実行させたらアドレスとかenumは表示できた! + +lldbと同じような表示でできた + +checkAndReferenceが最初に呼ばれる理由 +→バグ +インプリメンテーションが呼ばれるはず +Atomicは実行時にはあまり関係ない + +表示ルーチンを生成したやつをどうする? +parlスクリプトと格闘する必要あり + +breakpointも入れたい +backtrace戻りたい +→forwardtraceもできるようにしたい +変数の変更が誰によって行われたか +モデルチェックだとリバースポインタを使用して確認できる +デバッグしてくとある変数をアサインしたものがわかるようになる + +欲しいデバッガー機能 +トレース機能を入れてガンガントレースしていく +Haskellもトレースベース +何をトレースするのかを探す必要がある +→それを提供するような機能が必要 +``` + +## 疑問点 +- なんでC_checkAndSetAtomicReferenceが各CodeGearの最初で呼ばれる? + - バグ + - 本来であれば各CodeGearのImplが書かれてないといけない +- 今のところのDataGearの表示だけだとLLDBでいい感じがする。 +- デバッガの機能としてどういった機能を実行するか? + - DataGearの表示 + - CodeGearの表示 + - プロンプト + - breakpoint + - backtrace + - lldbとかだったらCodeGearのbtが取れないから欲しいって感じ? + - backtraceっていうよりはforwardtraceって感じ + - 変数の変更がどのCodeGearによって行われたか知りたい感じ + - バグ発生時はそもそも何をbtすればいいのかわからない + - なので、そのbtを見つけるのを助けるものが欲しい +- どんな感じでstubにデバッガ機能を書いていくか? + - stub生成時に書いていく感じ? + - これだとperl読まなきゃ。。。 + +## やること +- DataGearの表示機能の作成 +- stub生成してるperl読む +- lldbの機能理解&ソースコード読み + +## その他 +
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/riono210/seminar/202109/0921.md Wed Sep 22 00:10:04 2021 +0900 @@ -0,0 +1,108 @@ +## 0921 + +## 研究目的 +* ゲームの通信方式にはクライアントサーバ方式とp2p方式がある +* データの安全性やチート対策などでクライアントサーバ方式が主流 +* サーバに接続してマルチプレイなどのデータ同期を実現させているため、低速 +* 高速かつ安全に通信を行たい + * 並列分散フレームワークChristieがある + * Christieを利用してp2pで通信を行う +* ゲーム開発で主に使用されているUnityに対応するためにChristieをC#へ書き換えを行う + +## 今週の進捗 +* RemoteDGのバグをいくつか修正できた + * 自作クラスではなくstirngで試してみたところ送信できた + * ソケット部分は問題なさそうMessagePackがやはり原因 + * 次から次へとバグが出てくる... + + +### これまでにあったバグ +MessagePackでうまくシリアライズできない問題 +``` +MessagePack.MessagePackSerializationException: Failed to serialize System.Object value. + ---> System.TypeInitializationException: The type initializer for 'FormatterCache`1' threw an exception. + ---> System.TypeInitializationException: The type initializer for 'FormatterCache`1' threw an exception. + ---> MessagePack.Internal.MessagePackDynamicObjectResolverException: can't find matched constructor. +``` + +can't find matched constructor + +https://github.com/neuecc/MessagePack-CSharp/issues/547 +* プロパティー名とコンストラクタ内の変数が一致していないとダメらしい + * プロパティは使用していなかったが、keyとフィールド変数名が一致していなかったため修正した +``` +[Key("command")] +public string cmd; + +public RTCommand(string line, string cmd, int i) { + this.line = line; + this.cmd = cmd; + this.offset = i; +} +``` + + +``` +[Key("command")] +public string command; + +public RTCommand(string line, string command, int offset) { + this.line = line; + this.command = command; + this.offset = offset; +} +``` + + +### 自作クラスのデシリアライズがうまくいかない + +``` + at Christie_net.datagear.dg.DataGear`1.SetData(T data) in /Users/e165729/konoLab/Christie_net/datagear/dg/DataGear.cs:line 49 +at Christie_net.datagear.dg.MessagePackDataGear`1.GetData() in /Users/e165729/konoLab/Christie_net/datagear/dg/MessagePackDataGear.cs:line 46 +Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object. +``` + +プリントデバッグの結果 +``` +obj: System.Collections.Generic.Dictionary`2[System.Object,System.Object] + +``` +* 何かディクショナリになっていた +* デバッガー動かしてみたが、マルチスレッドが原因のため?ブレークポイントを掴めなかった + + +中身 +``` +key:line val:insert +key:command val:line +key:offset val:0 + +``` + +RTCommandの宣言 +``` +public class RTCommand { + [Key("line")] + public string line; + [Key("command")] + public string command; + [Key("offset")] + public int offset; + + public RTCommand(string line, string command, int offset) { + this.line = line; + this.command = command; + this.offset = offset; + } +``` + +なぜかデシリアライズするとディクショナリーに変換されてしまう + +* 受け取ったディクショナリーから動的にクラス、インスタンス生成する? +* DG部分を書き換えてディクショナリーで受け取れられるようにする? + + + +### 就活について +* 完全に終了した + * 名古屋か東京に行きます \ No newline at end of file