OSをつくろうpart4
■ このスレッドは過去ログ倉庫に格納されています
0001ひげぽん
NGNGスレッドになればと思います。
前々スレッド
OSをつくろうpart2
http://pc3.2ch.net/test/read.cgi/tech/1024411711/
前スレッド
OSをつくろうpart3
http://pc3.2ch.net/test/read.cgi/tech/1027080631/
0052ひげぽん
NGNG>>51
笑いました。
ところでvmwareって高いですね。ちょっと手が出ない（笑）
LightConeさん
nwsosのソースって公開されているんでしょうか。
ちょっと見てみたいなあと最近思います。
すんません独り言です、気にしないでください・・・
0053デフォルトの名無しさん
NGNGnwsosは商用を目指しているので、ソース公開はあり得ないんじゃないかな？
個人的には、商用クローズ開発と、オープン開発、お互いにどういう経路で
発展していくか？に興味あるので、nwsosとmonaに激しく注目している。
今のところ、さすがにnwsosとは比較にならない工事段階だけど、
比較対照としてはおもしろいと思ってます。
0054デフォルトの名無しさん
NGNG現在の段階では、識者からアドバイスを受けて成長するのが一番。
このスレの存在意義に、ひげぽんさんの成長も含まれていると思う漏れ。
0055ひげぽん
NGNG>nwsosは商用を目指しているので、ソース公開はあり得ないんじゃないかな？
>個人的には、商用クローズ開発と、オープン開発、お互いにどういう経路で
>発展していくか？に興味あるので、nwsosとmonaに激しく注目している。
そうですよね。
商用であるということ＆今までクローズでやってきた事から
オープンにするメリットは少ないかもしれませんね。
>簡単にソース見ちゃ詰まらないと思いますよ。
>現在の段階では、識者からアドバイスを受けて成長するのが一番。
>このスレの存在意義に、ひげぽんさんの成長も含まれていると思う漏れ。
そうなんですよね。
簡単にソースを見ちゃあいけない・・・分かっています。
ただ、煮詰まったときに 賢い人の書いたソースを見ると
目から鱗ですごく自分の成長になるんですよね。
もう少し煮詰まるまでがんばってみます。
0056デフォルトの名無しさん
NGNG神秘的で超自然的な夜の出来事
0057デフォルトの名無しさん
NGNGなんのために？？？
0058LightCone ◆sSJBc30S5w
NGNG>>ファイルシステムのコードを走行するのでしょうか。もしそうだとすると
>>並列製が落ちる可能性はありませんか。
>subsystemサーバープロセスのスレッド数を、プロセッサ数×n (※)などで
>決め打ちしておき、message-queueで処理するとか。(nまで再入可能)
>※ threadが極めて軽量な実装ならば、ユーザー側スレッドのトータル数でもいいかも。
ご返答有難うございます。
これは、例えば、ファイルシステムのプロセスが、内部的に固定的に、
5個のスレッドを持っているような状況を想像すればいいのでしょうか。
こういう仕組みでも一応「１プロセス」と言えなくもないわけですね。
これだと、確かに並列性は落ちないかもしれませんね。
マイクロカーネルは、それぞれのサブシステムがシングルスレッドしか
持ってないのだとに思っていたので、もっと並列性が落ちるのかと思って
ました。
0060LightCone ◆sSJBc30S5w
NGNGなんだか、NWSOSも、マイクロカーネルを採用したくなってきました。
ファイルシステムのプロセスが、メモリ空間的に分離されている別
プロセスのバッファを扱う仕組みを１分くらい考えてみたのですが、
どのようなものが考えられるでしょうか。
ちょっと思いついたのは、個々の一般ユーザープロセス内に、DLL の形で
「ファイルシステム-サポートライブラリ」みたいなものをロードして、
ファイルシステム本体のプロセスと通信するようなものです。
サポートライブラリ自体は、それぞれのユーザープロセスの全メモリが
可視なので、共通メモリなどを介して（コピーして）ファイルシステム本体
と通信をする、という方法です。
（ちょっと難しくなりそうですが、ページングを駆使すれば、コピーせずに
済ますこともできるかもしれませんが。）
仮想メモリ(固定ディスクとのSWAP)などとの連携も難しそうですが。
0061LightCone ◆sSJBc30S5w
NGNG>煮詰まったときに 賢い人の書いたソースを見ると
>目から鱗ですごく自分の成長になるんですよね。
私のコードにも恥かしながら汚い場所がいっぱい有り、それが公開に
踏み切れない理由の一つでも有ります。
他人のソースを見ると目から鱗、というのは、確かにありますね。
0062デフォルトの名無しさん
NGNGこのスレでもやってるな
58と60、59と61は一つのレスにまとめられるだろうに。
行き当たりばったりでレスせずに、もっと思慮を入れろよ
0064デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG0067デフォルトの名無しさん
NGNGとりあえず、文章書いたあと30分位置いてみる。
これくらいの流れなら、多少寝かせても亀になることはなかろう。
0068LightCone ◆sSJBc30S5w
NGNG文章が汚い、読みにくい、まとまりが無い、ということは認めます。
そういうことなら納得です。ついつい、殴り書きみたいな感じで書いて、
一度も読み返さない癖がありますので、、、（読み返すと何故かイライラ
するんです。）。
0069デフォルトの名無しさん
NGNG0070デフォルトの名無しさん
NGNG技術的なｳﾝﾁｸばかりじゃ飽きますし、頭も痛くなります。
0071デフォルトの名無しさん
NGNG同一人物の連続投稿はウザいだけ
0072ひげぽん
NGNGあーでもないこーでもないと考えるのが楽しいですね。
二つのプロセスの切り替え実験をやろうと思うのですが
設計の段階でいろいろと欲張りすぎて・・・破綻
の無限ループに陥ったりします。
0073デフォルトの名無しさん
NGNG定期ageするひげぽんがウザいだけ
0074デフォルトの名無しさん
NGNG0075デフォルトの名無しさん
NGNG>済ますこともできるかもしれませんが。）
既存のOSには見られない傾向ではあるんですが、ここは思い切って
アプリケーションが読み込みエリアを指定することができないファイルAPI作ってみては
いかがでしょ？通常、freadなどはポインタも指定しますが、これを指定させない。
で、かわりに、FileOpen時にメモリハンドラを貰う。
アプリはこのメモリハンドラ経由でアクセス。
OSがメモリプールを責任もって確保。
posixにあるようなfreadとかって前時代的な仕様だと思うんですよ。
アプリ屋のミスで不法なメモリでも平気でガツガツ書き込んでしまうし。
保護例外で止まってくれればまだありがたいんですがね。
0076LightCone ◆sSJBc30S5w
NGNG>アプリケーションが読み込みエリアを指定することができないファイルAPI作ってみては
>いかがでしょ？通常、freadなどはポインタも指定しますが、これを指定させない。
>で、かわりに、FileOpen時にメモリハンドラを貰う。
>アプリはこのメモリハンドラ経由でアクセス。
>OSがメモリプールを責任もって確保。
一度聞いてみたいアイデアなような気がしますので、
ここでおっしゃる「メモリハンドラ」というものの詳細や、この方式での
具体的なファイルアクセスの手順を聞ければ幸いです。
>posixにあるようなfreadとかって前時代的な仕様だと思うんですよ。
>アプリ屋のミスで不法なメモリでも平気でガツガツ書き込んでしまうし。
>保護例外で止まってくれればまだありがたいんですがね。
アプリ側が不法なバッファアドレスを指定した場合、fread() API 内部で、
スーパーバイザ権限で「身代わりアクセス」してしまうことを指摘されて
いるのですね。
ご存知かもしれませんが、これを防ぐ手は一応存在していて、API の処理冒頭
で、メモリが合法かどうかをソフト的にチェックするルーチンをかませば、
跳ね返せます。CPUの保護機能だけでは無理で、通常のCPU命令を用いて
ページテーブルやセグメントの属性やフラグ類をチェックしなければならない
ので、確かに煩わしいのですが。
0077ひげぽん
NGNGたいしたコンテンツはありませんが、最新版ブートイメージが
ダウンロードできます。
http://mona.sourceforge.jp/
タスク切り替えを試みているのですが
実際の切り替え部分(セグメント間ジャンプ)て、
インラインアセンブラでも可能でしょうか？
いろいろとやっているのですが、もし不可能なことを
試みているのであれば、方向転換が必要です。
0078LightCone ◆sSJBc30S5w
NGNG>タスク切り替えを試みているのですが
>実際の切り替え部分(セグメント間ジャンプ)て、
>インラインアセンブラでも可能でしょうか？
単体のアセンブラでさえ、通常はOS作成を前提にしていない場合が多い
ため、far jmp、その中でも特殊セグメントへの jmp 命令は記述が無理か、
または、出来たとしても特殊なOBJファイルを掃いてしまう場合があるため、
一番安心なのは、db 命令で直接埋め込む方法かもしれません。
あと、IA32の場合、タスク切り替え用の jmp 命令は、通常の命令の
組み合わせで書けてしまいます。フラグ類の設定を通常命令の組み合わせ
でやってしまうだけです。実はそちらの方が楽だったりします。
0079LightCone ◆sSJBc30S5w
NGNGIA32には、「タスク間jmp/call」「レベル遷移jmp/call」など色々
用意されていますが、なんのことはない、メモリ中のデータ構造のフラグ
変更と、レジスタセットの値の変更を超えるものではないんですね。
ページディレクトリの物理アドレスを保持するcr3、ローカルセグメント
のテーブルを設定する ldtr、Protect/V8086 モードを区別するeflags、
TSSセグメントセレクタtr などの設定を変えることや、全レジスタの
保存・復帰以外とには、特にやることは無かったと思います。
（tr から全ての情報がたどれますが、ltr 命令だけでは、確かcr3や、
ldtr は変更されなかったような気がします。）
0080ひげぽん
NGNG> 単体のアセンブラでさえ、通常はOS作成を前提にしていない場合が多い
>ため、far jmp、その中でも特殊セグメントへの jmp 命令は記述が無理か、
>または、出来たとしても特殊なOBJファイルを掃いてしまう場合があるため、
>一番安心なのは、db 命令で直接埋め込む方法かもしれません。
目から鱗です。db命令で埋め込むとは気づきませんでした･･･
最悪の場合この手があるのですね。ありがとうございます!!!
> あと、IA32の場合、タスク切り替え用の jmp 命令は、通常の命令の
>組み合わせで書けてしまいます。フラグ類の設定を通常命令の組み合わせ
>でやってしまうだけです。実はそちらの方が楽だったりします。
これは一応認識していたのですが、
たしかに、おっしゃる通りかもしれません。
0082ひげぽん
NGNGsecondboot.asmにてgdt関連の設定を行っています。
dw gdt_end - gdt0 - 1 ; gdt limit
dd gdt0 + 0x100 * 16 ; start adderess
プロテクトモード移行後
インラインアセンブラで
asm volatile("sgdt %0\n"
: /* no output */
: "m" (gdtr)
);
_sys_printf("gdtr.limit = %d\n", gdtr.limit);
_sys_printf("gdtr.base = %d\n", gdtr.base);
とやってみると
gdtr.limit = 31
gdtr.base = 0
と表示されます。
limitは意図どおりの値なのですが
baseの値が0というのが違和感があります。
何か大きな勘違いをしてそうで・・・
0084デフォルトの名無しさん
NGNG0085デフォルトの名無しさん
NGNG>>76
> 一度聞いてみたいアイデアなような気がしますので、
> ここでおっしゃる「メモリハンドラ」というものの詳細や、この方式での
> 具体的なファイルアクセスの手順を聞ければ幸いです。
メモリハンドラは、単なるポインタでいいと思う。C で書けば...
File F = fopen("test.txt", "r");
char *p = fread(F, 100);
とかすれば、OS が 100バイトの領域を確保して、そこにデータを読み込んでから、そのアドレスを返してくれるという感じかと...。
C だと、free(p) とかしないとダメだけど、Java とかならそれも必要ないだろうし。これで、fread() が間違ったアドレスにデータを書き込んでしまうことは防げるでしょ ?
> アプリ側が不法なバッファアドレスを指定した場合、fread() API 内部で、
> スーパーバイザ権限で「身代わりアクセス」してしまうことを指摘されて
> いるのですね。
今時、そんなタコな OS は無いでしょう。当然...
> ご存知かもしれませんが、これを防ぐ手は一応存在していて、API の処理冒頭
> で、メモリが合法かどうかをソフト的にチェックするルーチンをかませば、
> 跳ね返せます。
ぐらいはやってはず。そうではなく、fread() に間違ったアドレス指定して、自分で使う領域を壊したりするのを防ぎたいんだと思う。最近のコンピュータウィルスで使われるバッファーオーバーランとかを避けたいだけじゃないでしょうか。
> CPUの保護機能だけでは無理で、通常のCPU命令を用いてページテーブルや
> セグメントの属性やフラグ類をチェックしなければならないので、確かに
> 煩わしいのですが。
プロセサによっては、保護機能を使えるのもありますよ。(68K の moves とかね。)
0086ひげぽん
NGNG新たにTSSを追加をする場合
dt分のスペースをお尻に確保しなければならないことに気がつきました。
secondboot.asmで仮に設定しておいて
C++に移行してからもう一度設定しなおしたほうがいいのでしょうか。
うーん勉強が足りません。
0088ひげぽん
NGNGを立ち読みしてみました。
初めて読んだときはさっぱり分からなかったですが
難易度的にちょうど良く、自分の知りたいことが
たくさん書いてあるので欲しい。。。でも高い。
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4873110483/reviews/ref%3Ded%5Fer%5Fdp%5F1%5F1/249-3833329-4800325
どこかの古本屋に売ってないかな･･･
図書館でも良いな。
0089デフォルトの名無しさん
NGNGあれってソースがただ印刷されて、コメントが日本語訳されてるだけじゃなかった？
役に立つような解説はなかったような。
カーネルをダウンロードして読むってのじゃだめなのかな？
009089
NGNGこっちと勘違いしてた。上のは見たことない。
http://www.amazon.co.jp/exec/obidos/ASIN/4797820063/qid=1038350048/sr=1-6/ref=sr_1_2_6/250-3155597-6663410
0091デフォルトの名無しさん
NGNGhttp://www.ascii.co.jp/books/detail/4-7561/4-7561-3313-4.html
0092LightCone ◆sSJBc30S5w
NGNG詳細Linuxカーネル 5800円：高いですが参考になりそうなので一ヶ月ほど前に購入。
Linux2.4 インターナル 3200円:内容は上記より少なめですが、短いので読みやすいかも。
OS そのものとは関係有りませんが、SHELL プログラミングでお勧めなのが、
SOFT BANK「入門UNIXシェルプログラミング」Bruce Blinn著 山下 哲典 訳
0093LightCone ◆sSJBc30S5w
NGNG（恐らく）転送時間が1レベル増えるであろうことを気にしないなら単純でよさそうな方法
ですね。
セクタの内容をキャッシュするセクタバッファの他に、ファイルごとに
キャッシュするファイルバッファというものがあるそうですが、後者を
うまく使えばバッファの転送時間もかなり減らせるかもしれませんが。
0094LightCone ◆sSJBc30S5w
NGNG>そうではなく、fread() に間違ったアドレス指定して、自分で使う領域を
>壊したりするのを防ぎたいんだと思う。最近のコンピュータウィルスで使わ
>れるバッファーオーバーランとかを避けたいだけじゃないでしょうか。
fread()の場合は取得サイズをアプリ側が指定するので特に問題は
ないと思うのですが、OS側から可変長のデータを取得する時には
その問題を感じます。
例えば、何らかの文字列データ(例では他のタスクの名称)をOSから
取得したい時、APIによっては次のような形式を用いますが、ちょっと問題
を感じます。
<<続く>>
0095LightCone ◆sSJBc30S5w
NGNG//int GetTaskName(HTASK hTask, char *pFilename);
void PutTaskName(HTASK hTask)
{
int size = GetTaskName(hTask, NULL);
if (size == 0) {
put_err("hTask is wrong?");
}
char *pName = malloc(size + 1);
if (ptr == NULL) {
put_err("Memory shortage!!");
}
else {
GetTaskName(hTask, pName);
printf("The name of task(%08X) is %s\n", hTask, pName);
free(pName);
}
}
一言メモ:
GetTaskName(hTask,pName)は、pName にNULLを指定すると、
受け取るタスク名の長さを返す。通常、二度呼び出して、pNameのバッファ
をアプリ側が確保する。
0096LightCone ◆sSJBc30S5w
NGNGここで問題となるのは、hTaskの名前が二度のGetTaskName()呼び出しの
間に変化する可能性です。起動後のタスクではタスク名が絶対変化しないよう
なシステムだと問題なくても、SetTaskName()のようなAPIが用意されている
場合に問題が起きます。
もし、今の例の様に、GetTaskName()を二度呼ぶような仕様だと、
何らかのロック処理が必要になるはずですが、現実のよく知られたOSでは
私の知る限りそれが出来ないケースがあります。
このような場合には、
const char *GetTaskName2(void);
のようなAPIの方が簡単では有ると思います。ただし、これにも短所が
あります。空システムメモリ空間が圧迫される可能性があることです。
0097ひげぽん
NGNG>こっちと勘違いしてた。上のは見たことない。
おお、こんなのもあるんですね。
指定されたURLのレビューを見ると詳解の後に
読むことを薦めていますね。
>>92 LightConeさん
>詳細Linuxカーネル 5800円：高いですが参考になりそうなので一ヶ月ほど前に購入。
えっと、だいぶ背中を押されました（笑）
たぶん買います、いやきっと買うでしょう。
>OS そのものとは関係有りませんが、SHELL プログラミングでお勧めなのが、
>SOFT BANK「入門UNIXシェルプログラミング」Bruce Blinn著 山下 哲典 訳
これ会社の同僚が持っていた気がします。仕事でcshを使うので
ちょっと見せてもらってみます。
0098ひげぽん
NGNG>ＢＳＤだけどこれがお勧め
>http://www.ascii.co.jp/books/detail/4-7561/4-7561-3313-4.html
これ安いですねぇ。
内容の難易度的にはどうなんでしょうか。
今度本屋で探してみます。
0099LightCone ◆sSJBc30S5w
NGNGOS作りでは、実はコマンドラインSHELLがかなり重要なのではないかと
思えてきた今日この頃です。
UNIX好きの人でも、CYGWIN環境があれば満足してしまう人も多いようで、
一番大きな理由が、UNIX互換のシェルが使えるからだそうです。
UNIXは、カーネルも優れた側面を持っていると思いますが、
シェル、特にシェルスクリプトの機能（その一行切り出しとしての
コマンドライン解釈部）が強力なことも見逃せないと思います。
それにしても UNIX のシェルはいいですね。
0100デフォルトの名無しさん
NGNGC言語でモニタとコルーチンを実装（ライブラリを作成）したいのですが、
WEBで探してもなかなか合った文献がみつかりません。
どなたか、実装方法教えてくれませんか？
WEBや書籍でもいいのでお願いします。
＊Modula-2からCへの移植を行うため、モニタとコルーチン機能がCで必要になりまし
た。
0101デフォルトの名無しさん
NGNG中級ぐらいと思う。
メインはデバドラとブートコード。
「詳解Ｌｉｎｕｘカーネル」はあまりLinux板では評判よくなかった。
自分ももってるけどLinuxOSの概念の説明で
具体的なコードが書かれてないからすきじゃない
0102LightCone ◆sSJBc30S5w
NGNG良いことを聞きました。
「詳細Linuxカーネル」は訳本のせいもあるのか文章量が多めで、途中から
斜め読みするには辛いものを感じていたのですが、よく考えるとこの本は、
プログラミング言語で書かれた部分は、構造体定義のみで、他は
ほぼ全て自然言語で書かれています。プログラミング言語も適度に有った
方が分かりやすいのかもしれませんね。今度ご紹介の本を見てみたいです。
0103デフォルトの名無しさん
NGNG0104LightCone ◆sSJBc30S5w
NGNGソースをコピーしない限りは、恐らく大丈夫かと。
特許が採られてない限り、技術の内容を真似ること自体は自由では？
そうでないと、知らず知らずにGPLのソースを偶然目に触れてしまって、
いつのまにか真似てしまった場合などにおかしなことになるかと。
0105デフォルトの名無しさん
NGNGmonaはGPLだったと思うけど。
0106デフォルトの名無しさん
NGNG> ソースをコピーしない限りは、恐らく大丈夫かと。
これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
ていて、見てしまった場合は別の実装を考えるように推奨しています。
日本の法律ではコピーしなければ大丈夫だったと思うけど、海外から訴えられ
たらたまらんですな。
0107ひげぽん
NGNG>メインはデバドラとブートコード。
ありがとうございます。
なるほど、詳解Linuxカーネルはほとんどソースがないということであれば
立ち読み程度にしておこうかな・・・
ご存知かもしれませんがこんなのを見つけました。
http://lkh.linux.or.jp/24kernel/source/html4/boot.html
0108ひげぽん
NGNG>>104
>>105
>Linuxのソースを参考にしながら開発するとmonaはGPLになると思われるがよいか？
一応monaはGPLなので問題ないかと。
LightConeさんの仰るとおり
>ソースをコピーしない限りは、恐らく大丈夫かと。
という認識で私もやっています。とおもったら・・・
>これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
>GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
そうなんですか･･･
いろいろなフリーのOSのソースを見て勉強してしまっているんですが･･･
いちおう参考にすることはあっても、コピーはしないようにしています。
自分のためになりませんし･･･
0109LightCone ◆sSJBc30S5w
NGNG>> ソースをコピーしない限りは、恐らく大丈夫かと。
>これはGNUプロジェクトでは"駄目orグレー"だと認識されています。そのため
>GNU Coding Standardには"他の実装(Implementation)"を見ないことを推奨し
>ていて、見てしまった場合は別の実装を考えるように推奨しています。
こわばら こわばら。
「見てない」って言い張るだけで回避可能とかではない？
0110FreeDOS教徒
NGNG‥‥ていうか、コピペまがいの行為はしないから、大丈夫でしょ？
実装が似通う例なんて腐るほどあるし。
0111LightCone ◆sSJBc30S5w
NGNG>‥‥ていうか、コピペまがいの行為はしないから、大丈夫でしょ？
してないつもりです。
>実装が似通う例なんて腐るほどあるし。
そうですよね、、、。
もし、GPLのソースを見て勉強しただけで、自分のプログラムのライセンスまで
制約されると言うのならば、かなり無理が有りませんか。
0112デフォルトの名無しさん
NGNG0113デフォルトの名無しさん
NGNG> GNU GPLにそこらへんの基準は載ってないのね。
いや、GNUの場合はUNIXの著作権を侵害しないように気を付けろってことだし、
"よりCoolな実装"を目指せば、同じにはならないでしょ。
似たものになっても、より優れていれば大丈夫。
当然、悪くても可 > オレモナー
0114デフォルトの名無しさん
NGNGそう言ってるともとれるのがGPLです。
0115デフォルトの名無しさん
NGNGttp://www.sra.co.jp/wingnut/standards/standards-ja_2.html
0116デフォルトの名無しさん
NGNG> ここで問題となるのは、hTaskの名前が二度のGetTaskName()呼び出しの
> 間に変化する可能性です。
普通、ユーザーが確保した領域に書き込む API は、サイズを渡すように
なっていて、気の聞いた API/OS なら、入りきらない時は必要なサイズを
返すようになってたりすると思うけど ? (例えば、Win32 の
GetWindowsDirectory() とか。)
悪いけど、もう少し他の OS の勉強した方がいいと思うよ。
> 何らかのロック処理が必要になるはずですが、
そんなことしたら、わざとロックかけて SetTaskName() しようとしている
タスクの実行を邪魔することができちゃうよ。(バッファを別に持つとかし
て、回避できるだろうけど、複雑になるしね。)
> ただし、これにも短所があります。空システムメモリ空間が圧迫される
> 可能性があることです。
どう言うこと ?
0117デフォルトの名無しさん
NGNGhttp://aglaia.c.u-tokyo.ac.jp/~yamamoto/UNIX/kernel/
http://www.graco.c.u-tokyo.ac.jp/~kamina/jugyo/kernel/chap4_half/
0118デフォルトの名無しさん
NGNGきっとタスク名をシステムメモリ空間に確保したバッファに書き込んでユーザープロセスに返すのでしょう。
どうやって読み出すのかは知りませんが。
0119LightCone ◆sSJBc30S5w
NGNG>普通、ユーザーが確保した領域に書き込む API は、サイズを渡すように
>なっていて、気の聞いた API/OS なら、入りきらない時は必要なサイズを
>返すようになってたりすると思うけど ? (例えば、Win32 の
>GetWindowsDirectory() とか。)
そういうAPI仕様は知ってはいましたが、#94-#96では言及できてません
でした。すみません。
UINT GetWindowsDirectory(
LPTSTR lpBuffer, // Windows ディレクトリが格納されるバッファ
UINT uSize // ディレクトリバッファのサイズ
);
その方法では結局、実際に文字列を取得する際のサイズが前回取得した
文字列のサイズ以下になるまで繰り返しが必要になり、単に文字列を
取得したいたびにそのようなループを書く必要があることになる
わけですよね。
結局#96での結論と同じく、
const char *GetTaskName2(HTASK hTask);
というような API 仕様だと便利だと思うんです。
0120LightCone ◆sSJBc30S5w
NGNG>きっとタスク名をシステムメモリ空間に確保したバッファに書き込んで
>ユーザープロセスに返すのでしょう。
その通りです。 ただし、API呼び出し時に書き込むのではなく、元々存在
している場合の方が多いかもしれませんが。
>どうやって読み出すのかは知りませんが。
共通空間でも、ユーザーが読めるようにすることは可能です（書けるように
することも可能ですが）。
メモリ空間がタスク固有空間か共通空間かと、アクセス禁止属性は独立
して扱えますので。
一応、NWSOS でも、
const char *GetTaskFilename( HTASK hTask );
というAPIにしてみています。
http://homepage2.nifty.com/nowsmart/nwsosapi.htm#NWSOS API
0121デフォルトの名無しさん
NGNG0122デフォルトの名無しさん
NGNG0123デフォルトの名無しさん
NGNG…。･･･。･･･。
0125デフォルトの名無しさん
NGNGありがとう。
0126デフォルトの名無しさん
NGNGLightConeさんはカーネル内部にTASKのデータを持たせておいて、
外部からはHTASKで操作し、
>>116さんはTASKのデータをTASKに持たせておいて、
カーネルではTASKのIDとかで識別できる程度にしておいて、
カーネルからのメッセージでTASKが動作するといったイメージでしょうか？
# 必要なデータはTASK側で確保するってこと。
そうだとすると、マイクロカーネルを目指すmonaとしては後者の方が
有利だと思うのですが、何か間違ってます？
0127ひげぽん
NGNGどなたかアドバイスください。
長文になることをご了承くださいm(__)m
Monaではsecondboot.asmにて以下の手順で
ディスクリプタテーブルの設定を行っています。
(1)lgdtにてロード(エントリー数は4)
(2)プロテクトモードに移行
(3)far jump 0x08へ
(4)レジスタの設定
(5)オフセットアドレス決めうちでCで実装したコードへjump
ここまで前提です。
最近タスク管理を実装しようと思い勉強していたのですが
基本的にはタスクひとつにつきTSSが必要っぽいことが分かりました。
エントリー数が足りない・・・
0128ひげぽん
NGNG(A)セグメントのエントリ数はどのくらいが適当か？
(B)固定or動的にエントリ数を増やせるような仕組み
どちらが一般的でしょうか？
もし固定であればsecondboot.asmにて
エントリー数分メモリを確保しようと思っています。
(C)動的な場合
エントリー数が増えた場合、連続領域にメモリを確保し
lgdtをしなおさなければならないと考えていますが
lgdtを複数回行うのはありでしょうか。
(D)secondboot.asmにてlgdtを行わず
プロテクトモード移行後に、Cで実装している部分
monaKernel.cppでlgdtを行うことは可能か？
「はじめてよむ486」にはプロテクトモード移行後
セグメントレジスタにセレクタ値をロードするまでは
リアルモードのセグメント配置を引きずるとあるのですが・・・
※これが可能であれば、エントリ数を増やすときに
secondboot.binのサイズを固定のままでよいかと考えています。
(C)(D)は実際に自分で、いろいろやってみているのですが
現時点では成功していません。
0129LightCone ◆sSJBc30S5w
NGNG>TASKのデータをTASKに持たせておいて、
>カーネルではTASKのIDとかで識別できる程度にしておいて、
>カーネルからのメッセージでTASKが動作するといったイメージでしょうか？
「メッセージでTASKが動作する」と言う意味がよく分からないのですが、
TASKならではの情報は、なるべくそのTASK独自のメモリ空間に入れるべ
きだということは同感です。
しかし、共通空間に入れたほうが簡便になる場合もあるので、事情に
よりけりだと思います。
他のタスク固有の情報を、「運んでくる」と言うのは結構メンドクさく
感じます。多分、
1. ページングで「窓」をあける。
2. 一旦、ソース側のタスクにいる時に共通空間にコピー、デスト側に来た時に
共通空間からコピー
みたいな感じになるのでしょうか。
0130LightCone ◆sSJBc30S5w
NGNG>基本的にはタスクひとつにつきTSSが必要っぽいことが分かりました。
>エントリー数が足りない・・・
基本的にはそうで、最新版のNWSOSでは、タスクごとにTSSを用意して
いるのですが、同一タスクのスレッド（軽量タスク）では同じTSSを指
しています。
しかし、Linux 2.4 では、TSSはひとつだそうです。
ちなみに、タスクゲートは、Linuxでも用いていないそうです（NWSOSでも）。
0131超先生＠OS板 ◆leaf/RYZgY
NGNG＜ ｀ー´＞y-~~~
個人的にはTSSを使うのはあまり好きじゃないな・・・。
コンテキスト保存用のブロックが無駄に大きすぎる。
nest-taskができるのは便利なんだが。
0132LightCone ◆sSJBc30S5w
NGNG調べて見たところ、NWSOSでは、lgdt は、初期化時に一回だけ、
8192 個のリミットで確保していました（TSS領域自体は、動的に
確保しています。）。
多分、lgdtは何度でも行えると思うんですが、その際必要となるのが、
「連続した”物理”アドレス」ですので、動的に伸張していく際、
必要なサイズの「連続した物理アドレス」が空いてない場合は、
どこかにページングされているものから集めてくる処理が必要にな
ると思います。
0133ひげぽん
NGNG>基本的にはそうで、最新版のNWSOSでは、タスクごとにTSSを用意して
>いるのですが、同一タスクのスレッド（軽量タスク）では同じTSSを指
>しています。
なるほど、スレッドは、メモリ空間？を共有している特殊なタスクということですね。
ということは、エントリ数は512とか256位必要な気がしますね。
>しかし、Linux 2.4 では、TSSはひとつだそうです。
どういう方法をとっているのでしょうか。なぞです。
でも結局はTSSに相当するものはどこかに持っていないとおかしいですよね。
0134ひげぽん
NGNG>個人的にはTSSを使うのはあまり好きじゃないな・・・。
>コンテキスト保存用のブロックが無駄に大きすぎる。
勉強不足なのですがTSSの使用はmustではないのでしょうか？
segment typeはTSSでなくても、結局は使用するセグメントを
ディスクリプタテーブルに登録しなければならない気がするのですが
激しく勘違いしているかもしれません。
0135LightCone ◆sSJBc30S5w
NGNG超先生、コメント有難うございます。
Linuxの参考書を見るべきかもしれませんが、
TSSを固定するとなると、I/O 許可ビットマップは利用しないという
ことなんでしょうか。in/out 命令は全部例外を起こさせて
エミュレートするか、I/O用システムコールを利用？
0136ひげぽん
NGNG> 調べて見たところ、NWSOSでは、lgdt は、初期化時に一回だけ、
>8192 個のリミットで確保していました（TSS領域自体は、動的に
>確保しています。）。
わざわざ調べていただいて恐縮です。
なるほどNWSOSでは最初に一回多めにとっているのですね。
結局は、この方法がベストな気がします。
>多分、lgdtは何度でも行えると思うんですが、その際必要となるのが、
>「連続した”物理”アドレス」ですので、動的に伸張していく際、
>必要なサイズの「連続した物理アドレス」が空いてない場合は、
>どこかにページングされているものから集めてくる処理が必要にな
>ると思います。
おっしゃるとおりですね。
動的拡張は、ちょっと面倒であまりメリットがないかもしれません。
結局は初期サイズで余分に取っておくでしょうし･･･
0137LightCone ◆sSJBc30S5w
NGNG(SS0:ESP0, SS1:ESP1, SS2:ESP2) がCPUによって自動参照されて
しまうはずなので、TSSの切り替えをしない場合は、そこをタスク
スイッチ時に書き換える必要がありますよね。違っていたらNWSOS
では無駄なことをしていることになりますが、それをしないと確実に
暴走するので間違いないと思います。
最新版のNWSOSでは、スレッドを切り替える際は、TSSを変更せずに、
そこだけを書き換えてます。
他の項目は、タスクゲートなどを使わないなら書かなくていいん
はずですよね。TSSの CR3,LDTR などもどうでもいいんですよね。
TSSの「レジスタセーブ領域」は、自信を持って書き換える必要がないと
言えます。
なぜなら、最新版NWSOSでも利用せずに、独自の構造体に入れてますので。
0138超先生＠OS板 ◆leaf/RYZgY
NGNG使わないというか、TSS一つを共有と。
>TSSを固定するとなると、I/O 許可ビットマップは利用しないという
>ことなんでしょうか。in/out 命令は全部例外を起こさせて
>エミュレートするか、I/O用システムコールを利用？
そもそもi386以外ではI/O access mapのようなものはないですからね。
移植性を考慮すると、subsystemプロセスに限定しても、
直接ユーザーランドからI/O命令を発行するような実装は綺麗でないです。
0139LightCone ◆sSJBc30S5w
NGNG>勉強不足なのですがTSSの使用はmustではないのでしょうか？
恐らくその通りで、Linux でも、TSSは、一つだけは使っています。
超先生がおっしゃっているのは、TSSを複数使うかどうかだと思います。
#135 の私の質問も、その意味で書いたつもりです。
0141LightCone ◆sSJBc30S5w
NGNGLinuxが、in/out 命令をユーザーレベルで直接使わずに、関数コール
しているのかが今分かった気がします。
やはり、TSSは、一つだけ固定的に持つのが一番賢そうですね。
そして、タスクスイッチ時は、「TSSの内側スタックポインタ」だけを
書き換えればいいわけですよね？
0142ひげぽん
NGNG>やはり、TSSは、一つだけ固定的に持つのが一番賢そうですね。
となると、TSSをタスクの数だけ用意するのは
何もメリットがないのでしょうか？
0143ひげぽん
NGNGそうすればセグメント間ジャンプのときに
セグメントタイプがTSSであることをCPUが検知してくれて
TSSの内容を参照し、セグメントを切り替えてくれる。
OS側では、タスク切り替えの前にTSSディスクリプタが持つ
TSSのアドレスに切り替えたいタスクのTSS構造体のアドレスを設定する。
うーんなんか間違っている気がします･･･
0144LightCone ◆sSJBc30S5w
NGNG>となると、TSSをタスクの数だけ用意するのは
>何もメリットがないのでしょうか？
複数使うメリット:
1. タスクゲートなどを使ったCPUネイティブなタスクスイッチが行える。
2. 割り込みなどをタスクゲートで行える。その際「ネスト」できるハズ。
3. TSSの「内側レベルのスタックポインタ」を頻繁に書き換えないで済む。
4. I/O 許可ビットマップを（一々コピーすることなく）利用できる。
複数使うデメリット:
1. タスク数に制限がついてしまう
2. I/O ビットマップを使うとなるとメモリが無駄。
3. セグメントレジスタの DWORD align が無駄
（だけどアクセス高速化のためには結局必要かも）。
0145LightCone ◆sSJBc30S5w
NGNG>そうすればセグメント間ジャンプのときに
>セグメントタイプがTSSであることをCPUが検知してくれて
>TSSの内容を参照し、セグメントを切り替えてくれる。
CPU定義のタスクジャンプや、タスクコールを使わないで済ますんです。
あと、タスクスイッチを伴うjmpは、「セグメント間ジャンプ」
とは言わない習慣のはずです。
0146みとこ ◆AEqcy/sQU6
NGNG物理アドレスを使うのはCR3とページディレクトリ・ページテーブルだけですよね？
0147デフォルトの名無しさん
NGNG> その方法では結局、実際に文字列を取得する際のサイズが前回取得した
> 文字列のサイズ以下になるまで繰り返しが必要になり、単に文字列を
> 取得したいたびにそのようなループを書く必要があることになる
> わけですよね。
ライブラリというものの存在はご存知 ?
個人的には、OS が勝手に領域を確保するという仕様は好みでない。
全ての言語が動的メモリーをサポートしているわけじゃないからね。
文字列領域をユーザーに確保させるか環境が確保するのかは言語/ライブ
ラリ作成者が決めればいい話で OS が決めることではないと思う。
重要なことは、const char *GetTaskName2(HTASK hTask); と言う API
を使って領域を確保しないでタスク名を取得することはできないけど、
GetWindowsDirectory() なら、ライブラリで領域を確保することもでき
るし、ユーザーに領域を確保させることもできると言う自由度があると言
うこと。その自由度を捨てて OS でできる限り安全にすると言うのも一つ
の方向ではあるけどね。
0148デフォルトの名無しさん
NGNG> >>116さんはTASKのデータをTASKに持たせておいて、
> カーネルではTASKのIDとかで識別できる程度にしておいて、
>>116 では、タスク名称の置き場所とかには言及してません。
まあ、普通は TCB (Task Control Block) 等のタスク管理領域に置くと
思う。
> カーネルからのメッセージでTASKが動作するといったイメージ
> でしょうか？
これは、まずいと思う。ps や taskmgr.exe で、ハングアップしたタス
ク名称が取得できなくなってしまう。
0149126
NGNG説明ありがとうございます。できるだけ小さいカーネルと、周りのプログラム
というのが実現できればいいと思ったのですが、ある程度のメモリサイズは
どうしても必要になるのですね。書籍の勉強だけでなく実装の勉強も
してみます。ありがとうございました。
0150LightCone ◆sSJBc30S5w
NGNGホントですね。すみません。
lgdtで指定するのは「連続した線形アドレス」でした。
gdtrやidtrは、「セレクタ」が必要ないんでしたか。最近忘れてます。
0151みとこ ◆AEqcy/sQU6
NGNGｾﾚｸﾀが必要なのはLDTRやTRですね。
■ このスレッドは過去ログ倉庫に格納されています