2009年04月16日
ML
忙しい中あえて書くことでもないのですが(drunk エントリですし:-)、最近 YLUG-ML が面白すぎます。Web でアーカイブが見れないことも手伝っていて、こういう閉鎖空間での面白さって伝えるのが難しいですね。ある種の SNS (というか、CUG) ですね、これって。
現象としては困った(かまって)チャンと大人たちの駆け合いというかネタと釣りの応酬というか、あえて釣られて、この人もいたんだ、というような驚きがあったり、というかなんというか。面白すぎます。ちょうど日本でのインターネット黎明期を彷彿とさせています、この 2008~9 年にかけてですよ。
ただなんというか、そういう人(現象)を排斥せずに受け入れる度量があの空間にあることが面白いですね。ときどきババだったものがジョーカーに変わったりもしますし。この面白さを分かる人は、きっと彼の言う○○なんだと思います。実際、面白すぎますw
2006年06月08日
地図のない旅
ドキュメントのないソースコードを読むことは地図のない旅をするようなもんだなぁ、と最近感じています。特に OSS のソースを読む場合なんかにはそう感じますし、今その旅の真っ最中って感じです。
旅は現地に行ってみればそこに何があるのかがわかるのですが、観光ガイドブックで事前に調べたりせず行く場合、非常な苦労をすることがあります。近道があるのに思いっきり遠回りをしてみたり、見どころだと思って行ってみたところが取るに足らないものだったり、名物だと思って食べたものがどこでも食べられるものだったり。
その土地の開拓をしたり発展させたり、観光地として有名になることはそこの土地の人々にとっては面白いことだとは思いますし、住みやすくもなるでしょう。しかしその土地がどういった過程を経て成り立ったのかとか慣習とか、区画整備された目的だとかその後の地図だとか、そういった史記や風土記、地図といった類のものがないと他所の土地から来た人は非常に苦労をしてしまいます。
ソースコードが地図だ、といってしまえばそれはそれで楽でしょうが、ソースコードは住所なんですよね。1 次元の情報です。これを 2 次元化した地図がやはり最低限欲しいです。この辺、なんとかできない/ならないもんですかねぇ。
2006年06月06日
Poderosa(2)
ここ数日使ってみましたが、これはどうもメモリ大喰らいソフトのようです。通常 Firefox, Thunderbird, Poderosa が起動しており、これらだけで 200MB 近くのメモリを消費します。なんというか別の意味でファットクライアントって感じがします。
多分にメモリリークも存在するんでしょうが、Firefox や Thunderbird 自体はそういう設計なので仕方ないにしても、ターミナルエミュレータでどうやってあんなにメモリを消費できるんだろうと思ってしまいます。これも .Net Framework のなせる業なんでしょうね。
2006年05月31日
Poderosa
Linux を使うときは Cygwin のターミナルから ssh を使っていたのですが、あまりターミナルを開きすぎるとデスクトップが煩雑になってしまうためタブ式のターミナルエミュレータがないかと探したときに見つけたソフトがこれです。
- index - Terminal Emulator Poderosa
http://ja.poderosa.org/
Poderosa はポデローサと読むようです。いったいどういった意味があるんでしょう? 半日使っていましたが名前が覚えられませんでした(というか、トップページにカタカナがふってあるのに今気がつきました。これで間違わずに覚えられそうです)。
半日使った感じでは問題が発生するわるわけでもなく快適に動作していました。これで Cygwin は X のみの利用にとどめられそうです。そうそう、この Poderosa は Cygwin への接続もでき、私の用途にとっては至れり尽せりです。
2006年05月16日
kernel debugging(4)
さて、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
2006年05月12日
kernel debugging(3)
では前回の続きからですので 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 をしなかったため、どうでもよかったのかもしれません。
2006年05月01日
kernel debugging(2)
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 を行うような人は日本語資料などいらないし英語のドキュメント/コミュニティで十分なのかな、と思ってしまいました。
2006年04月28日
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 といってソースがあるといっても、それを運用する方法がわからないんであれば意味がありません。質問しても放置されるようじゃ誰も質問なんてしないですよね…。
結局英語圏の情報を見るのが手っ取り早そうです。