Monaのfile_serverを新しいものにリプレースしたので紹介します。
背景 †
- 旧file_serverのコードが汚くなりつつあり、リライトの時期だった
- 仮想メモリの足掛かりを作る
- 土台であるファイルシステムをきちんと作りたかった
変更点 †
- Vnode/VFSベースになりました
- ソースコードがきれいになりました
- ファイルシステムの追加が容易になりました
- テストとメモリリークチェックが容易になりました
- 正式にmonapiでwriteサポートがつきました
- monapi_call_file系のAPIの名前が変わりました
- 接頭子が monapi_call_file -> monapi_file に変更
- ドライブレターをやめました
- 既存のソースは修正／リコンパイルが必要な場合があります
API †
| 旧 | 新 | |
| dword monapi_call_file_open(const char* file) | dword monapi_file_open(const char* file, MONAPI_BOOL create) | ファイルをopenする。ハンドルが返る |
| dword monapi_call_file_get_file_size(dword id) | dword monapi_file_get_file_size(dword id) | 開いているファイルのサイズを得る |
| MONAPI_BOOL monapi_call_file_seek(dword id, dword position, dword flag) | dword monapi_file_seek(dword fileID, dword offset, dword origin) | seekする |
| MONAPI_BOOL monapi_call_file_close(dword id) | dword monapi_file_close(dword id) | ファイルをcloseする |
| monapi_cmemoryinfo* monapi_call_file_read(dword id, dword size) | monapi_cmemoryinfo* monapi_file_read(dword fileID, dword size) | ファイルをreadする |
| monapi_cmemoryinfo* monapi_call_file_read_data(const char* file, MONAPI_BOOL prompt) | monapi_cmemoryinfo* monapi_file_read_all(const char* file) | ファイルを全てreadする |
| monapi_cmemoryinfo* monapi_call_file_read_directory(const char* path, MONAPI_BOOL prompt) | monapi_cmemoryinfo* monapi_file_read_directory(const char* path) | ディレクトリをread |
| int monapi_call_change_drive(int drive, MONAPI_BOOL prompt) | | 廃止 |
| int monapi_call_get_current_drive() | | 廃止 |
| int monapi_call_get_current_directory(char* dest) | | 廃止 |
| int monapi_call_change_directory(const char* dest) | | 廃止 |
| dword monapi_file_write(dword fileID, monapi_cmemoryinfo* mem, dword size) | ファイルをwriteする |
サンプルコード †
QEMUを以下のように起動すればCD-ROMブートで FD イメージを利用できる
qemu -cdrom ~/mona/mona/tool/mkimg/mona.iso -fda ~/mona/mona/tool/mkimg/mona.img -boot d
そして、新しい file_server を利用すればFloppy Disk Driveを /fd から利用できます。
新しいAPI monapi_file_read を利用して簡単にファイル書き込みが可能です。
サンプルはこんな感じ。
const char* message = "Hello World\n";
monapi_cmemoryinfo* buffer = new monapi_cmemoryinfo();
if (!monapi_cmemoryinfo_create(buffer, strlen(message) + 1, 0))
{
monapi_cmemoryinfo_delete(buffer);
return -1;
}
memcpy(buffer->Data, message, buffer->Size);
dword id = monapi_file_open("/FD/HELLO.TXT", true);
monapi_file_write(id, buffer, buffer->Size);
monapi_file_close(id);
ファイル書き込みといえばエディタだ！と思いつき、id:hetappiさんのgnoteを最新のMona 0.3.0系でコンパイルしてみました。
ちょっとした手直しで動いたので monaos/contrib/Misc/gnoteとしてツリーに追加しました。
gnoteはコピー／貼り付けなどが全て自前で実装されていてかなり気合いが入っています。
肝心の書き込みはここでやっているようです。
当時は書き込みの正式APIがなかったので空になっています。
bool Controller::WriteFile(const String& f, const Document& d) {
return false;
}
ここにいろいろ書けば動きそうですが、なぜかメニュー部分がうまくイベントを拾ってくれなくて今日のところはここまで。
Mona上でファイルを編集／保存してごにょごにょ。まではだいぶ近付いてきた気がします。
コメント †
コメントはありません。 コメント/Mona/0.3.0/新file_server?
file_server 導入に伴って stlport を tool に配置した件 †
- toolじゃなくて、coreの下で良いんじゃないですか? monalibcとかmonapiと一緒に並ぶものじゃないですか?--shadow
- 正直迷いましたがtoolにしました。他の人の意見も聞いてみたいです。--ひげぽん
- tool に置いた理由って何でしょうか？stlport を見ると include に自身をコピーするだけに見えます。monalibc のヘッダtは include に元から配置しています。同じように stlport も include に元から配置するとどうでしょうか？ -- Gaku
- stlportは完全に外部ライブラリなのでcontrib/Develに入っていました。その後file_serverがstlportに依存したのでtoolに入れました。includeにそのままおくのは、「stlportは外部ライブラリである」という点で抵抗があります。いかがでしょう。 -- ひげぽん
- 必須サーバである file_server は stlport に依存する。stlport は外部ライブラリなので tool に置かれていて、変則的な扱いである。ていうおかしな状況ですね。外部ライブラリとして区別して置きたいなら、区別する方法を決めておくのがスジだと思うのですが、ま、今のところ stlport だけだしこのままで良いかな。 -- Gaku
- 外部ライブラリをOSサーバに使っちゃいけないのでは? 使うならCoreに入れるべきでしょう。 -- shadow
- うーん。外部ライブラリをOSサーバーに使ってはいけない理由はなんでしょう。そして使うならcoreに入れるべき理由は何でしょう。(質問) -- ひげぽん
- あくまでも個人的意見ですが、
- メインソース（ここではCore)に含めないなら、実行環境側に用意されているべき。でも、OSの実行環境側って...と考えたら自分で持つべきかと。
- 逆にtoolは、ビルドに必要なツール群という位置づけだった(気がする)ので、実行環境にはなくてもいいものかなぁと。ソースがないとしてもビルド環境で用意したらいいものたち。
- ポイントは、現状stlportがヘッダ群なことですかね。実行時に必要ないビルドツールじゃん?って意見ならtoolでOK。でも、今はたまたまヘッダ群なだけでソースがつくこともあるわけですよね?それなら、coreに(実際にはincludeですが)含めたほうがいいと思います。--shadow
- 自分の考えを書いてみます。外部ライブラリを (1) OSサーバに使っても良い (2) toolに置くのは良くない ( toolはビルドに必要になったツールなどを置く場所 ) (3) 外部ライブラリは(今までの独自ライブラリを置いていた)includeと区別したいという事はあり得る。 (4) 外部ライブラリ配置用のディレクトリを作ったら？ (5) stlport だけなので今回は tool で勘弁して欲しい→それもあり。 -- Gaku
- 単純に疑問なだけですが、システムのincludeって外部ライブラリのヘッダを置くものじゃないですか?内部ライブラリなら自分のソースディレクトリに持てばいいんだし。 -- shadow
- OSのソースツリーでは内部→スクラッチで書いたコード、外部→外部ライブラリという定義。Mona OSを起動してファイルシステム上にある include は外部ライブラリのヘッダを置く場所となると思います。OSのソースツリーなのか、実際に起動しているOSのFS上に配置されているヘッダかの区別が必要かと思います。--ひげぽん
- ↑はどこかおかしい気がします。Mona OSが起動した後にincludeフォルダがあったとしてmonalibcを配置することもあるでしょう。monalibcはスクラッチで書いたコードに分類されるはずなので依然として、Monaプロジェクトでスクラッチで書いたコード、と、外から持ってきて移植などしただけのコード、を区別する方法は必要じゃないかと思います。（それと、shadowさんとhigeponさんの内部・外部の言葉の意味するところがずれているように見えます。同じ話題について話そうとしているなら少しまずいかな？） -- Gaku
- 個人的にはGakuさんが書いてくださった「自分の考えを書いてみます」で始まる部分の話以外に深く掘り下げるべき問題でない気がします。 -- ひげぽん
- おっと。修正しようとしたら新しいコメントが。「今回は tool で勘弁して欲しい」で決まりってことですね。配置の話なので違うなーと思うと突っ込みを入れてしまうわけですが、まぁ決定なり方針なりがあればそれに従うまでじゃないかな？（自分としては↑で(5)→それもあり、ですしね） -- Gaku
コメントはありません。 コメント/Mona/0.3.0/新file_server?
file_server のコンパイルに失敗する件 †
- file_server のコンパイルに失敗します。stlport/config/stlcomp.h に #define _STLP_RAND48 されてます。すると stlport/stl/_algo.c の __random_number 関数で lrand48 が使われます。#define _STLP_RAND48 をコメントアウトすると rand が使われてコンパイルが通るようになるので、コメントアウトしたら良いかな？と思ってるのですが、いかがでしょうか？ -- Gaku
- コメントアウトしてしまってください。その後コミットしてもらってこちらの環境でも確認という流れで進めてもらえると助かります。 -- ひげぽん
- まぁ直す場所は↑に書いておいたので困った人が直せば良いのじゃないかな。と。 -- Gaku
- ん。面倒であればやりますが、こちらで再現していないので確認が難しいですね。 -- ひげぽん
コメントはありません。 コメント/Mona/0.3.0/新file_server?
deviceOn / deviceOff が適切でない件 †
- FAT12FileSystem.cpp で deviceOn / deviceOff が適切でないので、実機で起動しませんでした。他の人のとこだとどうなんでしょうか。（CD-Rに焼くのが面倒でソースコードを改変してFDから起動するようにして動かしたんですけれども） -- Gaku
- 今は、CDブート + FDもアクセスできるという構成を前提にしています。そのあたりを自動検出できるとうれしいのですがどうだろうか。 -- ひげぽん
- んー。CDブート + FDでも今のコードだと実機で起動しないのじゃないかと思うのですが、どうかな？Fat12FileSystemを初期化する際にFDDのモータをオンにしていない様なので。だれかCDブート+FDアクセスの構成で実機で起動してみました？ -- Gaku
コメントはありません。 コメント/Mona/0.3.0/新file_server?
