NegitoroOS Project 【一巻目】
「OSを一行で作るスレ」から開発が始まった NegitoroOS Project のスレです
【SF.JPプロジェクトページ】 http://sourceforge.jp/projects/negitoro/
【プロジェクトWiki】 http://negitoro.wiki.fc2.com/
>>4
長く開発を継続していたわけなのですが、すみませんが正直なところ、プロジェクト自体がまだ不安定なものであるので、明示的にNegitoro自体の特徴がどのようなものなのかということは説明できません。
加えて私自身が今年大学受験ということもありまして、開発に専念できていないのが今の現状です。 んと、まあ将来の目標はそれとして、スレ立ったことだし
開発状況、特に現状でのアピールポイントが知りたいなっと。
私が把握しているのは、
・一行スレから始まった企画で若手が集まった
・はりぼて系
・シリアルポート あり?
こんなところかな?
KOZOSのLANとかは載らないものだろうか。
まだないようなので、前スレへのリンクを張っておきます
ttp://kohada.2ch.net/test/read.cgi/os/1228318077/
さて本題
Sourceforgeの開発者MLではちらっと言及したのですが、
私はOS全体の構造を大きく作り変えることを計画しています
後ほど文章を整えてきますので、意見をいただければ幸いです 現在のNegitoroOSの構造は(こういう言い方が妥当かどうかは分かりませんし、ある種のレッテル貼りになりますが)モノシリックカーネルであると言えます
これはベースとなったはりぼてOSから引き継ぐ性質の一つです
具体的には、C言語で書かれたカーネルにキーボード・マウスドライバやシェルも組み込まれている、オールインワンの一枚岩構造です
アプリケーションの実行は常にシェルから行われ、アプリケーションがシェルに依存しないスレッドを持つことはありません
さて、私が実現したいアイディアは主に3つに分けられます
「フィールド指向マイクロカーネル」「データ取り扱いの支援」「徹底したセキュリティ」
(以下、突拍子もないように思われる独自の単語が頻出します ただの厨二なので適当に流してくださいww)
*** マイクロカーネルについて ***
これから提案するシステムでは、システム全体は「フィールド」というものの集まりとみなされます
実行中のプロセスは一つ以上のフィールドを所有し、複数のプロセスがある一つのフィールドを共有してもかまいません
フィールドは0個以上有限の他のフィールドと双方向のリンクを持ちます
プロセスは自分が所有するフィールドに対し以下の操作を行えます
1.あるフィールドに「エルフ」という小プログラムを「召喚」すること
2.あるフィールドに「スペル」を「唱える」こと
さて、プロセスがあるフィールドでスペルを唱えると、そのフィールドに召喚されているすべてのエルフがそれを聞き、
自身がそのスペルを理解できるかどうか判定します
スペルを理解できるエルフがいた場合、以降の処理はそのエルフに任されます
そのようなエルフがいない場合、リンクでつながっている他のフィールドにスペルがブロードキャストされます
スペルを理解できるエルフが見つかるまでこれが繰り返され、結果としてフィールドとリンクのグラフで幅優先探索が行われます
システムをこのような構成にするのは、「面白そうだ」という好奇心が一番ですが、
すでに実行中のプロセスの動作を乗っ取ることが容易に行えるからという理由もあります
すなわち、そのプロセスが所有するフィールドと他のフィールドとのリンクの間に別のフィールドを差し込み、
適切なエルフを召喚しておくことでそのプロセスが受け取るべきスペルを横取りできるわけです
これをカーネル自身に対して行うと、ユーザレベルでカーネルの機能拡張が可能になります
*** データの取り扱いについて ***
コンピュータの処理というのは、暴論すればデータの変換とフィルタに集約されます
その支援として、UNIX風のパイプに2つの拡張を与えることを考えます
まず、流せるデータをバイト列に制限しないこと
例えば、ビット、ニブル、Shift-JIS文字、カンマ区切り文字列、高々加算集合、タプル、2次元配列、グラフ、JPEG画像、はたまたチューリングマシンなどなど
コンピュータ上に表現できるありとあらゆるデータをパイプに流すことを許します
もう一つの拡張は、パイプの入力元・出力先をそれぞれ一つずつに限らないこと
例えば、このシステムが実現してGUIを実装するなら、キーボード・マウスのイベントはパイプから入力するようにするでしょう
マウスイベントをファイルに記録し、パイプを通してプロセスに渡すなどといった操作もサポートします
*** セキュリティについて ***
このシステムでは、プロセスがOSに何かをするとき、必ずフィールドとスペルを用いるので、
システム内を流れるスペルのすべてを監視する機能を提供することで、プロセスの行動を逐一記録することが可能です
必要とあらば、API呼び出しのすべてにユーザレベルでカスタマイズ可能なフィルタリングルールを適用することもできます
これらのアイディアはどれもどこかで聞きかじったのをOS向けに組み合わせてみただけです
実年齢中二のころからのある種の妄想ですが、適切に仕様を決めていけばある程度は実現可能かと思い、文章に起こしてみました
駄文かつ長文となりましたが、何かご意見などありましたらお聞かせ願えると幸いです
>システム内を流れるスペルのすべてを監視する機能を提供することで、プロセスの行動を逐一記録することが可能です
つまり、セキュリティ、機密性は皆無ってことかな? > すでに実行中のプロセスの動作を乗っ取ることが容易に行えるから
> ユーザレベルでカーネルの機能拡張が可能
セキュリティもへったくれもないな 貴重なご意見ありがとうございます
>>12
だいたいそういうことです
>>13
先にセキュリティという単語を使ったのは、
例えば「システムのファイルを破壊する」などの不正な処理をするプログラムを実行時に検出・阻止するという意味のつもりです
システムや管理者からはプロセスのどんな活動も監視できます
その意味では、今のところまだ機密性については考えていません
>>14
もちろん他のプロセスに影響を及ぼすような処理については、事前にあるいは実行時にユーザに確認を取るなどして、
適切な権限を持ったプロセスだけが実行できるように配慮します
特に、カーネルのプロセスに手を加えるには管理者ユーザの権限を要求するでしょう
>例えば「システムのファイルを破壊する」などの不正な処理をするプログラムを実行時に検出・阻止するという意味のつもりです
んなもんDosにしてやられるのがオチ
なんか話を聞いていると、iOSやアンドロイドの面白くない所だけ取り入れようとしているように聞こえる。
携帯世代ってそういうものなのかな? ソケットの場合、ポートナンバーで「スペル」のタイプがわかるようになってる。
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
例えば9801ならえんいーとか謎のスペルが書いてあるんだろう、多分。
但しFATの拡張子と同じ問題があって、独自フォーマット=プロトコルを使う奴は居るし、
居なきゃ居ないでBTRONのTADみたいにそっぽ向かれちゃうしなあ。 >>10
> プロセスは自分が所有するフィールドに対し以下の操作を行えます
> 1.あるフィールドに「エルフ」という小プログラムを「召喚」すること
> 2.あるフィールドに「スペル」を「唱える」こと
> さて、プロセスがあるフィールドでスペルを唱えると、そのフィールドに召喚されているすべてのエルフがそれを聞き、
> 自身がそのスペルを理解できるかどうか判定します
この「エルフ」というものは、そのプロセスを利用するプログラムのことですよね。
「スペル」というのは、Linuxでのシグナルのようなものということでいいのでしょうか。
また、このフィールドはいわゆるサンドボックスのような機能も同時に持っているように見えます。(カーネルがフィールドとプロセスを監視し、状況に応じてプロセス単位かフィールド単位で破棄を行う) GStreamerで言うところのエレメントだろうか? なんか「スペル」とかそういう名前を使うのが目的って感じがするな
どういう使い方をしてどういうメリットがあるのかさっぱり見えない
エルフをストリップでマッハオー
TADも実行バイナリ入れられるんだっけそういえば。 TADには(公開されてる限りでは)そういうのはないよ。 入れられるでしょ?
アーヴ語と違って機械語の文章データをTRONコードで扱う方法は知らないけど。
大体、TADデータとは実身の内の文章データと図形データを言うみたいだけど、
TADデータレコードなんてレコードタイプはそもそも実身レコードに存在しないから意味不明だな。 TADってのは、管理情報セグメントが先頭に付いて、そのあとに文章または図形のセグメントが
続いた、オクテットの並び、がTAD。
指定付箋セグメントを使えばなんでも入れられるけど、それは指定付箋セグメントには
どんなオクテットの並びも入れられるから、というだけ。
レコードタイプとかは1Bや3Bにおける実装の詳細というか、レイヤが違うというか。
TADデータはTAD 主レコードに入れることになってるけども。 実行機能付箋レコードはTAD データ構成で規定となっていて、
実行プログラムレコードは標準オブジェクト形式で規定となっている。
標準オブジェクト形式というのがTRON 仕様多国語文字コードのように
TADのサブセットなのかは知らないけど、サブタイプにPPCもMIPSもARMも記述が無いんだよな。
これitronじゃどうしてるんだろ? 実行機能付箋レコードの中身は、TADの機能付箋セグメント
(仕様書の第1編第3章§3.4.7)だから、実行可能バイナリを入れるものじゃない。
標準オブジェクト形式というのは多分BTRON286の頃にはちゃんと定めてた
のだろうが、今はGNU binutilsとか使ってるし、なしくずしにELFなんじゃないかな。
(青い本になんかあった気もする)
ITRONというと、TOPPERSなんかは、もう当然こんなもの気にしてなんかいないでしょ。 機械「語」だから文章だって話だよ。
TRONCHIPの機械語がそもそもどんなものか知らないけれど。 TRONCHIPも68000も386も何でも、実行可能バイナリは実行可能バイナリであって、
文章ではない(text、という名前を歴史的に使うけども)。 そんな禁止規定はないし、機械語は機械が解する言語なのは事実。 どう意味不明な理屈をこねようと、TADとして解釈不能なバイト列にならざるを
えない機械語を、TADにおける「文章」として扱うのは不可能。 そもそも機械語以外の文を機械は「解釈」できない。
TADにおける「文章」とはTRON 仕様多国語文字コードだと思われる。
つまり機械語の「文字」を作れば可能。 TRON 仕様多国語文字コード というのは外部参照なので確定することができない。
DLLと同じ。
第1編第2章で解説されているTRON コード体系で、
言語指定コードで21以外の指定を含みうるもの、と解釈すべき、と思うが、
どこにもそう解釈できそうな文が書いてないなw
B-right/Vの仕様書のほうにちょっと書いてある。 >>35
再来年の間違いでした。
大学受験は今年になります。 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
UUAHROR5K6