つれづれ日記

2006年3月26日 (日曜日)

07:57:39 # Life lifereaでhttpsを利用できないことについて調べてみた．ソースをみたら，src/net/netio.cにて，がんばってHTTPプロトコルをしゃべっていた．これではHTTPSをサポートするのは難しいだろう． configure.acを見ると，自前のライブラリではなくlibcurlを使えるようできるように見えたが，よく見るとdnlではじまる行なのでコメントアウトしてあった．うーむ．どうしてなのだろう．

2006年3月25日 (土曜日)

14:23:42 # Life symbollic link 解決の制限．実はLinux Kernelには，シンボリックリンクをたどる回数に制限がかかっている．ファイルをopenしようとした場合にカーネル空間でシンボリックリンクの先を解決することになる．その際に5段階までしかsymbollic linkをたどってくれない．これは，DoSなどを防ぐための制限のようだが，ちょっとださい気もする．ユーザ空間側からstatして解決してあげればなんとか回避できるような気もする． glibc側でopenするたびにstatをしてシンボリックリンクの解決をするだとか，アプリケーション側で毎回canonicalize_file_nameをよんでからopen するだとか回避策は考えられるのだけど，現実味がちょっとたりない．意外と低いこの制限，はまりませんかね？

$ ls -l 
total 4
-rw-r--r-- 1 dancer dancer 5 Mar 25 15:49 a
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 b -> a
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 c -> b
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 d -> c
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 e -> d
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 f -> e
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 g -> f
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 h -> g
$ cat b
test
$ cat h
cat: h: Too many levels of symbolic links
$ realcsh.c 
REAL csh: #include <stdlib.h>
REAL csh: #define _GNU_SOURCE
REAL csh: printf("%s\n", canonicalize_file_name("h"));
/tmp/t/a

16:13:43 # Life みつかさんのcannaパッケージをスポンサーしました．とりあえずアップロードだけしました．

2006年3月19日 (日曜日)

09:27:38 # Life powerpc linux の PLT が書き込み可能な件について． PLTが書き込み可能な件については，問題だという認識がされており， New ABIというのが提案されているようです．そのNew ABIというのは，2005年5月に提案され，マージされており，現状 Debian の sidの binutils のソースにもすでに入っているようです． binutils:bfd/ppc_elf_select_plt_layoutあたりが肝でしょうか． glibc, gccまでアップデートされないと反映しないということなので，現状はそういうことなのでしょう． Fedora Core の glibc はすでに対応しているっぽいです．

23:02:27 # Life muse-elを使ってみた． emacsのwikiエンジンである，emacs-wikiの最新フォークであるemacs-muse(Debian パッケージmuse-el)を試してみました．テキストファイルをwikiのバックエンドデータとして扱い， emacsで編集するとemacsのバッファがwikiのような挙動をしめす，というものです． HTMLやPDF(日本語対応はまだっぽい)にエキスポートできるので，スタティックなwikiとして利用できます．データはCVSなどで管理すれば複数の人で共有でき，wikiのような操作感は味わえます． emacs-wikiにはelserv-wikiというemacsをウェブサーバにしてしまいwikiをブラウザから編集できるというつわものアプリケーションがあったのですが， emacs-museには残念ながらないようです． RSS生成機能とかもないようなので，微妙にかゆいところに手がとどいていないぞー．東京エリアDebian勉強会のページをmuse版で生成してみました．いかがでしょうか．

2006年3月12日 (日曜日)

02:57:10 # Life slind. debian-develで話題になっていましたが，slindというのがあるようです． pbuilder, dpkg-cross, そしてクロスツールチェインをつかってクロスビルド環境を構築しているっぽい． i386, arm, ppc, uclibc-arm, uclibc-i386, uclibc-powerpc アーキテクチャのパッケージを構築しているようです．うーむ．詳細が気になります．

15:55:02 # Life rosegardenでMIDIの楽譜をロードさせてみた．それなりに楽譜っぽく見えるのだが，よくみると不自然なところがあり，非常にみにくい． 'beam'の設定のしかたがおかしいのだ．これはアルゴリズムでがんばれば改善できるのではないだろうか．自動でできたbeam.

本当は下記のようになってほしい．

2006年3月11日 (土曜日)

12:43:00 # Life 共有ライブラリはスタティックライブラリよりもオーバヘッドがあるの？最近のLinuxで共有ライブラリを利用したプログラムを利用する場合，スタティックリンクの場合との違いとして，関数呼び出しは一旦pltセクションというところのジャンプ命令を経由して本当の関数を呼び出すようになります．この背景としては，共有ライブラリがロードされるアドレスというのが事前に決定できないため，ロードしてから関数呼び出すのアドレスを解決するという現状のELFのダイナミックローディングの仕様があります．それを実現するために text セグメント(プログラムの実行可能データの領域．ジャンプ命令の呼び出し先アドレスなどが書かれている)を全部書き換えれるようにしてしまうと実行バイナリをそのままmmapで読み込み専用で読み込めないことになります．そうするとスワップ領域を無駄に確保する必要がでてきたりするので，変更できる部分を外だしにしている，というあたりがそもそもの理由のようです．関数呼び出しは，pltセクションに対してのジャンプ命令を発生し， pltセクションの該当する部分はGOTの適切な部分のアドレスを読み込みそのアドレスに飛びます． (powerpcの場合直接pltが書き変わっているきがしますが，これは確認必要です．) それにより実際の関数のコードへジャンプすることができます． powerpcで関数呼び出しだけを1G回するプログラムを作り，比較してみました．約500MHzで動作しているCPUなので，2秒が約1クロックサイクルです．同じ事を繰り返しているので一番高速な場合であることが予想できます．結果を見てみると，どうやら-fPICの場合，関数呼び出しに2クロックサイクルくらい余計にかかっているようです．

項目	共有ライブラリ版(-fPIC)	スタティックリンク版
実時間	17.646	13.746
ユーザ時間	17.005	13.233
システム時間	0.024	0.018

参考までに，PLTセクションに書き込まれていたブランチ命令はこんな感じです．

0x10011b70 <function_in_lib@plt+0>:	b       0xffdf590 <function_in_lib>

Athlon 64 2.2GHzで同様のテストをしてみました．今回は，2.2G回実行してみたところ下記の結果が得られました．どうやら2クロックくらい消費しているようです．ppcと同じくらいですね．アッセンブラを解析してみたところ，しっかりとジャンプテーブルがGOTに作成されており， PLTではGOTへのインデックスをとりジャンプするようになっていました．

項目	共有ライブラリ版(-fPIC)	スタティックリンク版
実時間	8.185	6.142
ユーザ時間	8.168	6.125
システム時間	0.000	0.002

ここで，oprofileで実行中の時間分布をみてみると，ちょっと予想をうらぎる結果がでました．しかしなぜこうなるのでしょう．続きはまた後で．

	共有ライブラリ版	スタティックリンク版
function_in_lib	61%	25%
main	28%	66%
.plt	4%	-

Ian Wienandさんにまちがいを指摘されたので訂正しました．彼の紹介してくれたこのページは非常にマニアックです．おすすめ． PLTセクションは書き込み可能ではないそうです．(古いABIではpowerpcではPLTセクションが書き変わっていた，とのことです．)

powerpc で確認してみたログです，li命令がb命令に置き換わっているので，pltセクションが書き変わっているみたいです．

(gdb) disassemble 0x10011b70
Dump of assembler code for function function_in_lib@plt:
0x10011b70 <function_in_lib@plt+0>:	li      r11,4
0x10011b74 <function_in_lib@plt+4>:	b       0x10011b40 <_GLOBAL_OFFSET_TABLE_+44>
End of assembler dump.
(gdb) cont
Continuing.

Breakpoint 2, main (ac=1, av=<value optimized out>) at main.c:50
(gdb) disassemble 0x10011b70
Dump of assembler code for function function_in_lib@plt:
0x10011b70 <function_in_lib@plt+0>:	b       0xffdf590 <function_in_lib>
0x10011b74 <function_in_lib@plt+4>:	b       0x10011b40 <_GLOBAL_OFFSET_TABLE_+44>
End of assembler dump.

22:18:34 # Life サーバ障害． netfort.gr.jpのサーバの/homeがフルになっていたため，メールが受信できていなかった可能性があります．何か重要なメールをだしていたのにもかかわらず返事が無い，という場合はお手数ですが，再送ください．

2006年3月9日 (木曜日)

23:49:44 # Life どんなCDROMデバイスがこのマシンにはつながっているの？ Linuxシステムにおいて，CDRをやいたりしたいのにCDROMデバイスがどういうデバイス名として認識されているのかよくわからない，そんなあなたに． dmesgを見てみたり，cdrecord -scanbusを実行したりしてもデバイス名がわからず，とりあえず全部のデバイスに対してejectコマンドを発行してみてCDROMが出てくるまで試行錯誤してたりしませんか？そんな人々に朗報です． Linuxシステムにおいて/proc/sys/dev/cdrom/infoを見ると，デバイスの一覧とそのデバイスが何をすることができるのか，という一覧が出力されます．知らなかった．

$ cat   /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:             hda
drive speed:            40
drive # of slots:       1
Can close tray:         1
Can open tray:          1
Can lock tray:          1
Can change speed:       1
Can select disk:        0
Can read multisession:  1
Can read MCN:           1
Reports media changed:  1
Can play audio:         1
Can write CD-R:         1
Can write CD-RW:        1
Can read DVD:           1
Can write DVD-R:        1
Can write DVD-RAM:      0
Can read MRW:           1
Can write MRW:          1
Can write RAM:          1

ただ，デバイスが複数ある場合については，なかなか機械的に処理しにくい形式のファイルなのがつらいところです．

2006年3月7日 (火曜日)

22:36:10 # Life Linux Audio 関連の開発者は非常にたくさんいる．それは，Linux-audio-devel メーリングリストの流量をみれば感じられるだろう．若く，なぜかプログラミングを初めてやってみました，という人が比較的多く，ただ熟練のコード書きも存在している．よしおかさんの記事をみて，自分の立ち位置を確認してみる． linux-audio-develにおいて必要なのは，大量のコードの流れ，新しいプログラムの開発，それを阻害しないように統合し，調整する流れだろう．そういう問題認識の上で，今Linuxディストリビューションを統合しようとしている． RPM系においては，昔から複数のディストリビューションが乱立しており， RPMパッケージはあるけどインストールはできないという状況はよくあった．最近その状況がDebianにも派生しつつあり， Ubuntustudio と DeMuDiがお互いにその状態になってきていた．全ディストリビューションは一応Debian sidをベースに開発しているので， Debian sidにパッケージさえ入れれば相互に再利用できるはずだ．ということで，今年の一月くらいから猛烈に活動中．その他の活動が絶賛停滞中．グラフでみるとあきらかに活動が活発になっているのがわかる．日本においてあまりaudio関連に興味のある開発者は居ない気がしているのだけれども，もし居るのであればこっそりメールでおしえてください．

2006年3月6日 (月曜日)

07:30:46 # Life gcc出てますね．気づいたら，4.1.0がリリースされていました．どういう変化があったのかについてはまだ確認してませんが，とりあえず進捗しているというのは良い事だと思います．

22:36:29 # Life qt3のアプリケーションの翻訳をしてみる． qt3のアプリケーションはgettextなどでは翻訳ができないようになっています．全く違うインフラで翻訳されているので，興味が出たので少し調べてみました．国際化可能なプログラムのソースコード内部ではQTranslatorクラスのtr(英語文字列)というメソッドを利用しているようです．これを利用して翻訳は，lupdateコマンドで抽出し，.tsファイルを生成し，そのファイルを翻訳することで，利用できます． .tsファイルはXML形式のデータで，翻訳自体はlinguistプログラムで実行します．それで処理できた成果をlreleaseコマンドで処理し，できたqmファイルを検索される場所においてあげるとメッセージが翻訳されてプログラムが動いてくれるようです．仕組みはわかりましたが，さて，それをどう実地にもっていけばよいのか，どこかで協調して作業しているのか，という点は問題です．どなたかこっそりとメールで教えて頂けるとありがたいです．

ソースディレクトリ$ lupdate *.cpp src/*.cpp -ts qjackctl.ts
ソースディレクトリ$ linguist qjackctl.ts
ソースディレクトリ$ lrelease qjackctl.ts
ソースディレクトリ# cp qjackctl.qm /usr/share/locale/qjackctl_ja_JP.EUC-JP.ts

ウェブ上を検索しても，lrelease/lupdateコマンドの使い方が全くかいてなくて弱りました． findtrコマンドはobsoleteなインタフェースのようなのですが，そうだったらそうでよいので代替が何なのか書いていて欲しい所です．

2006年3月1日 (水曜日)

18:29:07 # Life jack/alsa/oss. Linuxのマルチメディア関連のAPIはたくさんあり，アプリケーションもたくさんあるけれど，日本語で追跡できるようなリソースは意外と少ないのではないのじゃないか，と言うのが感想．解析してみたらちょっとは何かの足しになるか？

つれづれ日記 2006年3月

予定

毎日