パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

平成14年度「未踏ソフトウェア」採択一覧」記事へのコメント

  • by Anonymous Coward on 2002年11月03日 14時58分 (#194450)
    http://www.ipa.go.jp/NBP/14nendo/14mito/gaiyou/2-9.html
    次世代GRUBとやらの概要を見てみたんだが、

    >メモリ管理のような基本的な機能も持っておらず、また、その実装はIA32に特化してしまっており、汎用性も考慮されていない。
    メモリ管理はOSの役目だし、ブートローダはCPUやアーキテクチャに依存するのは仕方ないし、
    そもそも286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるわけで
    ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できないのですが…

    しかも
    >ブートローダはサイズの制限が厳しいため、最低限度の機能を持ったコンパクトなコアイメージ
    と言いつつ、直後に
    >スクリプト言語、国際化、他アーキテクチャへの移植を見定め、IA32に依存したコードと汎用的な部品の明確な切り分け、
    >UTF-8のような非ASCII文字コードへの対応、多様なスクリプトを扱うためのフォントマネージャなどの開発も並行して実施する。
    とか言ってる…

    ブートローダに本当にスクリプト機能がいるのか?
    スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか?
    UNICODEってどれだけの格納文字数あるか知ってるのか?
    何より、「多様なスクリプトを扱うためのフォントマネージャ」って何だよ?

    こんなにもツッコミどころ満載で800万円も予算取る気か。
    税金の無駄遣いはやめて欲しいな。

    #一応OS関連の人間なのでAC
    • by nobuhiro (5244) on 2002年11月03日 15時53分 (#194476) ホームページ
      煽りなんでしょうけど、マジレスで。;-)

      プロジェクトの金額 800万ってのは最低限の金額でしょう。一人の開発者がフルタイムで一年でこなせるプロジェクトと考えると、年収+経費でとんとんの額です。開発機材をそろえるとなると、キリギリのラインでこの種の開発がこなせるスキルの技術者とを考えると薄給の部類と言えます。

      また、内容的にも、それまでの開発を踏まえた上での目標で、十分説得力があると思います。コンパクトなコアイメージが、追加機能読み込めばいいのだから、高機能とコンパクトさは別に矛盾しないですし。

      スクリプト言語にしても、カーネルの他ドライバモジュールを読み込みむ作業など高機能のブートローダの場合必要になってきます。実際、最近の FreeBSD のローダはスクリプト機能を持っています。(たぶん Solaris/x86 も持ってる)

      あと「多様なスクリプトを扱うためのフォントマネージャ」のスクリプトは、文脈を見るとスクリプト言語ではなくて『文字体系』の意味ですな。

      --
      親コメント
      • by saitoh (10803) on 2002年11月03日 18時28分 (#194532)
        Open Firmware (IEEE 1275)なんつー規格がありますが、 これは FORCE言語のインタプリタをROMモニタに乗せるもの。 実装例では SunのOpenBootがあります。
        IBM-PCアーキテクチャみたいにロムモニタが存在しないような 場合は、ブートローダが代わりに高機能化しても かまわないとおもうがなぁ。
        親コメント
    • by yaegashi (24) on 2002年11月03日 18時19分 (#194524) ホームページ

      ブートローダを作る必要もない恵まれた環境でカーネルをいじってる方からみると、この案件に対してはそのような感想しか持たれないのかもしれません。

      ブートローダの実装が本質的にアーキテクチャやプラットフォームに依存することは確かですが、それでもブートローダに必要とされる機能で、共用可能なコードはたくさんあります。

      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 円どころでなくもっとお金をかけて、ブートローダの決定版といえるものをリリースできれば、幸せになれる技術者はたくさんいると思いますよ。

      親コメント
      • 元のACです
        >eCos/RedBoot [redhat.com] という
        (中略失礼)
        >これまでの grub について見ると実装が x86 に依存しすぎており、そう簡単にはいかなかったわけです。
        それならeCos/RedBootでいいのでは?

        そもそも、環境の豪華さの全然違うPCと組み込み機器で同じブートローダなりOSなりを
        使おうということ自体に無理があると思うのですが…
        • eCos/RedBootは、外部からロードしたプログラムを起動する場合、
          単純にジャンプする機能しかないので、OSの起動用に使う場合は不便です。
          使えないことはありませんが、十分と言えるレベルでは無いと思います。
          親コメント
        • by yaegashi (24) on 2002年11月03日 22時34分 (#194610) ホームページ
          それなら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 は追加機能を動的に読みこめるようにするそうですから、大きくも小さくもスケールできるものになるんじゃないでしょうか。

          親コメント
        • > そもそも、環境の豪華さの全然違うPCと組み込み機器で同じブートローダなり
          > OSなりを使おうということ自体に無理があると思うのですが…

          実際に組み込み系で動作している UNIX 系 OS があるけど、
          それについて何か言うことはありますか?

          # ただ単にいちゃもんつけてるだけやん。
          • 別のACですが、
            組み込みOSとしてのUNIX系OS、例えばLinuxなんか
            CPUやチップに合わせてちまちま移植している状況なんで
            ブートローダーなんてどうでもいいっす。
            っていうか、OSの移植のほうがよほど手間。ブートローダーは明後日おいでって感じ。
            • by yaegashi (24) on 2002年11月04日 1時38分 (#194685) ホームページ

              そうでしょうか? ターゲットにカーネルのイメージを転送するのに最初から ICE や JTAG などが使えるか、または優れたモニタないしブートローダが始めから存在するような恵まれた開発環境をお使いの方はそのような感想を持たれるかもしれませんが、そんなものが存在しない場合、カーネル開発を始める前に何らかのブートローダを自作する必要があるかと思います。

              移植の初期段階においては、ホストでソースを編集してコンパイルしてターゲットに vmlinux をダウンロードして実行、という一連の流れの RTT を縮めるのが最も重要なので、単純なモニタプログラムを自作して間に合わせるよりは、多少時間をかけて eCos/RedBoot のようなブートローダをきちんと移植したほうが、結局は開発期間の短縮につながるようです。

              一回のダウンロードにシリアルを使って数分待たされるのと、TFTP で十数秒で終わるのでは、やはり開発効率には雲泥の違いがあります。

              親コメント
          • 元のACです。

            >実際に組み込み系で動作している UNIX 系 OS があるけど、
            >それについて何か言うことはありますか?

            組み込みに*BSDやlinuxなどのunix系OSがあるのは百も承知。
            ただ、それが適切であるかどうかというところに疑問があるだけです。

            というのも、別スレッドのOpenBSDの話ですが、今まではstack segmentに実行権限を与えていたようです。
            また、手元のcygwinにて実験しましたが、こちらもstack segmentに実行権限がありました。

            signal trampolineなどの実装の問題で必要となる措置かもしれませんが、どちらかというと
            組み込
            • by Anonymous Coward on 2002年11月04日 1時24分 (#194681)
              最初は

                こんなにもツッコミどころ満載で800万円も予算取る気か。
                税金の無駄遣いはやめて欲しいな。

              と言っていたのに、ずいぶんニュアンスが変わってきましたね。

              結局のところ、

                okuji 氏: 「ブートローダは~という形であることが望ましい」
                あなた: 「それが適切であるかどうかというところに疑問がある」

              という考え方の違いだけではないのですか?

              仮にあなたの考えが正しいとしても、800万でそれが証明されれば
              安いものでは? もし 800万で素晴らしいモノができたら、それはそれで
              いいじゃないですか。
              親コメント
              • >okuji 氏: 「ブートローダは~という形であることが望ましい」
                >あなた: 「それが適切であるかどうかというところに疑問がある」
                >という考え方の違いだけではないのですか?

                違います。

                >>>>ただ、それが適切であるかどうかというところに疑問があるだけです。

                >>>実際に組み込み系で動作している UNIX 系 OS があるけど、
                >>>それについて何か言うことはありますか?
                に対する解答ですので、この点はあくまでもツッコミの一つにすぎません。

                機能の有無に対する個人的
              • 釈然としないなら、もっと調べるか、作者と直接意見を交わせば良いのでは?

              • by Anonymous Coward on 2002年11月04日 14時04分 (#194906)
                「未踏ソフトウェア」なんじゃない?
                問題点があるなら指摘してやれよ.こんなところでクダまいてないで.
                # ……実際は "そもそもどこが問題なのかも解らない" ものの方が
                # 「未踏ソフトウェア」にふさわしいけどね
                野分
                親コメント
              • by Anonymous Coward on 2002年11月04日 15時29分 (#194927)
                最初に言ったように、
                ・286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるため、ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できない
                ・スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか?
                などの問題について釈然としません。
                本気で疑問に思うなら、開発者本人に意見してはどうでしょう?
                連絡先も、名前まで分かっているのですから、
                探せば簡単にみつかりますし。
                親コメント
              • by yaegashi (24) on 2002年11月04日 19時57分 (#195010) ホームページ
                ・286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるため、ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できない

                現行の grub ですでに 32bit プロテクトモードのコードが stage2 で使われていますし、それは 286 の 16bit のプロテクトモードでは動きません。だいたい、これから新規開発するブートローダでわざわざ 286 をサポートする意義は薄いのでは?

                また有名なことですが 286 でも CPU のみをハードウェアリセットすればプロテクトモードからリアルモードに戻ることができますし、そのためのサポートが PC の BIOS にはあります。なので、DOS 起動もがんばればできるのではないかと。

                ・スクリプト機能、ましてや国際化(で用いるであろう文字コードの処理)は暗黙のセキュリティホールの原因にならないか?

                こちらに関しては専門外なのでコメントは控えます。

                ちなみに次世代 grub というのは PUPA [nongnu.org] のことですね。公開されている PDF [nongnu.org] に、この事業でやろうとしていることについてさらに詳しく書かれています。

                親コメント
              • >・286みたいに一度プロテクトモードになるとリアルモードに帰って来れない石もあるため、ブートローダがプロテクトモードで動くと、リアルモードのOS(DOSなど)は起動できない

                そもそもあれは「欠陥CPU」だろ?
                プロテクトモードにしたところで、パワー不足とセグメントの璧で
                ほとんど使い物にならなかったってのに。
                あんなのへの対応を、わざわざ今からやりたい奴の気が知れないね。
                そもそも組み込み向けでも286CPUなんてもう製造しとらんだろ。

                x86の場合、80186あたりの互換か、その上は最低でも386、
                普通はElanみたいに486クラス以上を載せていると思うぞ。
                親コメント

アレゲは一日にしてならず -- アレゲ見習い

処理中...