N a p l o g

忙しい中あえて書くことでもないのですが(drunk エントリですし:-)、最近 YLUG-ML が面白すぎます。Web でアーカイブが見れないことも手伝っていて、こういう閉鎖空間での面白さって伝えるのが難しいですね。ある種の SNS (というか、CUG) ですね、これって。

現象としては困った(かまって)チャンと大人たちの駆け合いというかネタと釣りの応酬というか、あえて釣られて、この人もいたんだ、というような驚きがあったり、というかなんというか。面白すぎます。ちょうど日本でのインターネット黎明期を彷彿とさせています、この 2008～9 年にかけてですよ。

ただなんというか、そういう人(現象)を排斥せずに受け入れる度量があの空間にあることが面白いですね。ときどきババだったものがジョーカーに変わったりもしますし。この面白さを分かる人は、きっと彼の言う○○なんだと思います。実際、面白すぎますｗ

ドキュメントのないソースコードを読むことは地図のない旅をするようなもんだなぁ、と最近感じています。特に OSS のソースを読む場合なんかにはそう感じますし、今その旅の真っ最中って感じです。

旅は現地に行ってみればそこに何があるのかがわかるのですが、観光ガイドブックで事前に調べたりせず行く場合、非常な苦労をすることがあります。近道があるのに思いっきり遠回りをしてみたり、見どころだと思って行ってみたところが取るに足らないものだったり、名物だと思って食べたものがどこでも食べられるものだったり。

その土地の開拓をしたり発展させたり、観光地として有名になることはそこの土地の人々にとっては面白いことだとは思いますし、住みやすくもなるでしょう。しかしその土地がどういった過程を経て成り立ったのかとか慣習とか、区画整備された目的だとかその後の地図だとか、そういった史記や風土記、地図といった類のものがないと他所の土地から来た人は非常に苦労をしてしまいます。

ソースコードが地図だ、といってしまえばそれはそれで楽でしょうが、ソースコードは住所なんですよね。1 次元の情報です。これを 2 次元化した地図がやはり最低限欲しいです。この辺、なんとかできない/ならないもんですかねぇ。

ここ数日使ってみましたが、これはどうもメモリ大喰らいソフトのようです。通常 Firefox, Thunderbird, Poderosa が起動しており、これらだけで 200MB 近くのメモリを消費します。なんというか別の意味でファットクライアントって感じがします。

多分にメモリリークも存在するんでしょうが、Firefox や Thunderbird 自体はそういう設計なので仕方ないにしても、ターミナルエミュレータでどうやってあんなにメモリを消費できるんだろうと思ってしまいます。これも .Net Framework のなせる業なんでしょうね。

Linux を使うときは Cygwin のターミナルから ssh を使っていたのですが、あまりターミナルを開きすぎるとデスクトップが煩雑になってしまうためタブ式のターミナルエミュレータがないかと探したときに見つけたソフトがこれです。

• index - Terminal Emulator Poderosa
  http://ja.poderosa.org/

Poderosa はポデローサと読むようです。いったいどういった意味があるんでしょう？ 半日使っていましたが名前が覚えられませんでした(というか、トップページにカタカナがふってあるのに今気がつきました。これで間違わずに覚えられそうです)。

半日使った感じでは問題が発生するわるわけでもなく快適に動作していました。これで Cygwin は X のみの利用にとどめられそうです。そうそう、この Poderosa は Cygwin への接続もでき、私の用途にとっては至れり尽せりです。

さて、patch をあて終わった後にはカーネルの make になりますが、patch によって何が変わったかを確認することにしましょう。

比べやすいように make xconfig の画像をそのままのせておきます。

Fig.1 8250.patch

Fig.2 eth.patch

ここで重要なのはどちらも core 及び i386 の patch 適用後であるということです。これらがあたっていない場合、Kernel hacking の Option はあらわれません。make xconfig は patch が正しくあたっているかの確認にもなるでしょう(それ以前に patch のログを見ればわかると思います)。

ethernet はわかりませんので serial port に関して補足をしておくと、この図では serial port の設定が以下の様になっているのがわかると思います。

(1) Serial port number for KGDB (NEW)

これはシリアルポートの番号です。ここでは、いわゆる /dev/ttyS1 が指定されていることになります。これはマザーボードの仕様にもよると思いますが、シリアルポートが 1 つしかない環境の場合にはこれを 0 に指定する必要があります。

また同様に baud rate の設定も必要ですが、これはデフォルトの 115200 で問題はないでしょう。

kernel の make 方法に関してはここでは特に注釈はしませんが、これは以下の記事が大変参考になると思います。

• Linux Kernel 2.6を組み込み機器で使う : 何が新しくなったのか，何が追加されたのか
  http://www.cqpub.co.jp/interface/sample/200507/if0507_chap1.pdf

では前回の続きからですので kgdb patch に含まれている README ファイルに関してです。これには大きく分けて 3 種類の説明が書かれています。それは、

• Patch
• Build
• Module Debugging

patch を行うために quilt というツールを使えばいいという説明がありますが、私は使いませんでしたのでここでは無視します。

さて、私の対象とする環境は普通の x86 ですので以下の patch をあてました。

• core-lite.patch
• i386-lite.patch
• core.patch
• i386.patch
• 8250.patch
• module.patch

これらの patch で -lite が付いているものは基本 patch のようなので関連するものに関してはそれらを先にあてます。patch のあてかた自体は kgdbquickstart-2.4.pdf が参考になります。

• kgdbquickstart-2.4.pdf
  http://kgdb.linsyssoft.com/downloads/kgdb-2/kgdbquickstart-2.4.pdf

曰く、

$ patch -p1 < ${BASE_DIR}/linux-2.6.15.5-kgdb-2.4/core-lite.patch

ここで、カレントディレクトリは kernel のソースを展開したディレクトリです。例えば /usr/src/kernels/linux-2.6.15.5 などです。ここは自分の環境に読み替えてください。引用されている ${BASE_DIR} がそれですね(補足2006.05.15 : この ${BASE_DIR} は /usr/src/kernels/ になります。${BASE_DIR} がそれ、は間違いですね)。

patch に関して簡単に補足しておくと、8250.patch はシリアルポートを用いてリモートデバッグをする場合の patch です。WinDbg ではシリアルポートの接続でデバッグを行っていたのでこれを使うことにしました。シリアルポート以外にはイーサネット接続でデバッグができるようで、その場合には eth.patch をあてます。私はこれでデバッグを行ったことが無いので説明はできません。

module.patch に関しては autoloaded module のデバッグに関して有用である、といったことが書かれていたのであてることにしました。実際にどういった効果があったかは調べていませんが、とりあえずあててあります。実際のデバッグではモジュールの autoload をしなかったため、どうでもよかったのかもしれません。

kernel 空間のデバッグをすることができるようになったのでその方法に関してまとめておこうと思います。デバッグの方法は kgdb を使うので PC は 2 台必要です(最近は VMware などを使って 1 台で開発をすることもあるようですが、とりあえず 2 台で)。Windows でドライバ開発に WinDbg などを使っていたくらいの知識があると読みやすいと思います(というか、Windows のドライバを作っていたが不幸(?)にして Linux のドライバの面倒もみないとならなくなった人向け、といった方がいいかもしれません)。

使用した kernel は 2.6.15.5 です。これは kgdb のパッチとして 2.6.15.5 用を使ったことによりますが、多分これ以外のバージョンでも基本は同じだと思います。

まず、対象となるカーネルソースとパッチをダウンロードします。

• The Linux Kernel Archives
  http://www.kernel.org/
• KGDB: Linux Kernel Source Level Debugger
  http://kgdb.linsyssoft.com/getting.htm

ここで重要なのが kgdb patch に含まれている README ファイルです。ここに patch のあて方から remote gdb による接続の方法までがひととおり書かれています。日本語のサイトでこれに関して説明しているところは皆無だと思いますが(探した限りみつかりませんでした)、kernel debugging を行うような人は日本語資料などいらないし英語のドキュメント/コミュニティで十分なのかな、と思ってしまいました。

ユーザ空間のデバッグが一段落し、次にカーネル空間のデバッグをしなければならなくなっています。カーネル空間のデバッグにはいろいろとツールがあるようですが C のソースレベルでデバッグが可能なのは探した限りやはり kgdb が一般的のようです。

しかしこの kgdb の導入/運用に関する日本語の具体的で有用な情報ってほとんどないんですよね。IBM のサイトに

• Linuxのデバッグ手法をマスターする
  http://www-06.ibm.com/jp/developerworks/linux/021018/j_l-debug.html

また、日本のメーリングリストを検索してみても kgdb に関しては放置されるのが現状のようです。

• [linux-users:105821] ローダブルモジュールのデバッグについて
  http://search.luky.org/linux-users.a/msg05775.html

いくら OSS といってソースがあるといっても、それを運用する方法がわからないんであれば意味がありません。質問しても放置されるようじゃ誰も質問なんてしないですよね…。

結局英語圏の情報を見るのが手っ取り早そうです。

• Linuxのドライバソフトをめぐって論争再燃--UI強化が引き金に - CNET Japan
  http://japan.cnet.com/special/story/0,2000056049,20101831,00.htm

グラフィックドライバに関する問題です。GPL 至上主義な人たちにとっては問題なのでしょう。利用者にとってみればどっちでもいいことで、この GPL 至上主義者と利用者の意識の差が今日の PC-UNIX の一般的な普及を阻む根本的な問題の一つとなっていると思います。

以前、DoGA の上映会でかまたゆたかさんがこんなことを言っていました。「投稿作品の傾向を見ていると、初期の投稿作品は理系の人のみであり、それは 『パソコンが使える人 == 理系の人』 の時代のものでした。それがだんだんと文型の人が作品を作るようになり、単に 3DCG だったものが物語性を帯びてくるようになりました。そして最近では芸術系の作品まで応募されるようになり、CG アニメーションというものの裾野がこんなに広がったんだと実感しています。」 私が思うに、未だに PC-UNIX の世界は理系の世界です。

GPL の理想を考えると、それはそれでもう仕方の無いものなのかもしれません。ソースコードの改変は自由。誰でも求めればソースコードが得られる。これって理系の人、というかソフトウェアプログラマの理想なんですよね。決して文系の人や芸術系の人が求めている内容ではありません。こういった人たちはソースコードを自由に読めたり改変したりすることよりも、出来上がったソフトウェアによって何かをつくりあげる、そのためにソフトウェアを使う、ということを欲している人たちです。別に GPL によって作り上げられたソフトウェアを使いたいわけではなく、道具は道具として使いたいだけなのです。

最近よく思うことは「Linux などの PC-UNIX の大半って、結局は同人ソフトなんだよね」ということです。同人ソフトに対する一般の人の接し方を思うと、これはこれで当然の結果だとも思ってしまいます。

• スラッシュドット ジャパン | DistroWatch.comが見た、日本のLinux事情
  http://slashdot.jp/linux/06/04/18/0326212.shtml

コメントをつらつらと読んでみていますが、これが今の Linux を取り巻く普通の感想なんだろうな、と思いますし、きっと今後 10 年経っても変わっていないだろうとも思います。大体の言及はコメントの中にあるのでここではネガティブなことは書かないでおきますが、やはり Windows と Linux は完全に層として分かれていると思います。UNIX として一般受けが期待が出来るとしたらやはり Mac になるんでしょうかね。

最近はデバッガとして insight を使うようになったのですが、デバッグ中に insight 自身が segmentation fault で落ちることが多々あります。なんてゆーか、ありえないんですよね、こうゆうことって。こういった点ひとつをとっても大分 Windows の後塵を拝しているな、と感じざるを得ませんし、まぁこれは Linux の問題ではなくて Linux を取り巻く環境の問題なんですけれども。

とりあえず備忘録的に。

Linux は shell から上を使う分には変化はそうない感じですが、kernel 界隈は version 毎に互換性がなかったり関数が減ったり増えたりと、とても変化が激しいようです。また web 上の資料も version 2.0, 2.2, 2.4, 2.6 とそれぞれの情報が混在混線しており、とてもまとまっているとは言えません。こういったことを書くと OSS 原理主義世界の人たちからは「それならあなたの力で・・・」的な、利用するという目的とはかけ離れた本末転倒な方向に話が進みそうなので、こういった話もあまり出ないのかなぁ、という気がしています。

なんとなくですが、Linux などの UNIX 世界では、いろんなことを知っていて当たり前、的な気分がとても濃いように感じます。思想的には CUI と GUI のような感じですね。CUI などのターミナル環境が前提な場合、プログラムやコマンド名などを知らなければ使うことが出来ません。これには最近、グローバル変数文化だな、という感想を持っています。自分の知らないところで突然グローバル変数を宣言されている感じですね。知らなくて当たり前だが存在している、というものです。逆に GUI は見えるものが操作できるものですから、とてもオブジェクト的な世界に見えます。

さて、ドライバ関連で資料を探しているときに、以下のドキュメントを見つけました。

• Linux カーネルハッカーのための Windows I/O システム概説
  http://lkh.linux.or.jp/ppt/windows_io_for_linux_hacker.pdf

私は Linux よりは Windows のドライバの方が詳しいのですが、最終ページの○×表を見ると、このドキュメントが書かれてから 5 年たっても世界って変わらないもんだなぁ、と思います。慣れの問題もあるのでしょうが Windbg と kgdb の導入を考えた場合、その労力の差にはため息しか出ません。はぁ…。

突然(でもないんですが) Linux を触らなければならない事情になってしまい、数年ぶりに Linux のインストールと、ついでに Cygwin 環境も整えてみました。

最近は Linux に関して、ウェブ進化論 を読んで以降「Google と Linux のディストリビュータって同じ種類の仕事だな」と思うようになりました。

Google は web 世界の玉石混淆問題に対して、ページ抽出と整理を行っている立場といえますが、Linux ディストリビュータも同様に Linux で使用可能なソフトウェアの抽出と整理を行っているといえます。世の中に多数存在する独立したソフトウェアをまとめて有用なパッケージにすることは原理的には個人でも可能ですが、とてもコスト(リソース)がかかります。目的が Linux を使うことである以上、こういったパッケージがまとめられているに越したことはありません。ディストリビューションが存在しなかった場合の Linux の導入に関して考えると、かなりぞっとします。といっても、初期はやはりそうでしたし SLS や Slackware など、 はしりのディストリビュータ、ディストリビューションという考え方には感心させられます。

しかし、このディストリビューション乱立の世界はなんとかして欲しいものです。外食で例えると Windows は日本的オーダーで注文が可能なフランチャイズチェーン店のような感じですが、Linux は欧米式オーダーをしなければならない個人経営店のような感じです。Windows ではもうメニューが決まっていて「これを下さい」である程度まとまったものを食べることが出来ます。しかし Linux においては料理方法を細かく注文しなければならなかったり、自分で旬の素材を知っていなければならなかったり、客であるのに自分で料理をしたり、はては原料の供給をしたり・・・と、目的を達成するための副次的行為がとても多くなります。この辺はひとまわり経ってもあまり変わってないですねぇ。

今回やらなければならないのはドライバの開発なのですが、デバッグ方法に関して資料を探すだけで骨が折れます。ちょっと情報を見つけても「printk() で・・・」とかって、目を疑うくらい進化していなような情報もあります。…早く最近の情報を見つけなければ。