Nobita/020.vfs,vnodeのロードマップ/20060611


Top / Nobita / 020.vfs,vnodeのロードマップ / 20060611

これは何か

(HigePon) file_serverは一から書き直しだ!
(Gaku) ぉ。どーしたんだっ。
(HigePon) vnode対応をしていったら大体今までと同程度の機能が提供できそうなめど立ちました。
(oku_PS2) リファクタリング発作だ
(HigePon) でもベースクラス依存が激しくて
(HigePon) いまのままだと
(HigePon) 新旧コードの依存関係が
(Gaku) まぁまずあれです。
(HigePon) 最悪。
(Gaku) なぜ自分が書き直したくなったかを把握しないと。
(HigePon) 具体的には
(Gaku) どこがまずくてどう直せば、自分が納得できるか把握できてるなら、書き直しに反対する理由は特にないと思うな。
(HigePon) FileSystem.h にかかわるインターフェースが
(HigePon) Vnode用と旧システム用
(HigePon) 2倍になっている点。
(HigePon) Vnode用が旧システム用に依存していて
(HigePon) 旧システム用が
(HigePon) 消せない点
(HigePon) などなど。
(Gaku) 旧システム用ってのは?
(HigePon) 旧file_server用のインターフェースです。
(HigePon) Read/Open/とか
(Gaku) 旧ファイルサーバのインタフェースを、新ファイルサーバも提供する。
(Gaku) てな事になっている?
(HigePon) vnode用と相容れないんだけど死ぬほど似ている名前の関数群
(Gaku) つまり、今動いているアプリの互換性のため、新ファイルサーバも古いインタフェースを提供する?
(HigePon) それはYes
(HigePon) file_server内にある
(HigePon) メッセージループレベルでは同じものを提供する
(HigePon) 中身のコンクリートFSが実装すべきインターフェースが
(Gaku) 旧システム用ってのはそのレベルじゃないのか。まずコード見ないとダメかな?
(HigePon) 例を挙げると
(HigePon) ディレクトリ内のファイル一覧を取得する関数
(HigePon) で
(Gaku) (あれだ。ちょっとコード見るのは後にして、コード見てない人への説明の実験をしてみよう。
(HigePon) extern monapi_cmemoryinfo* monapi_call_file_read_directory(const char* path, MONAPI_BOOL prompt);
(HigePon) アプリはこの関数を使います。
(HigePon) この関数はこれからも昔も同じで変わらない。
(HigePon) この関数はfile_serverにメッセージを投げることでこの機能を提供しているんだけど
(Gaku) ん。メッセージループレベルの互換性は了解です。
(HigePon) お。さらに先に進んでみよう。
(Gaku) Read/Open/とか。ってのは何?
(HigePon) 以前はVnodeというものがいなくてFileSystemEntryとFileSystemが主役でした。
(HigePon) 前者がファイル・ディレクトリの基底クラス
(HigePon) 後者がコンクリートファイルシステムが実装すべきインターフェースを
(HigePon) きていしたもの。
(HigePon) さらにfile_serverには
(HigePon) ↑上の一行なし。
(Gaku) うぃ。それで、そろそろ、Read/Openの説明が↓
(HigePon) ISO9660FileSystemはこのルールにのっとり実装されています。
(HigePon) で、FileSystemEntry->Open/Readなどの関数が
(HigePon) 用意されています。
(HigePon) つまりファイルに対する操作は
(HigePon) ファイルが持つ。
(HigePon) という形。
(HigePon) 新しい実装はVnodeがファイル・ディレクトリをあらわします。
(HigePon) いろいろ考えた結果
(HigePon) open/readなどは
(HigePon) ファイルではなく
(HigePon) VnodeManagerが手続きを提供する形にしました。
(HigePon) 理由の一例として
(HigePon) 存在しないファイルのOpenをどう実装するかとか。
(HigePon) これが新旧で相容れない1点目です。
(HigePon) 説明一区切りです。>Gakuさん
(Gaku) インスタンスに対する操作。じゃなくて、そのものが属する領域に関する知識である。という立場か。
(Gaku) と思ったんだけど、もう少し現実的な理由なのね。
(HigePon) ですね。
(HigePon) もう一点理由を書いてみようかなぁ。
(Gaku) それで、ISO9660FileSystemなどの実装は旧実装を使いまわそうとしている。と。
(HigePon) です。
(Gaku) そうしたら、FileSystemEntryなんかもそのまま使う。と。
(Gaku) FileSystemEntryにOpen/Readがあるとして、これと至極似たインタフェースがVnodeだか、VnodeManagerだかにもある?16:39 (HigePon)     virtual dword Read(void* buffer, dword size);
(Gaku) 旧実装を使いまわしたいから、旧実装のインタフェースはそのまま残して、新実装でラップする。てのはよくある話だと思うのだけど。
(Gaku) お。説明を先に聞こう。
(HigePon) FileSystemEntryに実装されているやつ
(HigePon)     int read(dword fileID, dword size, monapi_cmemoryinfo** mem);
(HigePon) これが新しいほう。
(Gaku) 新しい方はVnodeManager?
(HigePon) です。
(HigePon) あ!
(HigePon) 重要なことを説明せねば
(Gaku) うぃ。
(HigePon) VnodManager->readは
(HigePon) FileSystemに実装されている
(HigePon) fs->readを呼びます。
(HigePon) なのでこの場合はfs->readのインターフェースも提示しないと
(HigePon) いけないや。
(HigePon)     virtual int read(Vnode* file, struct io::Context* context)                            = 0;
(HigePon) これ。
(Gaku) ん?「FileSystemEntryに実装されている。」じゃなくて?
(Gaku) FileSystem.readは、、、新たに作ったのか。
(HigePon) FileSystemに実装されている。です。
(HigePon) です。Gakuさんは理解が早い。
(Gaku) (しまった。FileSystem::readって記述しないと。パーソナリティが漏れる。
(HigePon) w
(HigePon) 今まで説明した。この問題。
(HigePon) と
(HigePon) FAT12/ISO9660の実装の違いをwrapする層が存在していること
(HigePon) が掛け合わされて
(Gaku) FileSystemEntry::readはどこから使われます?
(HigePon) 新しいほうで?
(Gaku) です。
(Gaku) 今までの話だと、旧実装を利用して、新実装を作る。ことに関する問題なので。
(Gaku) そうしたら、問題点は、旧実装を、新実装につなげるレイヤがちゃんと切れているか?
(Gaku) に集約されるハズ。
(Gaku) どこで、旧実装から新実装に処理を渡していますか?てのは重要な質問になると思うのだけど。どうかな?
(HigePon) ISO9660FileSystem::readでつかわれていますね。
(HigePon) その指摘はあっていると思います。
(Gaku) VnodeManager->read  ----->  FileSystem->read  ----->  ISO9660FileSystem->read  ----->  FileSystemEntry->read
(Gaku) くらいかな?
(HigePon) です。
(Gaku) 旧実装はFileSystemに隠蔽されている?
(Gaku) つまりVnodeManagerは旧実装に左右されないようになっている?
(HigePon) VnodeManagerは旧FileSystemのインターフェースには
(HigePon) 依存しないです。
(Gaku) あぁ。FileSystemに新旧両方のインタフェースを置いたのか。
(HigePon) そうそう。
(Gaku) そうね。FileSystemインタフェースは大混乱状態だな。
(HigePon) 一番の書き直したい理由は
(Gaku) 通常Adapter見たいなつくりにしたいはずだと思うのだけど。どうかな。
(HigePon) うーん。
(HigePon) wrapや調整にかけるコスト >> 書き直すコスト 
(HigePon) とか
(HigePon) 今後のメンテナンスのしやすさ
(HigePon) とかを考えて
(HigePon) 書き直したくなっている。
(Gaku) あれか。次は、どこを書き直したいのか?を聞いてみたほうがよいのか。
(HigePon) それは良いかも。
(HigePon) 前提としてVnode実装の肝は
(Gaku) まず、問題点として、新旧実装のつなぎになっているFileSystemインタフェースが汚くなりすぎた。ということがあがったと。
(HigePon) です。
(Gaku) するってぇと、FileSystemのところだけ整理すればえーやん。と思ってしまうのだけど。
(Gaku) 肝は?
(HigePon) Vnodeはファイルである
(HigePon) コンクリートFSはVnodeを知っている(Vnodeに依存している)
(HigePon) この2点。
(HigePon) かなと。
(HigePon) 思っています。
(HigePon) なので
(HigePon) ISO9660FileSystemをVnode依存できっちり書き直したい。
(HigePon) これが書き直したい1点目。
(HigePon) もう1点あって
(HigePon) 上がうまくいったらFAT12をwrapするのを書いて
(Gaku) ちょい待ち。
(HigePon) はい
(Gaku) 「コンクリートFSはVnodeを知っている」!!!
(Gaku) つまりコンクリートFSにも今回手を入れている?
(HigePon) Yes
(HigePon) ISO9660FileSystemとかいじりまくり(コード追加がメイン)
(Gaku) VnodeManager->新規実装、FileSystem->新規実装用インタフェースを追加、ISO9660FileSystem->新規実装のための修正
(Gaku) さて、使いまわしたいところはどこだ?
(Gaku) つまり、旧実装を残す理由になりえるところがあったか?が疑問点なのかな。
(HigePon) ですね。
(HigePon) 残すことのデメリットがかなり高いと思っています。
(Gaku) いや。追加がメインって事は、使ってるところもあるのでは?
(shadow-TC) OSサーバなんだから、2個動かしちゃダメなの?
(Gaku) 実際に作ってみてるのだから、ここは使いまわしてるな。ってところが分かるはず。
(Gaku) 全くないですか?使いまわしているところ。
(HigePon) もちろん旧ロジックをcallしているところは
(HigePon) あります。
(Gaku) 旧ロジックをcallしていて、そこが使いまわすに足るロジックである。ってのなら、そこのつなぎ方が悪い。という問題になると思うのだけど。
(Gaku) 旧ロジックをcallしているところが、たいしたことなくて、書き直すべきである。という判断なら、書き直したほうが良いと思うけど。
(Gaku) 何となく汚いなぁ。という理由だけなら、もう少し考察した方が良いような気はしますが、、、
(HigePon) 意見まとめ中。
(Gaku) あれかな。FileSystem / ISO9660FileSystem をラップするクラスを作って、そちら側に追加分のコードを分離できるなら、そのほうが良いかな。
(Gaku) そうする理由として、再利用できる旧コードがそれなりの分量あること。ってのが前提になるのだけど。
(HigePon) 僕が書き直す理由として思うのは
(HigePon) ・なんとなく汚いなぁというレベルを超えて現時点で、実装速度に影響が出ている
(HigePon) ・コードの混在が将来のメンテナンス性を下げる
(HigePon) ・wrapする時間的コスト > 書き直す時間的コスト
(HigePon) あたりかな。
(Gaku) ラップクラスがコスト高。という決心が付いたなら書き直しで良いかも。
(HigePon) お。
(HigePon) Gakuさんが納得したかも?
(Gaku) ちなみに現時点で、ラップするクラスに入るべき追加分と、ラップされる側のISO9660FileSystem辺りの再利用しているコード、の区別は付いてますか?
(Gaku) いや、もう少し。
(HigePon) ラップ戦略の話ですね。
(HigePon) 大体ついていると思います。
(Gaku) ですね。それと、書き直すにあたって、どれくらいのところが書き直されるのか。という見積もりにもなる。
(Gaku) どれくらい書き直す機能があるのか?ていう見積もりがついてるのなら、
(Gaku) それと、ラップした場合にどれくらいラップしなければならないか?ていう見積もりがついてるのなら、
(Gaku) それはラップクラスの方がコスト高、という判断にそれなりの裏づけがある。ってことだから、
(Gaku) まぁ判断を信用してもいーのでは?
(HigePon) ラップクラスは
(HigePon) コストは正確に見積もれていると思います。(実装しながらいろいろい見たので)
(HigePon) 書き直しは大体想像つくけど前者よりは正確な見積もりではないだろうな。
(HigePon) という感じ。(正直ベース)
(HigePon) Gakuさんのおかげでだいぶ考えがまとまった。
(HigePon) このろぐをwikiに貼り付けておいたほうが良いな。
(Gaku) もうちょい突っ込んで、新実装(例えばVnode)依存してるところを書き直すってなるはずだから、ココとココとココ。って書き直すべきところが分かるはずだと思うのだけど。
(Gaku) まぁその辺りはおいおい考えればいーかな?
(HigePon) まぁ具体的には、デバイスの操作とかが旧実装のパブリックメソッドに入っているので
(HigePon) それをprivate化して、新実装から呼ぶように
(Gaku) 転載は別段構いませんよ。

コメント

コメントはありません。 コメント/Nobita/020.vfs,vnodeのロードマップ/20060611?

お名前:

MENU

now: 8

リンク


最新の20件
2018-10-07 2018-09-20 2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-05-29 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 1879, today: 2, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:47:55 (3915d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.029 sec.