アカウント名:
パスワード:
プロジェクトの金額 800万ってのは最低限の金額でしょう。一人の開発者がフルタイムで一年でこなせるプロジェクトと考えると、年収+経費でとんとんの額です。開発機材をそろえるとなると、キリギリのラインでこの種の開発がこなせるスキルの技術者とを考えると薄給の部類と言えます。
また、内容的にも、それまでの開発を踏まえた上での目標で、十分説得力があると思います。コンパクトなコアイメージが、追加機能読み込めばいいのだから、高機能とコンパクトさは別に矛盾しないですし。
スクリプト言語にしても、カーネルの他ドライバモジュールを読み込みむ作業など高機能のブートローダの場合必要になってきます。実際、最近の FreeBSD のローダはスクリプト機能を持っています。(たぶん Solaris/x86 も持ってる)
あと「多様なスクリプトを扱うためのフォントマネージャ」のスクリプトは、文脈を見るとスクリプト言語ではなくて『文字体系』の意味ですな。
ブートローダを作る必要もない恵まれた環境でカーネルをいじってる方からみると、この案件に対してはそのような感想しか持たれないのかもしれません。
ブートローダの実装が本質的にアーキテクチャやプラットフォームに依存することは確かですが、それでもブートローダに必要とされる機能で、共用可能なコードはたくさんあります。
eCos/RedBoot [redhat.com] というブートローダはx86/arm/mips/ppc/sh といった多種多様のアーキテクチャ・プラットフォームに対応していますが、これはプラットフォーム HAL と Ethernet や IDE HDD といったドライバさえ書ければ、TCP/IP が使えたり、ext2 や ISO9660 や FAT や TFTP サーバから ELF のイメージを読みこめたり、gdb stub によるカーネルデバッグができたり、といった有用な機能が、共通のユーザインタフェースで使えるような構造になっています。
最も重要な点は、これだけの機能を持つブートローダが少ない労力で新しいプラットフォームに移植可能という点なのですが、これまでの grub について見ると実装が x86 に依存しすぎており、そう簡単にはいかなかったわけです。
新しい基板が次から次へとやってくる組み込みのフィールドでカーネルをハックする者としては、この次世代 grub のような汎用高機能なブートローダの出現は切望されるものです。8M 円どころでなくもっとお金をかけて、ブートローダの決定版といえるものをリリースできれば、幸せになれる技術者はたくさんいると思いますよ。
それならeCos/RedBootでいいのでは?
もちろん比較してみれば eCos/RedBoot にも grub には及ばないところが数多くあるわけで、たとえば RedBoot コンソールにはろくなコマンドライン編集機能がありませんし、サポートするファイルシステムの種類でも grub にはかないません。もうすこし一般的なユーザに対する利便性を考慮する必要があるでしょう。
また RedBoot は eCosという手頃な抽象層を利用して構築された、かなり ad-hoc なアプリケーションに見えます。RedBoot からは eCos カーネルの機能はほとんど使われていません。ハードウェア割り込みも禁止され、TCP/IP に必要なタイミングなどもポーリングで計ります。
同じソースコードをコンパイルできるだけの環境を提供するだけなら別に eCos でなくてもよいのではと思うわけで、次世代 grub では eCos/RedBoot とはまた違った、優れた汎用ブートローダのフレームワークを提供してくれるものと期待しています。
そもそも、環境の豪華さの全然違うPCと組み込み機器で同じブートローダなりOSなりを 使おうということ自体に無理があると思うのですが…
もちろん適材適所がいちばん重要ですが、近年の組み込みデバイスは PC の Linux や *BSD といった OS がそのまま動くだけの性能はあります。ブートローダも OS も共通の環境が構築でき、これまで蓄積されたソフトウェア資産が流用できるのは、組み込みに UNIX を用いることの大きな利点です。
次世代 grub は追加機能を動的に読みこめるようにするそうですから、大きくも小さくもスケールできるものになるんじゃないでしょうか。
そうでしょうか? ターゲットにカーネルのイメージを転送するのに最初から ICE や JTAG などが使えるか、または優れたモニタないしブートローダが始めから存在するような恵まれた開発環境をお使いの方はそのような感想を持たれるかもしれませんが、そんなものが存在しない場合、カーネル開発を始める前に何らかのブートローダを自作する必要があるかと思います。
移植の初期段階においては、ホストでソースを編集してコンパイルしてターゲットに vmlinux をダウンロードして実行、という一連の流れの RTT を縮めるのが最も重要なので、単純なモニタプログラムを自作して間に合わせるよりは、多少時間をかけて eCos/RedBoot のようなブートローダをきちんと移植したほうが、結局は開発期間の短縮につながるようです。
一回のダウンロードにシリアルを使って数分待たされるのと、TFTP で十数秒で終わるのでは、やはり開発効率には雲泥の違いがあります。
釈然としないなら、もっと調べるか、作者と直接意見を交わせば良いのでは?
最初に言ったように、 ・286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるため、ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できない ・スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか? などの問題について釈然としません。
・286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるため、ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できない
現行の grub ですでに 32bit プロテクトモードのコードが stage2 で使われていますし、それは 286 の 16bit のプロテクトモードでは動きません。だいたい、これから新規開発するブートローダでわざわざ 286 をサポートする意義は薄いのでは?
また有名なことですが 286 でも CPU のみをハードウェアリセットすればプロテクトモードからリアルモードに戻ることができますし、そのためのサポートが PC の BIOS にはあります。なので、DOS 起動もがんばればできるのではないかと。
・スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか?
こちらに関しては専門外なのでコメントは控えます。
ちなみに次世代 grub というのは PUPA [nongnu.org] のことですね。公開されている PDF [nongnu.org] に、この事業でやろうとしていることについてさらに詳しく書かれています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
次世代GRUBで800万(゚Д゚)? (スコア:0)
次世代GRUBとやらの概要を見てみたんだが、
>メモリ管理のような基本的な機能も持っておらず、また、その実装はIA32に特化してしまっており、汎用性も考慮されていない。
メモリ管理はOSの役目だし、ブートローダはCPUやアーキテクチャに依存するのは仕方ないし、
そもそも286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるわけで
ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できないのですが…
しかも
>ブートローダはサイズの制限が厳しいため、最低限度の機能を持ったコンパクトなコアイメージ
と言いつつ、直後に
>スクリプト言語、国際化、他アーキテクチャへの移植を見定め、IA32に依存したコードと汎用的な部品の明確な切り分け、
>UTF-8のような非ASCII文字コードへの対応、多様なスクリプトを扱うためのフォントマネージャなどの開発も並行して実施する。
とか言ってる…
ブートローダに本当にスクリプト機能がいるのか?
スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか?
UNICODEってどれだけの格納文字数あるか知ってるのか?
何より、「多様なスクリプトを扱うためのフォントマネージャ」って何だよ?
こんなにもツッコミどころ満載で800万円も予算取る気か。
税金の無駄遣いはやめて欲しいな。
#一応OS関連の人間なのでAC
Re:次世代GRUBで800万(゚Д゚)? (スコア:3, 参考になる)
プロジェクトの金額 800万ってのは最低限の金額でしょう。一人の開発者がフルタイムで一年でこなせるプロジェクトと考えると、年収+経費でとんとんの額です。開発機材をそろえるとなると、キリギリのラインでこの種の開発がこなせるスキルの技術者とを考えると薄給の部類と言えます。
また、内容的にも、それまでの開発を踏まえた上での目標で、十分説得力があると思います。コンパクトなコアイメージが、追加機能読み込めばいいのだから、高機能とコンパクトさは別に矛盾しないですし。
スクリプト言語にしても、カーネルの他ドライバモジュールを読み込みむ作業など高機能のブートローダの場合必要になってきます。実際、最近の FreeBSD のローダはスクリプト機能を持っています。(たぶん Solaris/x86 も持ってる)
あと「多様なスクリプトを扱うためのフォントマネージャ」のスクリプトは、文脈を見るとスクリプト言語ではなくて『文字体系』の意味ですな。
の
Re:次世代GRUBで800万(゚Д゚)? (スコア:3, 参考になる)
IBM-PCアーキテクチャみたいにロムモニタが存在しないような 場合は、ブートローダが代わりに高機能化しても かまわないとおもうがなぁ。
OpenFirmwareね (スコア:1)
>FORCE言語のインタプリタをROMモニタに乗せるもの。
これ、ワークステーションでは結構使われていますよ。
AppleもPowerPC登載機種からは採用しているようだし、
今は亡き? DECのAlphaマシンもそうです。
ARC(MIPS系)もじゃない?
また、OpenBIOS [linux.de]はx86にOpenFirmwareを載せるプロジェクトです。
# IBMが同じ名前で別の製品を出しているらしいので紛らわしいですが。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
Forth言語じゃなくって?
#ここはForthの暗黒面なのでAC。
Re:次世代GRUBで800万(゚Д゚)? (スコア:1)
>Forth言語じゃなくって?
確かにFORCEではなくてFORTHですね。
#時々OpenBOOTで遊んでいたのでID。
masamic
Re:次世代GRUBで800万(゚Д゚)? (スコア:3, 参考になる)
ブートローダを作る必要もない恵まれた環境でカーネルをいじってる方からみると、この案件に対してはそのような感想しか持たれないのかもしれません。
ブートローダの実装が本質的にアーキテクチャやプラットフォームに依存することは確かですが、それでもブートローダに必要とされる機能で、共用可能なコードはたくさんあります。
eCos/RedBoot [redhat.com] というブートローダはx86/arm/mips/ppc/sh といった多種多様のアーキテクチャ・プラットフォームに対応していますが、これはプラットフォーム HAL と Ethernet や IDE HDD といったドライバさえ書ければ、TCP/IP が使えたり、ext2 や ISO9660 や FAT や TFTP サーバから ELF のイメージを読みこめたり、gdb stub によるカーネルデバッグができたり、といった有用な機能が、共通のユーザインタフェースで使えるような構造になっています。
最も重要な点は、これだけの機能を持つブートローダが少ない労力で新しいプラットフォームに移植可能という点なのですが、これまでの grub について見ると実装が x86 に依存しすぎており、そう簡単にはいかなかったわけです。
新しい基板が次から次へとやってくる組み込みのフィールドでカーネルをハックする者としては、この次世代 grub のような汎用高機能なブートローダの出現は切望されるものです。8M 円どころでなくもっとお金をかけて、ブートローダの決定版といえるものをリリースできれば、幸せになれる技術者はたくさんいると思いますよ。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
>eCos/RedBoot [redhat.com] という
(中略失礼)
>これまでの grub について見ると実装が x86 に依存しすぎており、そう簡単にはいかなかったわけです。
それならeCos/RedBootでいいのでは?
そもそも、環境の豪華さの全然違うPCと組み込み機器で同じブートローダなりOSなりを
使おうということ自体に無理があると思うのですが…
Re:次世代GRUBで800万(゜Д゜)? (スコア:2, 興味深い)
単純にジャンプする機能しかないので、OSの起動用に使う場合は不便です。
使えないことはありませんが、十分と言えるレベルでは無いと思います。
Re:次世代GRUBで800万(゚Д゚)? (スコア:2, 興味深い)
もちろん比較してみれば eCos/RedBoot にも grub には及ばないところが数多くあるわけで、たとえば RedBoot コンソールにはろくなコマンドライン編集機能がありませんし、サポートするファイルシステムの種類でも grub にはかないません。もうすこし一般的なユーザに対する利便性を考慮する必要があるでしょう。
また RedBoot は eCosという手頃な抽象層を利用して構築された、かなり ad-hoc なアプリケーションに見えます。RedBoot からは eCos カーネルの機能はほとんど使われていません。ハードウェア割り込みも禁止され、TCP/IP に必要なタイミングなどもポーリングで計ります。
同じソースコードをコンパイルできるだけの環境を提供するだけなら別に eCos でなくてもよいのではと思うわけで、次世代 grub では eCos/RedBoot とはまた違った、優れた汎用ブートローダのフレームワークを提供してくれるものと期待しています。
もちろん適材適所がいちばん重要ですが、近年の組み込みデバイスは PC の Linux や *BSD といった OS がそのまま動くだけの性能はあります。ブートローダも OS も共通の環境が構築でき、これまで蓄積されたソフトウェア資産が流用できるのは、組み込みに UNIX を用いることの大きな利点です。
次世代 grub は追加機能を動的に読みこめるようにするそうですから、大きくも小さくもスケールできるものになるんじゃないでしょうか。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
> OSなりを使おうということ自体に無理があると思うのですが…
実際に組み込み系で動作している UNIX 系 OS があるけど、
それについて何か言うことはありますか?
# ただ単にいちゃもんつけてるだけやん。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
組み込みOSとしてのUNIX系OS、例えばLinuxなんか
CPUやチップに合わせてちまちま移植している状況なんで
ブートローダーなんてどうでもいいっす。
っていうか、OSの移植のほうがよほど手間。ブートローダーは明後日おいでって感じ。
Re:次世代GRUBで800万(゚Д゚)? (スコア:2, 参考になる)
そうでしょうか? ターゲットにカーネルのイメージを転送するのに最初から ICE や JTAG などが使えるか、または優れたモニタないしブートローダが始めから存在するような恵まれた開発環境をお使いの方はそのような感想を持たれるかもしれませんが、そんなものが存在しない場合、カーネル開発を始める前に何らかのブートローダを自作する必要があるかと思います。
移植の初期段階においては、ホストでソースを編集してコンパイルしてターゲットに vmlinux をダウンロードして実行、という一連の流れの RTT を縮めるのが最も重要なので、単純なモニタプログラムを自作して間に合わせるよりは、多少時間をかけて eCos/RedBoot のようなブートローダをきちんと移植したほうが、結局は開発期間の短縮につながるようです。
一回のダウンロードにシリアルを使って数分待たされるのと、TFTP で十数秒で終わるのでは、やはり開発効率には雲泥の違いがあります。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
>実際に組み込み系で動作している UNIX 系 OS があるけど、
>それについて何か言うことはありますか?
組み込みに*BSDやlinuxなどのunix系OSがあるのは百も承知。
ただ、それが適切であるかどうかというところに疑問があるだけです。
というのも、別スレッドのOpenBSDの話ですが、今まではstack segmentに実行権限を与えていたようです。
また、手元のcygwinにて実験しましたが、こちらもstack segmentに実行権限がありました。
signal trampolineなどの実装の問題で必要となる措置かもしれませんが、どちらかというと
組み込
Re:次世代GRUBで800万(゚Д゚)? (スコア:1, すばらしい洞察)
こんなにもツッコミどころ満載で800万円も予算取る気か。
税金の無駄遣いはやめて欲しいな。
と言っていたのに、ずいぶんニュアンスが変わってきましたね。
結局のところ、
okuji 氏: 「ブートローダは~という形であることが望ましい」
あなた: 「それが適切であるかどうかというところに疑問がある」
という考え方の違いだけではないのですか?
仮にあなたの考えが正しいとしても、800万でそれが証明されれば
安いものでは? もし 800万で素晴らしいモノができたら、それはそれで
いいじゃないですか。
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
>あなた: 「それが適切であるかどうかというところに疑問がある」
>という考え方の違いだけではないのですか?
違います。
>>>>ただ、それが適切であるかどうかというところに疑問があるだけです。
は
>>>実際に組み込み系で動作している UNIX 系 OS があるけど、
>>>それについて何か言うことはありますか?
に対する解答ですので、この点はあくまでもツッコミの一つにすぎません。
機能の有無に対する個人的
Re:次世代GRUBで800万(゚Д゚)? (スコア:0)
釈然としないなら、もっと調べるか、作者と直接意見を交わせば良いのでは?
問題の解法が解らないからこそ (スコア:1, すばらしい洞察)
問題点があるなら指摘してやれよ.こんなところでクダまいてないで.
# ……実際は "そもそもどこが問題なのかも解らない" ものの方が
# 「未踏ソフトウェア」にふさわしいけどね
野分
Re:次世代GRUBで800万(゚Д゚)? (スコア:1, すばらしい洞察)
連絡先も、名前まで分かっているのですから、
探せば簡単にみつかりますし。
Re:次世代GRUBで800万(゚Д゚)? (スコア:2, 参考になる)
現行の grub ですでに 32bit プロテクトモードのコードが stage2 で使われていますし、それは 286 の 16bit のプロテクトモードでは動きません。だいたい、これから新規開発するブートローダでわざわざ 286 をサポートする意義は薄いのでは?
また有名なことですが 286 でも CPU のみをハードウェアリセットすればプロテクトモードからリアルモードに戻ることができますし、そのためのサポートが PC の BIOS にはあります。なので、DOS 起動もがんばればできるのではないかと。
こちらに関しては専門外なのでコメントは控えます。
ちなみに次世代 grub というのは PUPA [nongnu.org] のことですね。公開されている PDF [nongnu.org] に、この事業でやろうとしていることについてさらに詳しく書かれています。
Re:次世代GRUBで800万(゚Д゚)? (スコア:1)
そもそもあれは「欠陥CPU」だろ?
プロテクトモードにしたところで、パワー不足とセグメントの璧で
ほとんど使い物にならなかったってのに。
あんなのへの対応を、わざわざ今からやりたい奴の気が知れないね。
そもそも組み込み向けでも286CPUなんてもう製造しとらんだろ。
x86の場合、80186あたりの互換か、その上は最低でも386、
普通はElanみたいに486クラス以上を載せていると思うぞ。