sip_user: hiroaki_sengoku
sip_passwd: xxxxxxxx
sip_domain: ekiga.net
answer_rings: 30
answer_sound: /home/tam_ekiga/answer.raw
voicemail_time: 60
voicemail_dir: /home/tam_ekiga/LOCAL/voicemail

設定ファイル answer_machine.conf を ↑ のような感じで書いておいて、 留守番電話スクリプト answer_machine を実行する:

answer_machine --conf /home/tam_ekiga/answer_machine.conf

sip:hiroaki_sengoku@ekiga.net に着信があると、 応答メッセージを流した後、 相手の音声を録音し、 /home/tam_ekiga/LOCAL/voicemail ディレクトリに 8kHz サンプリングの 8bit μ-law 形式で保存する。 あとはこのディレクトリを監視するプログラムを走らせて、 新着録音をメールで送信するようにしておけばよい。

次に IPKall を利用 (申込には米国の IP アドレスからアクセスする必要あり) して電話番号をもらう。 米国ワシントン州リンデンの番号 +1-360-526-6699 が割当てられた。 上記 SIP 留守番電話が待受けている sip:hiroaki_sengoku@ekiga.net を、 この電話番号の転送先として IPKall に登録すれば、 Google Voice もどき (^^;) の出来上がり。 この番号に電話すると、 上記スクリプトが応答し (上記設定ファイルに answer_rings: 30 と書いてある通り、 30秒間呼び出しを続けないと応答しない)、 何かメッセージを吹き込めば mp3 形式の音声データが添付されたメールが私宛に届く。

この仕掛けを作った晩の翌日未明 3:16 に、 さっそく着信があり録音データが添付されたメールが届いた。 発信者の電話番号は +1-877-347-3760 だった (+1-877- は米国のフリーダイヤル)。 メールで送られて来た録音データがコレ。 英語が苦手な私にはちょっとつらい (^^;) が、 再生速度を遅めにして一生懸命聞き取ってみる:

Hello, this is a message for Korety Martin. If you are not Korety Martin, please hang up and call 877-347-3760 to remove this phone number from our records. If you continue to listen to this message, you are acknowledging that you are Korety Martin. This message contains personal and private information. There will now be a three second pause.

This is EOCCA, A Collection Agency. This is an attempt to collect a debt. Any information obtained will be used for that purpose. Please contact us about this important business matter at 877-347-3760. When calling please reference account number 9.

真面目にディクテーションするのが馬鹿馬鹿しくなるような、 絵に描いたような詐欺電話 (*_*)。 「Collection Agency」 は債権回収会社のこと。 「EOCCA, A Collection Agency」 で検索してみると、 いっぱい出てくる。 借金の心当たりがある人 (のうち 1% くらい?) は、 つい騙されて折り返し電話をかけてしまうのか。 日本とかだと人海戦術で電話をかけまくるらしいが、 自動で電話をかけまくるのが米国流なのか? 電話版スパムメールといった感じ?

なお、 最後がしり切れとんぼのような感じがするが、 これは録音時間を 60秒間に制限しているため (上記設定ファイルの voicemail_time: 60)。

以下は、 Perl プログラミングに興味があるかた向け:

CPAN に登録されている Net::SIP モジュールには、 サンプルプログラムとして留守番電話スクリプト answer_machine.pl が含まれている。 ところが、 このスクリプトだと着呼時にすぐオフフック (＝受話器を持ち上げて電話に出る) してしまう。 ふつー留守番電話といえば、 呼び出し時間 (つまりベル^H^H着メロを鳴らす時間) を設定できるものだと思っていたが、 残念ながらこのスクリプトにはそのような機能はない。 これでは留守じゃなくても留守番電話が先に出てしまう！

着呼時にすぐオフフックするのではなく、 一定秒数待ってからオフフックするようにスクリプトを修正するなんて、 sleep 命令を書き加えるだけだろうと思うかもしれないが、 さにあらず。 Net::SIP は非同期処理が中心なので、 全ての処理はイベントループ Net::SIP::Dispatcher::Eventloop から呼び出される仕組になっている。 つまり各処理の中で勝手に sleep とかすると、 他の処理が全部滞ってしまう。 逆に言うと、 非同期処理なので一つのプロセスで複数の通話を扱える。 つまり決してお話し中 (Busy) にならない。

answer_machine.pl から引用:

use Net::SIP;
use Net::SIP::Util ':all';
	...
$ua->listen(
	init_media => [ \&play_welcome, $welcome,$hangup,$savedir ],
	...
	}
);
$ua->loop;

着呼待ちのためのスクリプトはたったこれだけ。 $ua->listen で、 オフフックしたときに呼び出される Callback (init_media) として \&play_welcome (関数リファレンス) を登録し、 $ua->loop でイベントループに入る。 着呼すると即オフフックして関数 play_welcome を引数 $welcome, $hangup, $savedir 付で呼び出す。 play_welcome は、 留守番電話の応答メッセージ (「ただいま留守にしております。 ご用件のあるかたはピーッという音の後にお話下さい」 など) を送信し、 相手が話す 「用件」 を録音する関数。

answer_machine.pl では自前の関数 play_welcome を定義して init_media へ登録しているが、 Net::SIP::Simple::RTP モジュール内にも media_send_recv という (応答メッセージを) 送信して、 (相手の用件を) 録音する関数が定義されている。 これを使えば、

$ua->listen(
    init_media => $ua->rtp('media_send_recv', 'answer.raw', 1, 'out.raw'),
    );

などと書くこともできる。 ここで answer.raw は 8kHz サンプリングの 8bit μ-law 形式の音声データのファイル名で、 これが応答メッセージとして再生され、 ファイル out.raw に同形式で相手の用件が録音される。

したがって、 呼び出し時間が常に 0 秒で構わなければ、

#!/usr/bin/perl
use Net::SIP;
my $user = 'hiroaki_sengoku';
my $pass = 'xxxxxxxx';
my $domain = 'ekiga.net';
my $ua = Net::SIP::Simple->new(
    outgoing_proxy => $domain,
    registrar => $domain,
    domain => $domain,
    from => $user,
    auth => [ $user, $pass ],
    ) || die;
$ua->register;
$ua->listen(
    init_media => $ua->rtp('media_send_recv', 'answer.raw', 1, 'out.raw'),
    );
$ua->loop;

これだけで留守番電話として機能する。

まったくもって簡潔すぎて、 どこをどう変更すれば呼び出し時間を確保できるのか、 これだけでは見当もつかないが、 関数 $ua->rtp (init_media に登録された Callback) が呼び出された段階で既にオフフックしてしまっているわけで、 時すでに遅しということだけは分かる。 どうやってオフフックする前に一定秒数待つ処理 (以下、Ringing と略記) を割り込ませばよいだろうか?

Net::SIP のドキュメントにはオフフック前の挙動については一切言及がないので、 仕方なく Net::SIP::Simple の listen のソースを読んでみる:

sub listen {
	my Net::SIP::Simple $self = shift;
	my %args = @_;

	# handle new requests
	my $receive = sub {
		my ($self,$args,$endpoint,$ctx,$request,$leg,$from) = @_;
		...
		# new invite, create call
		my $call = Net::SIP::Simple::Call->new( $self,$ctx,{ %$args });
		my $cb = UNIVERSAL::can( $call,'receive' ) || die;
		...
		# setup callback on context and call it for this packet
		$ctx->set_callback([ $cb,$call ]);
		$cb->( $call,$endpoint,$ctx,undef,undef,$request,$leg,$from );
	};

	$self->{endpoint}->set_application([ $receive, $self,\%args ]);
}

set_application は、 endpoint (Net::SIP::Endpoint, 通信端点) とユーザとをつなぐ application を endpoint に登録するための関数。 例えば着呼したら着信音を鳴らすとか、 ユーザが受話器を持ち上げたら着呼処理を行なうとか、 通信相手の音声をスピーカに出力してユーザに伝えるとか、 等々を行なう application (Callback) を登録する。

ここで登録される application である $receive (無名関数へのリファレンス) の処理内容を追っていくと、 実質的には Net::SIP::Simple::Call->receive を呼び出しているだけ。 で、この Net::SIP::Simple::Call->receive こそが実際の着呼処理、 すなわち通信相手からの INVITE リクエストに対して 「SIP/2.0 200 OK」 を返す処理を行なっている。

ということはつまり、 Net::SIP::Simple::Call->receive の呼び出しが行なわれる前に Ringing 処理を割り込ませばよい。 いろいろ方法はあると思うが、 endpoint に登録されている application を、 Ringing を行なう無名関数で置き換えてみた:

    my $sub = $ua->{endpoint}->{application}->[0];
    $ua->{endpoint}->{application}->[0] = sub {
	my ($self, $args, $endpoint, $ctx, $request, $leg, $from) = @_;
	my $meth = $request->method;
	if ($meth eq 'INVITE') {
	    my $res = $request->create_response('180', 'Ringing');
	    $endpoint->new_response($ctx, $res, $leg, $from);
	    $self->add_timer($rings, [$sub, $self, $args,
				      $endpoint, $ctx, $request, $leg, $from]);
	} else {
	    $endpoint->close_context($ctx);
	}
    };

これで着呼時にオフフックせずに、 Ringing を行なうことになる。 つまり、 「180 Ringing」 レスポンスを返し、 一定秒数 ($rings 秒) 後にオフフックさせるために add_timer を呼ぶ。 add_timer は、 第一引数 ($rings) で示す秒数後に、 第二引数 ([$sub, ...]) を Callback として呼び出すタイマーを登録する関数。 第二引数に、 元々 endpoint に登録されていた application へのリファレンス $sub を指定すれば、 $rings 秒後にオフフックして留守番応答が行なわれる。

米国内 IP アドレスは Linode VPS (Virtual Private Server, 仮想専有サーバ) を契約しているので既に持っている。 この VPS 上で PPTP (Point to Point Tunneling Protocol) デーモンを立ち上げておけば、 Windows 標準機能の 「仮想プライベート ネットワーク」 (VPN) で接続して、 米国内からのアクセスを装うことができる。 WWW アクセスだけなら proxy server を立ち上げておくだけで充分かと思ったが、 proxy 経由のアクセスかどうか Google サーバ側で見ているらしく、 proxy 経由では Google Voice は利用できない。

なお、 いったん Google Voice の設定を済ませて Google Number を確保してしまえば、 米国内国外を問わず任意のマシンから Google Voice を利用可能。 つまり Google Number を確保するときのみ、 米国内の IP アドレスからアクセスする必要がある、 ということ。

米国内の電話番号は、 無料で電話番号を割当ててくれるサービスがあるのでそれを利用する。 私は IPKall を利用した。 こちらも米国内の IP アドレスからアクセスする必要があるが、 Google Voice とは異なり米国内の proxy server を経由するだけで登録できる。 SIP フォン (VoIP 電話) のアドレスと、 メールアドレスを登録すると、 ワシントン州の電話番号を一つ割当て、 それをメールで教えてくれる。 割当てられた電話番号に着呼すると、 登録した SIPフォンへ転送してくれる仕掛け。 ただ、 米国は電話代が安すぎるためかイタ電が多いのがちょっと困りもの。 いたずら電話に困っている人がよほど多いのか、 WhoCallsMe.com, Who Called Us, PhoneOwner.info, white pages, Location Lookup など、 かかってきた電話番号を調べるサービスがいくつもある。

維持費用無しで米国の電話番号を持てるのは大変ありがたいが、 30日間サービスを利用していないと登録が無効になってしまう (IPKall の場合)。

IPKall Signup
**ABSOLUTELY FREE**
Washington state phone number to your IP phone.
...(中略)...
Accounts that are inactive for 30 days will be terminated for non-use.

IPKall Signup から引用

「inactive」 というのが、 (1)通話実績がないことを意味するのか、 (2)着呼だけでも 「active」 と見做されるのか、 あるいは (3)登録情報を更新するだけでもよいのかは不明。

仮に (1) だとすると、 毎月日本から国際電話をかけて通話実績を作らなければならず、 とても面倒だしお金もかかる。 そこで Google Voice を使って通話実績を作ることを考えた。 自動で発呼できれば手間もかからず番号を維持できる。 しかも 2011年中 Google Voice は米国内宛の通話が無料らしいので発呼の実験し放題。

Java や Python などから Google Voice をアクセスする 非公式な Google Voice API が発表されているが、 公式ではないので Google が仕様変更すると使えなくなる恐れあり。 「非公式 API」 のコードを見てみると、 内容的にはとても単純であるように見える。 この程度なら自分で一から書いた方が Google の仕様変更への追随も即座にできるし、 Java や Python よりは Perl で書きたかったというのもあって、 さくっと書いてみた。 わずか 58行、 しかも後述するように follow_meta_redirect のバグ対策で 21行ほど要してるので、 実質だとわずか 27行。

Google Voice で通話するには、 いわゆる 「V字発信」 を行なう。 つまり電話をかけようとする自分の側と通話先である相手側との両方に対して Google から電話をかけ、 両者を繋いで通話する。 自分の側の電話はあらかじめ登録してあるものから選ぶ。

Google Number を取得済の場合は、 Google Voice ページにアクセスすると左上のロゴの下に 「Call」 ボタンがあって、 押すと
← のようなウィンドウが現れる。

「Number to call」 に通話先の電話番号、 「Phone to call with」 に登録してある自分の電話のうちどれを選ぶかを指定し、 「Connect」 ボタンを押す。 自分の電話の電話番号の代わりに、 (登録済であれば) Google Talk や Gizmo5 のアカウントを指定することもできる。

すると、 まず自分の電話 (あるいは Google Talk や Gizmo5) に対して Google から発呼が行なわれる。 電話に出ると、 次に Google は通話先の番号に対して発呼を行なう。 呼び出し中は呼び出し音が自分の電話から聞こえ、 相手が出ればそのまま通話できる。

以上を、 ブラウザで操作する代わりに、 Perl スクリプトから行なえばよい。
まず Google Voice にログインする:

my $mech = WWW::Mechanize->new();
$mech->get("https://www.google.com/voice");
$mech->success || die "Fail to access\n";
my $res = $mech->submit_form(
    form_id => "gaia_loginform",
    fields => {
	Email => $user,
	Passwd => $pass,
    }
    );
$res->is_success || die "Fail to login\n";

「WWW::Mechanize」 は、 ブラウザでの操作を簡単にスクリプト化できる便利な Perl モジュール。 「ページを開く」 「ボタンを押す」 「リンクをたどる」 等々、 ブラウザ操作をずらずら書くだけで自動化が実現できてしまう。 混雑時は何度もリロードしないとアクセスできないチケット販売サイト等で、 どうしてもチケットを購入したいときに威力を発揮する(うそ)。

最初に "https://www.google.com/voice" をアクセスすると、 Google アカウントのログインページが表示される。 HTML ソースを見ると、

<form id="gaia_loginform"
      action="https://www.google.com/accounts/ServiceLoginAuth" method="post"
      onsubmit="return(gaia_onLoginSubmit());" >
	...
<input type="text" name="Email" id="Email"
       size="18" value="" class='gaia le val' />
	...
<input type="password" name="Passwd" id="Passwd"
       size="18" class="gaia le val" />
	...
<input type="submit" class="gaia le button" name="signIn" id="signIn"
       value="Sign in" />
	...
</form>

などとなっているので、 ID が "gaia_loginform" である form について、 「Email」 フィールドに gmail アドレス、 「Passwd」 フィールドにパスワードを入力して、 「Sign in」 ボタンを押せばよいことが分かる。 この操作をそのままスクリプトで記述して、

my $res = $mech->submit_form(
    form_id => "gaia_loginform",
    fields => {
	Email => $user,
	Passwd => $pass,
    }
    );

などと書けばよい。 もちろん変数 「$user」 「$pass」 には、 あらかじめそれぞれ 「gmail アドレス」 「パスワード」 を代入しておく。

大変便利な WWW::Mechanize モジュールだが、 画竜点睛を欠くことに meta refresh に対応していない。 すなわち、 「Sign in」 ボタンを押すと、 Google サーバから次のようなレスポンスが返ってくるが、

<html><head><title>Redirecting</title>
	...
<meta http-equiv="refresh" content="0; url=&#39;http://www.google.co.jp/accounts/SetSID?ssdc=1&amp;sidt=...(中略)...&#39;"></head>
<body ... >
	...
</body></html>

「<meta http-equiv="refresh" content="0; url=...」 タグがあるので、 「url=」 で示された URL へ遷移する必要がある。 ブラウザは自動でこのページ遷移を行なうが、 WWW::Mechanize は遷移してくれないので、 WWW::Mechanize::Plugin::FollowMetaRedirect モジュールの follow_meta_redirect を呼び出す必要がある。

ところが残念なことに follow_meta_redirect にはバグ? があり、 点睛を入れても龍は空へ飛んでいかない。 上記のように URL が 「&#39;」 (「'」 single quote) で囲われていると、 「'」 を含めて URL として扱ってしまう (つまり不正な URL になる) ために、 サーバ側に拒絶される。

仕方ないので、 follow_meta_redirect と同等のことを行なう関数 follow_refresh を、 follow_meta_redirect を真似して書いた:

sub follow_refresh {
    my ($mech) = @_;
    my $content = $mech->content;
    my $p = HTML::TokeParser->new(\$content) || return $content;
    while (my $token = $p->get_token) {
	if ($token->[0] eq 'S' && $token->[1] eq 'meta') {
	    if (defined $token->[2] && ref $token->[2] eq 'HASH') {
		if (defined $token->[2]->{'http-equiv'}
		    && $token->[2]->{'http-equiv'} =~ /^refresh$/io) {
		    if (defined $token->[2]->{'content'}
			&& $token->[2]->{'content'}
			=~ m|^(([0-9]+);\s*)*url\=(\'?)(.+)\3$|io) {
			$mech->get($4);
			return $mech->content;
		    }
		}
	    }
	}
    }
    return $content;
}

URL が 「'」 で囲われているときは、 その 「'」 を取り除いて $mech->get するだけ。 この関数を呼び出すことにより、 上記 meta タグで指定された URL へ遷移できる。

こうして遷移したページには、 以下のような部分がある:

<form action="#" id="gc-search-form" method="post" onsubmit="return false;">
<input name="_rnr_se" type="hidden" value="3W/C7p9ElNW6H+LdP0ndD9EIek4="/>

Google Voice では、 このように隠しフィールド (type="hidden") を使って 「_rnr_se」 の値を引き回しているようだ。 この値は Google Voice で電話をかける際にも必要なので、 保存しておく:

my $content = &follow_refresh($mech);
$content =~ m/\<input\s+name=\"_rnr_se\"[^\>]*\svalue=\"(.*)\"/
    || die "Fail to get _rnr_se\n";
my $rnr_se = $1;

以上で Google Voice へのログインが完了。

次に、 Google Voice ページの 「Connect」 ボタン (前述) を押したとき、 どのようなリクエストが Google サーバへ送られるか調べる。 ブラウザの挙動を模倣する Perl スクリプトを書けば、 ブラウザで操作する代わりに Perl スクリプトで発呼を行なわせることができるはず。

どんなリクエストがサーバへ送られるか調べるには、 Live HTTP headers アドオンが便利 (FireFox の場合)。 実際に調べてみるとこんな感じ:

POST /voice/call/connect/ HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Referer: https://www.google.com/voice?pli=1
Content-Length: 146
Cookie: (省略)
Pragma: no-cache
Cache-Control: no-cache

outgoingNumber=360469zzzz&forwardingNumber=253802yyyy&subscriberNumber=undefined&phoneType=2&remember=0&_rnr_se=3W%2FC7p9ElNW6H%2BLdP0ndD9EIek4%3D

POST リクエストの本文 (Content) に、 自分の電話番号 「253802yyyy」 (一部伏字、以下同様) と 通話先電話番号 「360469zzzz」 が指定されていることが分かる。 前述した 「_rnr_se」 の値も指定されている。

あとは同じリクエストを送信する Perl スクリプトを書くだけ:

$mech->post("https://www.google.com/voice/call/connect/",
	    Referer => "https://www.google.com/voice/",
	    Content => {
		outgoingNumber   => $call,
		forwardingNumber => $home,
		subscriberNumber => "undefined",
		phoneType        => 2,	# 7:gizmo, 9:gtalk
		remember         => 0,
		_rnr_se          => $rnr_se
	    });
$mech->success || die "Fail to call\n";

おそらく TS のデータに何らかの誤りがあって ffmpeg が映像データを読むのをそこで止めてしまうためだろうと思っていた。 そりゃ放送なんだからノイズが混じることもあるだろうと思い込んでいたのだが、 よほど電波状況が悪くない限りエラー補正が効くだろうから、 ノイズが原因というのはありそうもない話。

なぜ PS へ変換したいかといえば、 TS のままだとファイルサイズが大きすぎる (2時間の映画番組とかだと 12GB を超える) ので、 PS へ変換し (CM カットなどの編集を行なうときは PS の方が便利)、 さらに MPEG-4 などへ変換してサイズを小さくしたいから (もちろん保存する必要がない番組は見たらすぐ消す)。 ところが PS への変換に失敗した番組は TS のまま保存せざるを得ず、 そういうファイルが増えてきて、 2TB のハードディスクもだんだん手狭になってきた。

そこで、 何が原因で TS の読み込みに失敗しているのか、 まずは調べてみようと思ったのだが、 いかんせんファイルがデカすぎる。 12GB もあるとファイルの内容をダンプするのもままならない。 そこで変換が失敗する近辺のデータだけ抜き出して詳しく調べてみようと考えた。 MPEG-2 TS の仕様を調べてみると、 PCR (Program Clock Reference) なるタイムスタンプが 100msec 以下の間隔で MPEG-2 TS には埋め込まれているらしい。 問題の TS ファイルは、 2時間の番組中、 先頭から 1時間35分41秒ほど経過したあたりで読み込みに失敗するので、 PCR の値を手がかりにその近辺のデータを抜き出そうと考えた次第。

まずは PCR の値を表示する perl スクリプト tsdump.pl を作ってみた (後述する tsrenum.pl に -v オプションを与えることによって同じ出力が得られる)。

% ./tsdump.pl -v < 133000_GR23.ts
0008c4a PCR 24:55:00.570 8073051319+138
001a12d PTS 24:55:01.111 8073100071
001a132 DTS 24:55:01.011 8073091062
001d841 PTS 24:55:00.748 8073067367
0022556 PCR 24:55:00.628 8073056524+157
00226d5 PTS 24:55:01.045 8073094065
0026a65 PTS 24:55:00.769 8073069287
0029dcd PTS 24:55:01.078 8073097068
00300f1 PTS 24:55:00.791 8073071207
0033225 PTS 24:55:01.212 8073109080
003322a DTS 24:55:01.111 8073100071
0038f69 PTS 24:55:00.812 8073073127
003bcea PCR 24:55:00.685 8073061729+175
...

「133000_GR23.ts」 が問題の TS ファイル (23チャンネルなので TV東京 ^^;)。 次の 「0008c4a PCR 24:55:00.570 8073051319+138」 という行は、 ファイル先頭から 0008c4a バイト目に PCR があって、 そのタイムスタンプが 「24:55:00.570」 であることを示す。

行末尾の 「8073051319+138」 は生の PCR の値。 つまり、 PCR は 33bit の 「PCR base」 と 9bit の 「PCR extension」 から構成されるが、 それぞれ 8073051319 と 138 であることを示す。 PCR base は 90kHz の解像度、 PCR extension は 27MHz の解像度。 とりあえずここでは後者は無視して、 前者 8073051319 を 90000 (= 90kHz) で割ると 89700.570 秒で、 時分秒に直すと 24:55:00.570 になる。

PCR の他に、 PTS (Presentation Time Stamp) と DTS (Decode Time Stamp) というタイムスタンプも MPEG-2 TS には埋め込まれている。 これらは PCR と違って 90kHz の解像度の 33bit のデータのみ。 MPEG-2 TS では、 PCR の時刻を基準にして、 復号する時刻 (DTS) と再生する時刻 (PTS) を定めている (音声と映像の同期のためにも使われる)。 前述したプログラムの出力において、 2カラム目に PTS, DTS と出力している行は、 それぞれ PTS, DTS の値であることを示す。

で、 PCR の値を表示させてみていきなり気付いてしまったのだが、 この問題の TS ファイルは PCR の値が 33bit の上限値ギリギリ。 33bit の上限は 0x1FFFFFFFF = 8589934591 だから、 PCR は 26:30:43.717 (26時間30分43秒余) までしかカウントできない。 このファイルは冒頭のタイムスタンプが 24:55:00.570 だから、 冒頭から 01:35:43.147 ほど経過したあたりで PCR の値が桁あふれ (オーバーフロー) を起こして 00:00:00.000 へ戻ってしまう (ラップアラウンド)。

これは冒頭から 1時間35分41秒ほど経過したあたりで ffmpeg が止まってしまう症状にピッタリ符合する (2秒ほど差があるのは MPEG-2 復号に要する時間?) ので、 もう原因は PCR のラップアラウンド (PCR Wrap-around) で間違いないと推測。

「VLC で再生する分には問題がない」 と書いたが、 この問題の TS ファイルを VLC で再生して 1時間35分41秒あたり (VLC の場合 TS 再生時は時刻表示を行なわないのでシーンで探さざるを得ず大変) をよく見てみると、 再生が一瞬 (1秒ほど?) 止まっていた。 26時間半に一度、 必ず起こるラップアラウンドなのに、 VLC でも完全な対策は (まだ) 行なわれていないようだ。

原因調査の準備のために作ったスクリプトが、 いきなり原因究明の役に立つとは (^^;) と思いつつ、 tsdump.pl にタイムスタンプの値を付け替える (すなわち 24:55:00.570 から始まるタイムスタンプを 00:00:00.000 始まりにリナンバーする) 処理を付け加えたスクリプト tsrenum.pl を書いてみた (後述する pcr_write, ts_write 関数を追加しただけ)。

% ./tsrenum.pl < 133000_GR23.ts > 133000_GR23_fixed.ts

tsrenum.pl を使ってタイムスタンプを付け替えた 133000_GR23_fixed.ts は、 ffmpeg を使って PS 変換ができるようになった。 原因調査の準備のために作ったスクリプトが、 ほとんどそのまま問題解決の役にも立ってしまった (^^;)^2。

tsrenum.pl は、 標準入力から読み込んだ MPEG-2 TS において最初に現れた PCR/PTS/DTS タイムスタンプを基準 (下記スクリプト中の $pcrOrg) にして、 タイムスタンプを付け替えて標準出力へ書き出す:

#!/usr/bin/perl
use strict;
use warnings;
use POSIX;
use Getopt::Std;
our ($opt_v);
getopts('v') || &help;
my $PacketSize = 188;
my $offset = 0;
my $pcrOrg;
for (;;) {
    my $buf;
    my $len = read(STDIN, $buf, $PacketSize);
    last unless $len > 0;
    my @buf = unpack("C*", $buf);
    die if $buf[0] != 0x47;	# sync byte
    my $ind = (($buf[1] & 0xE0) >> 5);
    my $adp = (($buf[3] & 0x30) >> 4);
    my $pos = 4;
    if ($adp & 0x2) {	# Adaptation field exist
	$pos++;
	my $af = $buf[$pos++];
	if ($af & 0x10) {
	    my ($pcr33, $pcr9) = &pcr(\@buf, $pos);
	    printf(STDERR "%07x PCR %s %d+%d\n",
		   $offset+$pos, &stime($pcr33), $pcr33, $pcr9) if $opt_v;
	    &pcr_write(\@buf, $pos, $pcr33);
	    $pos += 6;
	}
	if ($af & 0x08) {
	    $pos += 6;
	}
	if ($af & 0x04) {
	    $pos++;
	}
    }
    if ($ind & 0x02) {
	if ($buf[$pos] == 0x00 && $buf[$pos+1] == 0x00
	    && $buf[$pos+2] == 0x01 && ($buf[$pos+6] & 0xC0) == 0x80) {
	    my $flag = $buf[$pos+7];
	    $pos += 9;
	    if ($flag & 0x80) { # PTS
		my $ts = &ts(\@buf, $pos);
		printf(STDERR "%07x PTS %s %d\n",
		       $offset+$pos, &stime($ts), $ts) if $opt_v;
		&ts_write(\@buf, $pos, $ts);
		$pos += 5;
		if ($flag & 0x40) { # DTS
		    my $ts = &ts(\@buf, $pos);
		    printf(STDERR "%07x DTS %s %d\n",
			   $offset+$pos, &stime($ts), $ts) if $opt_v;
		    &ts_write(\@buf, $pos, $ts);
		    $pos += 5;
		}
	    }
	}
    }
    syswrite(STDOUT, pack("C*", @buf), $len);
    $offset += $len;
}

sub stime {
    my ($ts) = @_;
    my $sec = floor($ts / 90000);	# 90kHz
    $ts -= $sec * 90000;
    my $min = floor($sec / 60);
    $sec -= $min * 60;
    my $hour = floor($min / 60);
    $min -= $hour * 60;
    return sprintf("%02d:%02d:%02d.%03d", $hour, $min, $sec, $ts/90);
}

sub help {
    print STDERR <<EOF;
Usage: tsrenum.pl <opt>
opt:   -v            ; verbose
EOF
    exit 1;
}

MPEG-2 TS を標準入力から 1パケットずつ @buf に読み込んで、 PCR を見つけたら
pcr(\@buf, $pos) 関数を呼び出して PCR base の値 $pcr33 を取得し、
pcr_write(\@buf, $pos, $pcr33) 関数で PCR base の値を変更して標準出力へ書き出す。 PTS, DTS についても同様に、 ts(\@buf, $pos) 関数を呼び出して値を取得し、 ts_write(\@buf, $pos, $ts) 関数で変更する。

ISO/IEC 13818-1 の 2.4.3.4節 Adaptation field (20ページ) の Table 2-6 - Transport Stream adaptation field を見ると、 adaptation field の 2バイト目から 33bit が PCR base の値、 続いて 6bit の予約ビット、 その次の 9bit が PCR extension の値であることが分かる。 したがって pcr(\@buf, $pos) 関数は以下のように書ける:

sub pcr {
    my ($br, $pos) = @_;
    my $pcr33 = (($br->[$pos] << 25) | ($br->[$pos+1] << 17)
		 | ($br->[$pos+2] << 9) | ($br->[$pos+3] << 1)
		 | (($br->[$pos+4] & 0x80) != 0));
    my $pcr9 = ((($br->[$pos+4] & 0x01) << 8) | $br->[$pos+5]);
    return ($pcr33, $pcr9);
}

pcr_write(\@buf, $pos, $pcr33) 関数は PCR base の値 $pcr33 から $pcrOrg を減算してから pcr(\@buf, $pos) 関数の逆を行なうだけ:

sub pcr_write {
    my ($br, $pos, $pcr33) = @_;
    $pcrOrg = $pcr33 unless defined $pcrOrg;
    $pcr33 -= $pcrOrg;
    $br->[$pos] =   (($pcr33 >> 25) & 0xFF);
    $br->[$pos+1] = (($pcr33 >> 17) & 0xFF);
    $br->[$pos+2] = (($pcr33 >>  9) & 0xFF);
    $br->[$pos+3] = (($pcr33 >>  1) & 0xFF);
    if ($pcr33 & 1) {
	$br->[$pos+4] |= 0x80;
    } else {
	$br->[$pos+4] &= 0x7F;
    }
}

ISO/IEC 13818-1 の 2.4.3.7節 Semantic definition of fields in PES packet (31ページ) の Table 2-17 - PES packet を見ると、 PES (Packetized Elementary Stream) の 9バイト目から marker bit を挟みつつ 33bit の PTS と DTS が格納されていることが分かる。

したがって ts(\@buf, $pos) 関数と ts_write(\@buf, $pos, $ts) 関数は以下のように書ける:

sub ts {
    my ($br, $pos) = @_;
    return ((($br->[$pos] & 0x0E) << 29)
	    | ($br->[$pos+1] << 22) | (($br->[$pos+2] & 0xFE) << 14)
	    | ($br->[$pos+3] << 7)  | (($br->[$pos+4] & 0xFE) >> 1));
}

sub ts_write {
    my ($br, $pos, $ts) = @_;
    $pcrOrg = $ts unless defined $pcrOrg;
    $ts -= $pcrOrg;
    $br->[$pos] =   ((($ts >> 29) & 0x0E) | ($br->[$pos] & 0xF1));
    $br->[$pos+1] =  (($ts >> 22) & 0xFF);
    $br->[$pos+2] = ((($ts >> 14) & 0xFE) | ($br->[$pos+2] & 0x01));
    $br->[$pos+3] =  (($ts >>  7) & 0xFF);
    $br->[$pos+4] = ((($ts <<  1) & 0xFE) | ($br->[$pos+4] & 0x01));
}

すべて解決した後で気付いたのだが (^^;)、 ラップアラウンドする TS ファイルを読み込んだときは ffmpeg が的確なエラーメッセージを出力していた:

...
frame= 1328 fps= 21 q=2.0 size=   31898kB time=44.00 bitrate=5938.8kbits/s dup=24 drop=0    
frame= 1341 fps= 21 q=2.0 size=   32002kB time=44.45 bitrate=5898.1kbits/s dup=24 drop=0    
[mpegts @ 0x6253c0]Invalid timestamps stream=0, pts=4078, dts=8589929661, size=53459
*** drop!
*** 1 dup!
*** drop!
*** drop!
*** drop!
*** drop!
*** drop!
adding -2147483648 audio samples of silence
adding -2147483648 audio samples of silence
*** drop!
...

「Invalid timestamps ... pts=4078, dts=8589929661」 すなわち PTS が 00:00:00.045 なのに、 DTS が 26:30:43.663 なので無効なタイムスタンプである、 というエラー出力。 タイムスタンプがラップアラウンドしたときは、 「Invalid timestamps」 とは言えないと思うのだが...

念のため ffmpeg の最新版を 「git clone git://git.ffmpeg.org/ffmpeg/」 で取得してコンパイルしてみたのだが、 「FFmpeg version git-735bbae」 でも同様に 「Invalid timestamps」 エラーが出力された。

どうして Android にはマルチタッチを活用したアプリケーションが無いのだろう？ と思ったので、 マルチタッチを試すテストアプリ MultiTouch.java (apk) を書いてみた:

タッチした位置にタッチの強さに応じた大きさの円を表示するだけの単純なアプリ。 指を移動すれば円も追随する。 Android ではタッチID が順に割り振られるので、 ID が 0 のタッチを赤色の円で、 ID が 1 のタッチを緑色の円で描いている。

プログラム上は ID が 2 のタッチを青色の円で描くことになっているが、 残念ながら現行の Android で同時に扱えるタッチは 2箇所のみ (追記: Samsung Galaxy S は 5箇所のマルチタッチが可能らしい) なので、 3箇所にタッチしても三つ目の円が描かれることはない。 だから例えば iPhone のアプリにあるような鍵盤楽器アプリを作ろうと思っても、 三つ以上の音を同時に鳴らすことはできない。

とはいえ、 2箇所のタッチを独立に扱えれば、 いろいろ応用が効くだろうにと思いつつ、 このテストアプリをいじっていると...

ありゃ?

上の写真の状態から、 左指を上方へ、右指を下方へ動かしただけなのだが、 両方の指の X 座標 (画面では上下方向) が交わった時点で両方の円の X 座標が入れ替わってしまって、 緑円は右指の動きに合わせて下へ動き、 赤円は左指の動きに合わせて上に動いた。 その結果、 指の位置と円の位置がずれてしまった:

つまり複数のタッチ (x_i, y_i), (x_j, y_j) を個別に扱えるのではなく、 X 座標の集合 {x_i, x_j} と Y 座標の集合 {y_i, y_j} として検知している模様。 例えて言うならダイオード無しのスイッチ・マトリックスみたいな感じ。 だから (x_i, y_i), (x_j, y_j) の 2点をタッチしているのか、 (x_i, y_j), (x_j, y_i) の 2点をタッチしているのか、 の区別ができない。

Android のマルチタッチを扱うプログラムの書き方について解説している Web ページをほとんど見かけないので、 MultiTouch.java についても一応解説:

タッチイベントは、 MotionEvent インスタンスとして Android OS からアプリへ伝えられる。 MotionEvent#getAction() メソッドでイベント種別 (ACTION_DOWN ならタッチ開始、 ACTION_MOVE ならドラッグ、 ACTION_UP ならタッチ終了といった具合) が取得できる。

マルチタッチの場合、 すなわちすでにタッチしている状況において追加で別の場所にタッチした場合、 ACTION_DOWN の代りに ACTION_POINTER_DOWN イベントが伝えられる。 パネルから指が離れてタッチが終わる場合、 まだ他の場所でタッチが継続しているのなら、 ACTION_UP の代りに ACTION_POINTER_UP イベントが伝えられる。

今回のテストプログラムの場合、 タッチの座標が分かればよいので、 ACTION_DOWN, ACTION_POINTER_DOWN, ACTION_MOVE は区別せずに、 put_points メソッド (後述) でイベントの座標を記録している。

	public boolean onTouchEvent(MotionEvent ev) {
	    int action = ev.getAction();
	    switch (action & MotionEvent.ACTION_MASK) {
	    case MotionEvent.ACTION_DOWN:
	    case MotionEvent.ACTION_POINTER_DOWN:
	    case MotionEvent.ACTION_MOVE:
		put_points(ev);
		break;
	    case MotionEvent.ACTION_UP:
		points.remove(ev.getPointerId(0));
		break;
	    case MotionEvent.ACTION_POINTER_UP:
		put_points(ev);
		int index = (action & MotionEvent.ACTION_POINTER_INDEX_MASK)
		    >> MotionEvent.ACTION_POINTER_INDEX_SHIFT;
		points.remove(ev.getPointerId(index));
		break;
	    }
	    Canvas canvas = getHolder().lockCanvas();
	    if (canvas != null) {
		onDraw(canvas);
		getHolder().unlockCanvasAndPost(canvas);
	    }
	    return true;
	}

MotionEvent インスタンスには 複数 (現状 2個までだが、 API 仕様的には 256個まで可能) のタッチの座標および強さ (pressure) が格納できて、 getX(i), getY(i), getPressure(i) の各メソッドを呼び出すことにより、 i番目 (i=0, 1,...) のタッチの X座標、Y座標、強さがそれぞれ取得できる。 タッチの個数は getPointerCount() メソッドで取得できる。 マルチタッチをサポートしない Android 2.0 eclair だと getPointerCount() は常に 1 を返す (ちなみに 1.5 cupcake や 1.6 donut だと getPointerCount() は存在しない)。

各タッチは、 指がパネルに触れてから離れるまで固有の ID が OS によって割り振られるので、 アプリは各タッチの動きをそれぞれ追うことができる。 getPointerId(i) メソッドを使えば i番目のタッチの ID が取得できる。

put_points(MotionEvent ev) メソッドでは、 id をキーとし、 TouchPoint (X座標、Y座標、強さの組) を値とするハッシュテーブル points に、 各タッチの現在値を登録している:

    class TouchPoint {
	public float x;
	public float y;
	public float p;
    }
    Hashtable<Integer, TouchPoint> points;
	...
	points = new Hashtable<Integer, TouchPoint>();
	...

	void put_points(MotionEvent ev) {
	    int count = ev.getPointerCount();
	    for (int i=0; i < count; i++) {
		int id = ev.getPointerId(i);
		TouchPoint p = new TouchPoint();
		p.x = ev.getX(i);
		p.y = ev.getY(i);
		p.p = ev.getPressure(i);
		points.put(id, p);
	    }
	}

現状 ID は 0 または 1 の値しかとらないようなので、 ハッシュテーブル (java.util.Hashtable) は牛刀な感を否めないが、 API 仕様上 ID は int 型としか規定していない (つまり最大値が 1ではなく int 型の上限となる可能性がある ^^;) ので、 配列ではなくハッシュテーブルを使った次第。

あとは SurfaceView#onDraw(Canvas canvas) にて、 points ハッシュテーブルに登録された座標、強さのデータ通りに円を描くだけ。

追記:
twitter で Galaxy S のマルチタッチはマトモと教えていただきました (_O_)
以下、頂いたツイートを (時間順に) 引用:

	gcd_org Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました http://www.gcd.org/blog/2010/07/613/ NexusOneだと座標を正しく取得できないケースがあるのですが他の機種だとどうですか？ #androidjp 2010年7月26日 10:41:34
	northeye @gcd_org Galaxy Sはわりとまとものようです http://www.youtube.com/watch?v=hVlsRCMltDg 2010年7月26日 10:45:20
	gcd_org @northeye すごい＞Galaxy Sのマルチタッチ。これで3点以上のマルチタッチがサポートされたら言うことなしですね。 RT Galaxy Sはわりとまとものようです http://www.youtube.com/watch?v=hVlsRCMltDg 2010年7月26日 10:54:20
	northeye @gcd_org 5点までいけるそうです http://www.youtube.com/watch?v=KRCDRXYJBCY 2010年7月26日 10:56:10
	nakamichito Galaxy Sではこんな感じです RT @gcd_org: Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました http://www.gcd.org/blog/2010/07/613/ #androidjp 2010年7月26日 11:13:40
	nakamichito URL忘れてた！ http://bit.ly/bFBicn RT @nakamichito: Galaxy Sではこんな感じです RT @gcd_org: Androidのマルチタッチについて書いてるページが見当たらなかったのでブログを書いてみました #androidjp 2010年7月26日 12:25:39

すでに同種のテストアプリが Android Market で公開されていたのですね。
車輪の再発明をしてしまった (後悔はしていない ;-)。

Nexus One や iPhone など全面タッチパネルの携帯電話だと、 (受話器として使うために) 耳に近づけたときタッチパネルが反応しては困る。 そこで近接センサを使って顔が接近してくることを感知し、 タッチパネルを無効にする (ついでにディスプレイをオフにして消費電力を抑える)。

私は Proximity なんて聞くと、 Proximity Warning System (接近警報システム) を思い浮かべてしまうくらいで、 携帯電話用の近接センサがどういうしくみか全く知らなかった。 今年1月の Nexus One の発表の時に近接センサのことを初めて知り、 その時はタッチパネル全体への接近を感知する (静電容量の変化を検知して?) のかと想像したが、 後述するように Nexus One の近接センサはタッチパネルの左上にしかなく、 タッチパネルの下方への接近は感知できないことが分かった。

Nexus One のどこに近接センサが搭載されているか、 センサの感応範囲がどれくらいなのか、 私には見当もつかなかったし、 google で検索してもその手の情報は見つからなかったので、 近接センサが感知した値を表示するだけの簡単なプログラムを書いてみた。

実は、 私にとって初めての android アプリ (^^;)。 しかも、 ここ数年 Java から遠ざかっていたので、 久々に書く Java プログラムだったりする。

お膳立ては Android SDK が全てやってくれるので、 わずか 74行のプログラム。 まず SensorManager#getSensorList メソッドで、 PROXIMITY タイプのセンサを取得し (sensor)、

	sensorManager = (SensorManager)getSystemService(SENSOR_SERVICE);
	List<Sensor> sensors
	    = sensorManager.getSensorList(Sensor.TYPE_PROXIMITY);
	Sensor sensor = sensors.get(0);

この sensor の値が変化したときなどにセンサの値を受け取るリスナ (SensorEventListener) を、 SensorManager#registerListener メソッドで登録するだけ。

public class Proximity implements SensorEventListener {
	...
	sensorManager.registerListener(this, sensor,
				       SensorManager.SENSOR_DELAY_NORMAL);
	...
    @Override
    public void onSensorChanged(SensorEvent event) {
	view.update(event.values);
    }

    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
}

近接センサの値が変化するとリスナの onSensorChanged メソッドが呼び出されるので、 新しいセンサ値を描画する (view.update):

	void update(float[] values) {
	    Canvas canvas = getHolder().lockCanvas();
	    if (canvas == null) return;
	    canvas.drawColor(Color.WHITE);
	    Paint paint = new Paint();
	    paint.setColor(Color.BLACK);
	    paint.setTextSize(40);
	    float height = paint.getTextSize();
	    for (int i = 0; i < values.length; i++) {
		canvas.drawText(" "+values[i], 0, height * (i + 1), paint);
	    }
	    getHolder().unlockCanvasAndPost(canvas);
	}

Nexus One のタッチパネル左上隅近く (黒枠部分) にセンサがあるらしく、 パネルまで 2cm ほどの距離に物体を近づけると反応する (センサの値が 9.0 から 0.0 へ変化する)。 また、 パネルと並行に物体を動かす場合、 センサの真上から 1cm ほど外れると反応しなくなる。

←

鈴を近づけたことにより、 近接センサが反応して、 値が 0.0 になっている

赤外線型の近接センサ (赤外線を照射し、近接する物体からの反射光を測定するセンサ) なので、 凸面の物体など赤外線があさっての方向へ反射してしまって受光素子に正しく届かない場合や、 あるいは黒色の物体などあまり反射しない場合などでは、 より近づけないと反応しない。

例えば、 黒く細い丸棒などだと 1cm 以下に近づけないと反応しない。 逆に白い紙 (凹面〜平面) など、 効果的に赤外線を反射し、かつ受光素子に反射光が効率的に届くケースだと、 2cm より遠くても (8cm くらいでも) 反応する。

ちなみに、 Nexus One に搭載されている近接センサは、 Capella Microsystems の CM3602 という、 環境光センサ付短距離近接センサ (Short Distance Proximity Sensor with Ambient Light Sensor) であるようだ。 名前の通り環境光も測定できる。 おそらく近接センサの受光素子をそのまま使って照度を測定しているのだろう。

前述したプログラムにおいて、 「Sensor.TYPE_PROXIMITY」 を 「Sensor.TYPE_LIGHT」 に置き換えれば、 環境光センサの値を読み取ることができる。

Android SDK において、 Eclipse を使わずにアプリを開発する方法を説明しているページが少ないので、 蛇足ながらビルド〜インストール方法を書いてみる。 まず android コマンド (Android SDK の tools ディレクトリにある) を使って Project ディレクトリを作る:

T:\src\android>android create project --target 1 --path Proximity --activity Proximity --package org.gcd.test
Created project directory: T:\src\android\Proximity
Created directory T:\src\android\Proximity\src\org\gcd\test
Added file T:\src\android\Proximity\src\org\gcd\test\Proximity.java
Created directory T:\src\android\Proximity\res
Created directory T:\src\android\Proximity\bin
Created directory T:\src\android\Proximity\libs
Created directory T:\src\android\Proximity\res\values
Added file T:\src\android\Proximity\res\values\strings.xml
Created directory T:\src\android\Proximity\res\layout
Added file T:\src\android\Proximity\res\layout\main.xml
Created directory T:\src\android\Proximity\res\drawable-hdpi
Created directory T:\src\android\Proximity\res\drawable-mdpi
Created directory T:\src\android\Proximity\res\drawable-ldpi
Added file T:\src\android\Proximity\AndroidManifest.xml
Added file T:\src\android\Proximity\build.xml

T:\src\android>

「--target <target_ID>」 オプションは、 利用する Android platform library を指定する。 <target_ID> の一覧は、 「android list targets」 を実行することで得られる。

「--activity <activity_name>」 オプションは、 アプリを起動したとき最初に表示される画面のクラス名を指定する。

作った Project ディレクトリ T:\src\android\Proximity の中に、 T:\src\android\Proximity\src\org\gcd\test\Proximity.java があるので、 これを書き換える。 私の場合、 T: ドライブは Linux マシン (正確に言えば coLinux) のファイルシステムなので、 Linux 上の emacs を使って書き換えている。

あとは ant コマンドを使ってビルドするだけ。 Eclipse などの IDE (統合開発環境) を使う必要性を全く感じないのだが...

T:\src\android>cd Proximity

T:\src\android\Proximity>ant debug
Buildfile: T:\src\android\Proximity\build.xml
    [setup] Android SDK Tools Revision 6
    [setup] Project Target: Google APIs
    [setup] Vendor: Google Inc.
    [setup] Platform Version: 2.1-update1
    [setup] API level: 7
    [setup] WARNING: No minSdkVersion value set. Application will install on all Android versions.
    [setup] Importing rules file: platforms\android-7\ant\ant_rules_r2.xml

-compile-tested-if-test:

-dirs:
     [echo] Creating output directories if needed...
    [mkdir] Created dir: T:\src\android\Proximity\gen
    [mkdir] Created dir: T:\src\android\Proximity\bin\classes

-resource-src:
     [echo] Generating R.java / Manifest.java from the resources...

-aidl:
     [echo] Compiling aidl files into Java classes...

compile:
    [javac] C:\android-sdk-windows\platforms\android-7\ant\ant_rules_r2.xml:255: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Warning: org\gcd\test\R.java modified in the future.
    [javac] Compiling 2 source files to T:\src\android\Proximity\bin\classes

-dex:
     [echo] Converting compiled files and external libraries into T:\src\android\Proximity\bin\classes.dex...

-package-resources:
     [echo] Packaging resources
 [aaptexec] Creating full resource package...

-package-debug-sign:
[apkbuilder] Creating Proximity-debug-unaligned.apk and signing it with a debug key...
[apkbuilder] Using keystore: C:\Documents and Settings\sengoku\.android\debug.keystore

debug:
     [echo] Running zip align on final apk...
     [echo] Debug Package: T:\src\android\Proximity\bin\Proximity-debug.apk

BUILD SUCCESSFUL
Total time: 6 seconds
T:\src\android\Proximity>

T:\src\android\Proximity\bin\Proximity-debug.apk に apk ファイル (Android Package) ができるので、 adb コマンド (これも Android SDK の tools ディレクトリにある) を使って Nexus One へインストールする。

T:\src\android\Proximity>adb install bin\Proximity-debug.apk
296 KB/s (14596 bytes in 0.048s)
        pkg: /data/local/tmp/Proximity-debug.apk
Success

T:\src\android\Proximity>

あるいは、 T:\src\android\Proximity\bin\Proximity-debug.apk を Web サーバ上に置いて、 Internet 経由でダウンロード & インストールしてもよい (アプリケーションの設定にて、 「提供元不明のアプリ」 のインストールの許可が必要)。

以上、 Windows のコマンドプロンプトでの実行例を示したが、 もちろん Linux 上でも全く同様にビルド〜インストールが可能。

ちなみに私は、 1999年に WorkPad 30J を使い始めて以来、 プライベートなデータを PDA / スマートフォンに集積してきた。 今まで使ってきた PDA / スマートフォンをまとめてみる:

WorkPad 30J から HYBRID W-ZERO3 に至るまで、 全て PC とのデータ同期が基本だったし、 それぞれデータ移行ツールが用意されていたので移行は容易だった。 ところが Nexus One で同じような同期を行なうには、 データを PC ではなく Google Calendar へ置かなければならない。

もちろん、 Google Calendar は共有設定さえ行なわなければ他人に読まれることはないだろうし、 「don't be evil」 と言ってるくらいだから、 Google が勝手にユーザのデータを活用する可能性も無い (と信じたい)。

だからといって、 個人的なデータや会社の超機密事項 (議事メモにはそういった情報も含まれる) も洗いざらい Google に預けてしまう、 なんてことは小心な私にはとてもできない。 よく知られているように Google Calendar は 「限定公開 URL」 が漏れるだけで一巻の終わりであるわけで、 漏れることを前提でリスク評価すべき。

というわけで、 議事メモや日記を Google Calendar に置くことはハナからあきらめて、 Google Calendar には直近の予定だけを置くことにした。 万一漏れても、向こう一週間くらいの予定だけであれば、 致命的というほどでもない。

ところが驚いたことに Google Calendar には過去の予定を一括削除する機能がない。 手作業でいちいち消していかない限り、 データは残り続けるようだ。 当たり障りのない 「予定」 でも積み重なればいろいろ見えてくることがあるわけで、 長年にわたって溜った予定データは脅威となりうる。

どうしてこんな超基本機能が無いのだろうと思いつつ google で検索してみると、 見つかるのは 「どうやったら過去のデータを (一括) 消去できるのか？」 という質問のページばかり。 過去データを削除したい、 というニーズは確実にありそうなのに、 なぜ Google は実装しようとしないのか？ そういえば gmail も過去のメールを溜め続けるのが基本だし、 Google Calendar に自動的に削除する機能がないのは意図的なのかもしれない。

無い機能は作ってしまえと、 Google Calendar API のドキュメントを眺めてみる。 API を叩くためのクライアントライブラリが用意されているようだ。 が、.NET とか Java とか Python とか PHP とか、 あまり気の進まない (^^;) 言語ばかりが並んでいる。 Perl は無いのかっと思って CPAN を検索したら、 Net::Google::Calendar があっさり見つかった。

マニュアル片手にテストプログラムを書いてみる:

use Net::Google::Calendar;
use DateTime;
my $cal = Net::Google::Calendar->new;
$cal->login('sengoku@gmail.com', 'xxxxxxxx');
for my $event ($cal->get_events('start-max' => DateTime->now
				- DateTime::Duration->new(days => 7))) {
    $cal->delete_entry($event);
}

たったこれだけ。 最初に login($user, $pass) して、 get_events(%opts) で「予定」データを取り出して、 delete_entry($event) で削除。 get_events の引数で、 開始時刻が一週間以上過去の予定のみ取り出すよう指定している。

ちょっと書き足して、 ユーザID やパスワードを設定ファイルで設定できるようにしたスクリプト gcal_remove を作ってみた。

% gcal_remove -c /path/to/config.yaml -d 7

などと実行すると、 7日間以上前の予定を削除する。

設定ファイル config.yaml は以下のような感じ:

google_user: sengoku@gmail.com
google_passwd: xxxxxxxx

• サイボウズオフィス6のカレンダーをiCalendar形式に変換するスクリプト。
• サイボウズofffice8と同期するツール暫定版

あいにく職場のサイボウズはオフィス8 なので、 オフィス8 に未対応の前者は使えない。 後者はオフィス8 用だが、 「暫定版」 と書いてある通りいろいろバグがある。 さくっと修正してみて一応それっぽく動かすことはできたのだが、 使い続けていくとなると一から書き直したほうがいいような気がしてきた (わたし的にはこの手のものを PHP スクリプトでは書きたくない) ので、 perl で書き直してみた。

この perl スクリプト cybozu8_ical を、

% cybozu8_ical --conf /path/to/config.yaml

などと実行すると、 オフィス8 の 「月予定」 (月間スケジュール) ページをアクセスして、 iCalendar 形式に変換する。 向こう一週間以内の予定については 「予定の詳細」 ページもアクセスして、 「メモ」 および 「設備」 も取得する。 「月予定」 の全ての予定について 「予定の詳細」をアクセスすると、 オフィス8 サーバに負荷をかけすぎる懸念があったので、 このような仕様にしてみた。

設定ファイル config.yaml は以下のような感じ:

cybozu_url: http://intra.klab.org/cgi-bin/klcb/ag.cgi
calname: cybozu
userid: 73
password: xxxxxxxx
time_zone: Asia/Tokyo
input_encoding: shiftjis
output_file: /home/sengoku/tmp/cybozu.ics

「cybozu_url」 はオフィス8 の URL を指定する (もちろん intra.klab.org は KLab 社内LAN からしかアクセスできない)。 「userid」 と 「password」 はスケジュールを取得したいユーザの ID とパスワード。 「output_file」 に指定したファイルへ iCalendar 形式のスケジュールを出力する。 「output_file」 を省略すると標準出力へ書き出す。

なお 「--conf /path/to/config.yaml」 オプションを省略すると、 cybozu8_ical と同じディレクトリにある config.yaml が読み込まれる。

cybozu8_ical で生成した iCalendar 形式のファイルは、 とりあえず Google カレンダー および Thunderbird + Lightning で読み込めることは確認したが、 なにぶんまだ RFC 2445 を真面目に読んでいないので、 不具合などあったらご指摘頂けると有難い。

私はオフィス8 の API を知らないので、 「月予定」 「予定の詳細」 のページを取得してきて scrape しているだけ。 「繰り返し予定」 は個々の予定として扱っている。 iCalendar の UID (各予定固有のID) が同じままだと 2個目以降の予定が無視されてしまうので、 UID の末尾に通し番号をつけて互いに区別できるようにしている。

サイボウズのスケジュールは 「場所」 を登録できない。 その代わり 「施設」 として会議室を登録する。 ところが私の職場の場合 「施設」 には会議室だけでなく 「ビデオ会議システム」 などもあったりするので、 「施設」 に登録されているデータをそのまま iCalendar の LOCATION として使うわけにもいかない。 そこで 「施設」 に会議室の名称が登録されている場合のみ、 その会議室名を LOCATION として出力するようにしている。

iCalendar の LOCATION として出力すべき会議室名の一覧を、 cybozu8_ical スクリプトの始めの方で、

my @facility = (
	'20F 大会議室1', '20F 大会議室2', '20F 大会議室3',
	'20F 中会議室1', '20F 中会議室2',
	'20F 小会議室1', '20F 小会議室2',
	'20F 和室', '22F 社長室前MTGｽﾍﾟ-ｽ'
);

などと定義している。 ここに列挙されていない会議室等は 「施設」 に登録されていても単に無視される。

gcd.jp のマスタネームサーバである ns.gcd.jp と、 スレーヴネームサーバである ns2.gcd.jp (海外サーバ fremont.gcd.org の別名。 名前の通りカルフォルニア州フリーモントにある) とは、 MySQL のレプリケーションによってゾーンデータを同期させている。 したがってマスタ側での変更が即座にスレーヴ側に伝わる。

ちなみに、 ネームサーバ間の同期でよく利用されるゾーン転送 (AXFR) は、 ゾーンデータを丸ごと転送するので (ゾーンが大きくなってくると) 同期頻度を高くすることが難しく、 ダイナミックDNSサービスにはあまり向いていない。 MySQL のレプリケーションでネームサーバ間の同期が行なえてしまう MyDNS は、 ダイナミックDNSサービス向きと言える。

ところが gcd.org では (ダイナミックではない) 普通のネームサーバ ns1.gcd.org も運用していて、 これは tinydns を利用している。 せっかく海外にサーバ fremont.gcd.org を借りたのだから、 tinydns で管理しているゾーンも fremont.gcd.org で引けるようにしたいが、 fremont に複数 IP アドレスを付与するのはお金がかかる (月額 $1 追加) ので、 fremont で MyDNS と tinydns の両方を走らせるわけにもいかない。

私が借りてるレンタルサーバ (正確に言うと VPS) Linode は、 もともと DNS サービス (マスタ/スレーヴどちらでも、ドメインいくつでも) を無料で利用できるので、 DNS のためだけに 1IP 追加する気にはちょっとなれない。

もちろん、 tinydns を止めてしまって全てのゾーンを MyDNS へ移行してしまうという解決策も無くはないのだが、 MyDNS に全面的に依存してしまうのは恐い気もする。 できれば tinydns 側はいじらずに、 tinydns のゾーンデータを MyDNS 側へ反映させる仕掛けを作りたい。

というわけで、 tinydns のゾーンデータを読み込み、 MyDNS のゾーンデータの形式で MySQL へレコードを書込む perl スクリプト tinydns2mydns を書いてみた (CVSリポジトリ)。

なお MyDNS には、 mydnsimport という外部からゾーンデータを取り込むツールが付属していて、 tinydns のゾーンデータもインポートできるのだが、 以下の欠陥があってゾーン転送目的には使えない:

1. ゾーンの全レコードをいったん削除した上でインポートを行なう実装になっている。
2. SRV レコードをインポートできない。

1. tinydns 側で新しいレコードを追加したとき、 対応するレコードのみを DB に INSERT できる実装になっているかと思いきや、 ソースを確認してみると、 いったん全部 DELETE した後 tinydns のゾーンデータを 1レコードずつ INSERT する実装になっていた。

つまり、 短い時間とはいえ、 ゾーンにレコードが存在しないタイミングが存在する。 したがって、 その瞬間に届いたクエリに対して非存在 (NXDOMAIN) を回答してしまう。 mydnsimport のソースをいじって、 DELETE してから INSERT 完了まで読み込みをロックするようにすれば、 NXDOMAIN を返すこと自体は回避可能だが、 ネームサーバとしての性能を大いに損ねてしまう。

2. tinydns には A, AAAA, NS, CNAME, PTR, MX, TXT 以外の任意のタイプのレコードを定義する方法として、 タイプを数値で指定する汎用記法がある:

:fqdn:n:rdata:ttl:timestamp:lo

Generic record for fqdn. tinydns-data creates a record of type n for fqdn showing rdata. n must be an integer between 1 and 65535; it must not be 2 (NS), 5 (CNAME), 6 (SOA), 12 (PTR), 15 (MX), or 252 (AXFR). The proper format of rdata depends on n. You may use octal \nnn codes to include arbitrary bytes inside rdata.

The tinydns-data program から引用

この記法を利用して、 例えば以下のように SRV レコードを定義できる。

:_jabber._tcp.jabber.jp:33:\000\012\000d\024\225\006jabber\002jp\000:300

つまり fqdn が 「_jabber._tcp.jabber.jp」、 n が 「33」 で SRV の意味。 rdata はタイプによってデータの意味が変わってくるが、 SRV の場合は次のような構造になる:

┌─┬─┬─┬─┬─┬─┬─┬─≫┬─┬─┬─┬─≫─┬─┬─┐
│優先度│ 重み │ポート│長│ホスト名│長│ドメイン名……│０│
└─┴─┴─┴─┴─┴─┴─┴─≪┴─┴─┴─┴─≪─┴─┴─┘

つまり先頭から 2バイトずつ 3つの数値 (ネットワークバイトオーダ) を表わし、 複数個の文字列 (先頭に 1バイトの文字列長) が続いて最後に 0。 前述の SRV レコードの場合であれば、 優先度は 「\000\012」 つまり 8進数で 000 012 だから 10進数だと 10 になる。 以下同様に重みが 100 で、 ポート番号が 5269 で、 続く文字列が 「jabber」 と 「jp」 でホスト名 jabber.jp を意味する。

　優先度　 重み 　ポート　ホスト名
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│00　0A│00　64│14　95│06│ｊ│ａ│ｂ│ｂ│ｅ│ｒ│02│ｊ│ｐ│00│
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
　　10　　 100　　 5269 　　　　　6 文字　　　　　　　　　2 文字

ゾーンファイルの書式で書けば次のようなレコードになる:

_jabber._tcp.jabber.jp.	300	IN	SRV	10 100 5269 jabber.jp.

つまり、 ドメイン jabber.jp における TCP/IP の jabber サービスは、 ホスト jabber.jp の 5269 番ポートにアクセスすればよい、 ということを表わす。 同じサービスを提供するホスト・ポートが複数ある場合、 優先度の数値が (アクセス可能なものの中で) 最小のものに接続することが求められる (MUST)。 同じ優先度のホスト・ポートが複数ある場合は、 重みの比率に応じてアクセスを振り分けるべき (SHOULD)。

tinydns2mydns スクリプトにおいて SRV レコードを変換する部分は次のようになっている:

    # :fqdn:n:rdata:ttl:timestamp:lo
    elsif ($top eq ':') {
	my ($fqdn, $n, $rdata, $ttl, $timestamp, $lo) = @_;
	my $domain = &get_domain($fqdn);
	next unless defined $domain;
	my $name = &get_host($fqdn, $domain);
	if ($n == 33) {
	    $rdata =~ s/\\(\d\d\d)/sprintf("%c", oct($1))/ge;
	    my ($priority, $weight, $port, @target)
		= unpack("nnn(C/a)*", $rdata);
	    &record($sth_insert, $sth_update,
		    $Zones{$domain}, $name,
		    'SRV', "$weight $port " . join(".", @target),
		    $priority, $ttl, $lo);
	}
    }

眺めるだけで処理が見えてくる見通しのよいスクリプトだと思う (自画自賛 ;)。 $n が 33 のとき SRV レコードだから 続く $rdata を読み込んで、 8進数表記 \nnn をバイトデータへ変換し、 「優先度」 「重み」 「ポート」 および複数個の文字列に分解する:

$rdata =~ s/\\(\d\d\d)/sprintf("%c", oct($1))/ge;
my ($priority, $weight, $port, @target) = unpack("nnn(C/a)*", $rdata);

C で書けば何十行にもおよぶであろうこの処理をわずか 2行で書けてしまう perl はスゴイと改めて思う。 あとは分解したデータを MyDNS のレコードの形式に組み立てるだけ:

$Zones{$domain}, $name, "$weight $port " . join(".", @target), $priority, $ttl

mydnsimport のソースが C で 2000行近くもある (MyDNS ライブラリ群のソースを除く) のに対し、 tinydns2mydns はわずか 353行で書けてしまい、 しかも上記 mydnsimport にある欠陥を解決できている。 現状では tinydns の汎用記法のうち SRV しか対応していないが、 スクリプトの見通しがよいため他タイプに対応させるのも容易だろう。

tinydns2mydns スクリプトが DB に書込んだレコードは以下のようになる:

mysql> select * from rr where name='_jabber._tcp';
+-----+------+--------------+------+---------------------+-----+-----+
| id  | zone | name         | type | data                | aux | ttl |
+-----+------+--------------+------+---------------------+-----+-----+
| 817 |   13 | _jabber._tcp | SRV  | 100 5269 jabber.jp. |  10 | 300 |
+-----+------+--------------+------+---------------------+-----+-----+
1 row in set (0.00 sec)

外部のサイトから jabber.jp の SRV レコードを問合わせてみると、 fremont も正しいレコードを返すことが確認できる:

% host -t srv _jabber._tcp.jabber.jp fremont.gcd.org
Using domain server:
Name: fremont.gcd.org
Address: 74.207.241.21#53
Aliases: 

_jabber._tcp.jabber.jp has SRV record 10 100 5269 jabber.jp.

% host -t srv _jabber._tcp.jabber.jp
_jabber._tcp.jabber.jp has SRV record 10 100 5269 jabber.jp.

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

と書いてある。 すなわち 32bit 整数として UINT4 型を定義している。 x86_64 Linux を始め多くの 64bit Unix は LP64 すなわち long int (とポインタ) が 64bit な整数データモデルを採用している。 したがって UINT4 型の定義が 「unsigned long int」 のままで、 この MD5 リファレンス実装を使ってしまうと、 32bit であるべき UINT4 型が 64bit になってしまい、 間違ったハッシュ値を算出してしまう。

16bit CPU が主流だった大昔なら 「int が 16bit なデータモデルを採用している環境」 が多かったのかもしれないが、 RFC 1321 が出た 1992年ごろは既に 32bit CPU が主流だったわけで、 UINT4 型を 「int」 と定義しておいてくれてもよかったのにと思う。 そうすれば、 「long が 64bit なデータモデルを採用している環境」 が多くなる昨今でも (int は 32bit のままなので) 問題を起こさずに済んだだろうに。

試しにテストプログラムを書いてみる:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include "global.h"
#include "md5.h"
#define DIGEST_LEN 16
#define BUFFER_LEN 256

int main(int argc, char *argv[]) {
    MD5_CTX context;
    unsigned char digest[DIGEST_LEN];
    unsigned char buf[BUFFER_LEN];
    int i;
    MD5Init(&context);
    while ((i=read(0, buf, BUFFER_LEN)) > 0) MD5Update(&context, buf, i);
    MD5Final(digest, &context);
    for (i=0; i < DIGEST_LEN; i++) printf("%02x", digest[i]);
    printf("\n");
    return 0;
}

32bit 環境 (i686 Linux) では正しく動く:

senri:/home/sengoku/src/md5 % uname -m
i686
senri:/home/sengoku/src/md5 % ls
global.h  main.c  md5.h  md5c.c
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
a7966bf58e23583c9a5a4059383ff850
senri:/home/sengoku/src/md5 % echo "Hello, world" | openssl md5
a7966bf58e23583c9a5a4059383ff850

ところが、 64bit 環境 (x86_64 Linux) だと:

senri:/home/sengoku/src/md5 % uname -m
x86_64
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
fd578222c6a471623ea1e3eb2b6e6f6b

などと、 誤った MD5 の値が出力されてしまう。

MD5 の値を求めること自体が目的であれば、 誤ったハッシュ値が出力されればすぐ気付くのでいいのだが、 値そのものが目的であることは (当然ながら) あまりなくて、 普通はアプリケーションの中で MD5 を利用するので、 32bit 環境で使っていたアプリケーションを 64bit 環境でコンパイルし直して使おうとするとハマる。

私は qmapop-0.3 (Bert Gijsbers 氏が開発した、qmail 用 APOP 認証パッケージ。 とうの昔に obsolete になってる ^^;) を x86_64 Linux でコンパイルし直したら APOP 認証が通らなくなってしまって焦った。

なにぶん古いプログラム (1995年5月リリース) に いろいろ手を加えて使っていたので、 APOP 認証が失敗するのは必要なパッチをあてていないためだろうと思ってしまった。 しかし最後にコンパイルしたのは何年も前 (2002年4月) なので、 どんな修正を行ったか思い出せない。

仕方ないのでソースをながめて原因を探る羽目になり、 動作させつつ処理を追っていたら、 何のことはない単に算出した MD5 の値が誤ってるだけということに気付き、 (qmapop-0.3 が使ってた) MD5 リファレンス実装がデータモデルに依存していることを見つけた次第。

C99 で stdint.h が定義されて、 整数データモデルに依存しない、 移植性の高い書き方が可能になった。 以下のように global.h を修正すればよい:

senri:/home/sengoku/src/md5 % diff -ub global.h~ global.h
--- global.h~	1993-05-14 02:15:17.000000000 +0900
+++ global.h	2010-02-27 23:49:36.553633806 +0900
@@ -13,11 +13,13 @@
 /* POINTER defines a generic pointer type */
 typedef unsigned char *POINTER;
 
+#include <stdint.h>
+
 /* UINT2 defines a two byte word */
-typedef unsigned short int UINT2;
+typedef uint16_t UINT2;
 
 /* UINT4 defines a four byte word */
-typedef unsigned long int UINT4;
+typedef uint32_t UINT4;
 
 /* PROTO_LIST is defined depending on how PROTOTYPES is defined above.
 If using PROTOTYPES, then PROTO_LIST returns the list, otherwise it

統合といっても両ブログは微妙(?)に読者層が異なると思われるし、 何よりページの体裁が大きく変わってしまっては読者の方々を戸惑わせてしまうので、 CTO日記を 「仙石浩明の日記」 の一カテゴリという位置付けにして、 かつページの体裁は WordPress のテーマを切り替えることによって、 どちらのブログもあまり大きな変化がないようにしている。

「仙石浩明CTO の日記」 http://sengoku.blog.klab.org/ をアクセスすると、 次のような PHP スクリプトを走らせた上で、 WordPress を呼び出す (末尾の require 文):

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/category/cto/";
} elseif ($_SERVER['REQUEST_URI'] == "/feed/") {
    $new = "/blog/category/cto/feed/";
} elseif (preg_match('@^/\d+/\d+/\d+/@',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $new = $_SERVER['REQUEST_URI'];
...(中略)...
}
if ($new) {
    ...(中略)...
    $ORIG_SERVER_NAME = $_SERVER['SERVER_NAME'];
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    $abspath = "/usr/local/www/wordpress/";
    $themepath = "${abspath}wp-content/themes/sengoku_cto/";
    define('WP_USE_THEMES', true);
    define('TEMPLATEPATH', $themepath);
    define('STYLESHEETPATH', $themepath);
    require("${abspath}wp-blog-header.php");
...(中略)...
}
?>

つまり http://sengoku.blog.klab.org/ へのアクセスは、 パス名に 「/category/cto/」 を追加することによって、 CTO日記カテゴリへのアクセスに変換する。

ページの体裁については、 「wp-content/themes/sengoku_cto/」 ディレクトリが、 CTO日記のテーマフォルダで、 二つの PHP 定数 TEMPLATEPATH と STYLESHEETPATH をこのディレクトリへ設定することによって、 テーマの切り替えを行なっている。

テーマフォルダの中にあるテーマ関数ファイル 「functions.php」 は、 WordPress の初期化中に読み込まれるので、 ここに PHP スクリプトを書いておくことによって WordPress の挙動を変更することができる。 例えばブログのタイトルを 「仙石浩明CTO の日記」 に変更するには、 以下のスクリプトを functions.php に追加しておけばよい:

function option_blogname_cto() {
    return '仙石浩明CTO の日記';
}
add_filter('pre_option_blogname', 'option_blogname_cto');

つまり、 pre_option_blogname フックに、 option_blogname_cto フィルタを登録する。

WordPress では、 ブログのタイトルなど各種オプションの設定値 (DB に格納している) を、 get_option($setting) 関数を呼び出すことで参照している。 例えばタイトルは get_option('blogname') を呼び出すことで得られ、 URL は get_option('home') で得られる。

get_option($setting) 関数は wp-includes/functions.php で定義されていて、 以下のようにフィルタフック pre_option_* が定義されている:

function get_option( $setting, $default = false ) {
    global $wpdb;

    // Allow plugins to short-circuit options.
    $pre = apply_filters('pre_option_' . $setting, false);
    if ( false !== $pre )
	return $pre;
    ...(中略)...
}

つまり、 「pre_option_設定名」 というフックに登録されたフィルタが値を返すなら、 get_option はオプションの設定値ではなくフィルタが返した値を返すようになる。 前述の例なら、 「pre_option_blogname」 フックに登録された 「option_blogname_cto」 フィルタが 「仙石浩明CTO の日記」 という値を返すので、 get_option('blogname') も 「仙石浩明CTO の日記」 という値を返すようになり、 結果としてブログのタイトルを変更できる、というわけ。

ただし、 前述したように CTO日記は 「仙石浩明の日記」 の一カテゴリという位置付けなので、 ブログのタイトルを変更しただけだと、 ブログ 「仙石浩明CTO の日記」 の 「仙石浩明CTO の日記」 カテゴリということで、 ページのタイトル等が 「仙石浩明CTO の日記 » 仙石浩明CTO の日記」 という冗長なものになってしまう。 そこで、 以下のようなスクリプトを 「functions.php」 に追加して、 タイトルとカテゴリ名が同じときはカテゴリ名が表示されないようにする:

function single_cat_title_cto($category_name) {
    $name = get_option('blogname');
    if ($category_name == $name) return "";
    return $category_name;
}
add_filter('single_cat_title', 'single_cat_title_cto');

single_cat_title フックは、 wp-includes/general-template.php で定義されていて、 ページのタイトルなどに表示されるカテゴリ名を変更することができる。

以上で、 「仙石浩明の日記」 の一カテゴリを 「仙石浩明CTO の日記」 の体裁で見せることができるようになる。 しかし、 元が 「仙石浩明の日記」 であるだけに、 リンク先が全て 「仙石浩明の日記」 のページになってしまう。 例えば、 「仙石浩明CTO の日記」 のトップページの一番下に、 「古い投稿 »」 というリンクがあるが、 このリンク先が http://www.gcd.org/blog/page/2/ になってしまい、 たどると 「仙石浩明の日記」 のトップページの 2ページ目へ遷移してしまう。

また、 本文中 (あるいはサイドバー) に現れるリンクも、 DB のデータは 「仙石浩明の日記」 のパーマリンクを用いているので、 たとえそれが 「仙石浩明CTO の日記」 カテゴリに含まれていても、 そのリンクをたどると 「仙石浩明の日記」 の記事として表示されてしまう。

そこで、 遷移先も 「仙石浩明CTO の日記」 として表示したいリンクを、 フィルタで書き換えることにした。 つまり DB のデータは 「仙石浩明の日記」 へのリンクのままで、 ブラウザに送信する前に都度書き換える。

対象となるリンクは、 記事本文中だけでなく、 前述したページナビ 「古い投稿」 「新しい投稿」 や、 サイドバー (「人気記事」 や 「最近の投稿」) にも現れる。 ページ丸ごと (つまり HTTP レスポンス丸ごと) HTML を書き換えられるフックがあるとよかったのだが、 残念ながらそういうフックは定義されていないようだ。 以下のフックそれぞれについてリンクを書き換えればよさげ:

書き換え対象のリンクを決めるために、 まず CTO日記カテゴリに属す記事の ID を取得する:

function setup_cto_id() {
    global $wpdb;
    global $is_cto_id;
    $result = $wpdb->get_results("SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id=17", ARRAY_N);
    foreach ($result as $row) {
	$is_cto_id[$row[0]] = 1;
    }
}

あるカテゴリに属す記事ID のデータを取得する関数など、 WordPress に含まれているんじゃないかと探してみたのだが、 見つからなかったので DB に問合わせて取得するようにしてみた。 毎回 DB アクセスが発生してしまうが、 キャッシュとかはアクセス数が増えてから考える (^^;)。 「term_taxonomy_id=17」 が CTO日記のカテゴリ (決め打ち ^^;)。 CTO日記カテゴリに属す記事は、 配列 $is_cto_id[記事ID] に 1 を代入しておく。

次に URL を書き換えるスクリプト:

function replace_URL_cto($matches) {
    global $is_cto_id;
    global $ORIG_SERVER_NAME;
    if (!is_array($is_cto_id)) {
	setup_cto_id();
    }
    if (is_null($matches[2])) {
	if ($matches[1] == "category/cto/") return "http://$ORIG_SERVER_NAME/";
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    } elseif ($is_cto_id[$matches[2]]) {
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    }
    return $matches[0];
}

function convert_URLs_cto($text) {
    $textarr = preg_split("/(<.*>)/U", $text, -1, PREG_SPLIT_DELIM_CAPTURE);
    $stop = count($textarr);
    for ($i = 0; $i < $stop; $i++) {
	$content = $textarr[$i];
	if (strlen($content) > 0) {
	    $content = preg_replace_callback(
		    '@http://www.gcd.org/blog/(\d+/\d+/(\d+)|category/cto/)@',
		    'replace_URL_cto', $content);
	}
	$output .= $content;
    }
    return $output;
}

顔文字を画像に変換して表示するフィルタ wptexturize (wp-includes/formatting.php で定義されている) を参考にさせてもらった。 preg_replace_callback() を使って書き換え対象リンクを探し、 replace_URL_cto で記事ID がCTO日記カテゴリに属す ($is_cto_id[$matches[2]] が TRUE) 場合のみ書き換える。

最後に、 この書き換えフィルタ replace_URL_cto を前述したフィルタフックに追加:

add_filter('the_content', 'convert_URLs_cto');
add_filter('the_category', 'convert_URLs_cto');
add_filter('get_pagenum_link', 'convert_URLs_cto');
add_filter('post_link', 'convert_URLs_cto');
add_filter('widget_text', 'convert_URLs_cto');
add_filter('wp_list_categories', 'convert_URLs_cto', 12000);
add_filter('category_feed_link', 'convert_URLs_cto');

wp_list_categories にフィルタを追加すると Category Order プラグインと衝突するので、 優先順位を下げて Category Order プラグインの後で実行されるようにしている。

また、 the_category, post_link, widget_text, category_feed_link 各フックは、 2つ以上の引数を持つが、 第1引数 (書き換え対象の HTML あるいは URL) のみ使用するので引数の数 (add_filter の第3引数) を省略している。

もちろん、 準仮想化であるから標準的なカーネルをそのまま走らせることはできず、 パッチをあてる必要がある。 残念ながら最新カーネル用のパッチはまだ作られていないようで、 現時点では Linux kernel 2.6.26.8 用のパッチが最新。

私は自分で管理している Linux マシン (自宅と職場合わせて 10台以上ある) は、 この coLinux なマシンも含めてハードディスク (正確に言えば Linux のパーティション) の内容を同一にしている。 すなわち、 マスタマシン (senri.gcd.org) の内容を定期/不定期的に rsync を使って各マシンへ同期させている。 マスタマシンのカーネルは Linux 2.6.31.6 なので、 マスタでビルドしたソフトウェアの中には、 Linux 2.6.26.8 ベースである coLinux 環境で動かないものも当然でてくる。

先日 apache httpd 2.2.14 を (マスタマシンで) ビルドしたら、 coLinux 環境で動かなかった:

# uname -a
Linux ikeda.gcd.org 2.6.26.8-co-0.8.0 #1 PREEMPT Sat Nov 14 19:23:55 JST 2009 i686 GNU/Linux
# /usr/apache2/bin/httpd -t
[Sun Nov 29 17:13:41 2009] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null)
Syntax error on line 32 of /usr/apache2/conf/httpd.conf:
Listen setup failed

「Syntax error on line 32」 ということだが httpd.conf の 32行目は、

Listen 80

となっているので、 少なくとも 「Syntax error」 ではないことは明らか。 「Listen 80」 の代りに 「Listen localhost:80」 などと書けば、 「failed to get a socket for (null)」 というエラーメッセージが 「failed to get a socket for localhost」 に変わる。

このエラーメッセージを手がかりに apache httpd 2.2.14 のソースを探すと、 エラーを出しているのは server/listen.c の以下の部分:

        status = apr_socket_create(&new->sd, new->bind_addr->family,
                                    SOCK_STREAM, 0, process->pool);
	...
        if (status != APR_SUCCESS) {
            ap_log_perror(APLOG_MARK, APLOG_CRIT, status, process->pool,
                          "alloc_listener: failed to get a socket for %s",
                          addr);
            return "Listen setup failed";
        }

つまり apr_socket_create 関数でソケットを生成しようとしてエラーが起きている。 APR つまり Apache Portable Runtime の中でのエラー。 真面目に APR のソースを追ってもいいのだが、 エラーメッセージに 22 (= EINVAL) と出ていることから socket(2) システムコールが EINVAL (Unknown protocol, or protocol family not available) エラーを返しているのだろうとあたりをつけて、 strace コマンドを使って手っ取り早く確認してみた:

# strace /usr/apache2/bin/httpd -t
execve("/usr/apache2/bin/httpd", ["/usr/apache2/bin/httpd", "-t"], [/* 28 vars */]) = 0
brk(0)                                  = 0x80a6000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/usr/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=66428, ...}) = 0
old_mmap(NULL, 66428, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ffe000
close(3)                                = 0
open("/usr/lib/libm.so.6", O_RDONLY)  = 3
	...
socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_IP) = -1 EINVAL (Invalid argument)
	...

確かに socket(2) が EINVAL を返している。 socket の第1, 3 引数はエラーになりようがないので、 第2 引数 「0x80001」 が原因だろう。 この値は、 「SOCK_STREAM | SOCK_CLOEXEC」 という意味なので、 Linux 2.6.26.8 の socket(2) が 「SOCK_CLOEXEC」 フラグをサポートしていないのだろうと推測できる。 実際、 カーネルのソースを確認してみると SOCK_CLOEXEC をサポートしているのは Linux 2.6.27 以降だった。

CLOEXEC というのは close-on-exec の意味。 ファイルディスクリプタには FD_CLOEXEC フラグを設定できて、 このフラグが立っているファイルディスクリプタは、 exec を行なうと自動的にクローズされる。 fcntl(2) でこのフラグの設定/解除ができるが、 SOCK_CLOEXEC を付けて socket(2) を呼び出すと、 ソケットをオープンすると同時に FD_CLOEXEC フラグを設定できる。 open(2) でも同様に O_CLOEXEC を付けることができる (Linux 2.6.23 以降)。

open() システムコールと fcntl(FD_CLOEXEC) とが、 2つの手順に分離されていることが問題だといいます。 もし 「open」 と 「fcntl」 という 2つの処理のすき間で、 別スレッド、またはシグナルハンドラから fork が呼ばれると、 ファイルディスクリプタが閉じられずにリークしてしまいます。 もし、 exec したプログラムに脆弱性が含まれていた場合、 親プロセスがオープンしていたファイルまでもが危険にさらされることになります。
...(中略)...
Linux においては、 open 以外にも新規ファイルディスクリプタを作成して返却するシステムコールは大量にあります。 そのすべてにおいて、 フラグ引数に 「XX_CLOEXEC フラグ」 を追加する、 またはフラグ引数を追加した新システムコールを新設するという修正が行われました。

ファイルディスクリプタリークを防げ！ から引用

というわけでエラーの原因は分かったが、 どうやって対策したものか。 coLinux が 2.6.27 以降をサポートするのはまだ先のことになりそうだし、 かといって SOCK_CLOEXEC 付で socket(2) がエラーを返さないようにする小手先パッチを作るのは、 他の全てのプログラムに影響するのであまりよろしくない (実は SOCK_CLOEXEC が付いていてもエラーにしないパッチも作ってみたのだが、 APR は他にも Linux 2.6.31.6 ではサポートされているが Linux 2.6.26.8 ではサポートされていない機能を使ってるらしく、 httpd の子プロセスがゾンビになってしまった)。

というわけで、 Linux 2.6.26.8 (つまり coLinux 環境) 下で APR ライブラリをビルドし直し、 得られた libapr-1.so を /usr/lib/colinux ディレクトリに入れておいて、 coLinux 環境ではこのディレクトリを LD_LIBRARY_PATH を指定して apache httpd を実行することにした。

ikeda:/usr/local/src/apr-1.3.9 % ./configure
	...
checking for epoll_create1 support... no
checking for dup3 support... no
checking for accept4 support... no
checking for SOCK_CLOEXEC support... no
	...
ikeda:/usr/local/src/apr-1.3.9 % make
ikeda:/usr/local/src/apr-1.3.9 % fg
# cp -d /usr/local/src/apr-1.3.9/.libs/*.so* /usr/lib/colinux/.
# ls -l /usr/lib/colinux
total 572
lrwxrwxrwx 1 root root     17 Dec  3 08:46 libapr-1.so -> libapr-1.so.0.3.9
lrwxrwxrwx 1 root root     17 Dec  3 08:46 libapr-1.so.0 -> libapr-1.so.0.3.9
-rwxr-xr-x 1 root root 578999 Dec  3 08:46 libapr-1.so.0.3.9
# LD_LIBRARY_PATH=/usr/lib/colinux /usr/apache2/bin/httpd

無事 coLinux 環境においても httpd サーバを実行することができた。

なお、 epoll_create1(2), dup3(2), accept4(2) は、 それぞれ epoll_create(2), dup2(2), accept(2) に int flags 引数を追加し、 close-on-exec フラグを設定できるようにした Linux 独自の拡張。 いずれも Linux 2.6.26 以前ではサポートされない。

senri:/usr/local/src/glibc-2.10.1.i386 % ../glibc-2.10.1/configure
	...
senri:/usr/local/src/glibc-2.10.1.i386 % make
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__libc_fork':
/usr/local/src/glibc-2.10.1/posix/../nptl/sysdeps/unix/sysv/linux/i386/../fork.c:79: undefined reference to `__sync_bool_compare_and_swap_4'
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__nscd_drop_map_ref':
/usr/local/src/glibc-2.10.1/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4'
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `*__GI___libc_freeres':
/usr/local/src/glibc-2.10.1/malloc/set-freeres.c:39: undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
make[1]: *** [/usr/local/src/glibc-2.10.1.i386/libc.so] Error 1
make[1]: Leaving directory `/usr/local/src/glibc-2.10.1'
make: *** [all] Error 2

__sync_bool_compare_and_swap_4 は gcc の組み込み関数なので、 関数が未定義であることを示す 「undefined reference to ...」 というエラーメッセージは、 誤解を招く不親切なメッセージだと思う。

__sync_bool_compare_and_swap_4(mem, oldval, newval) は、 mem が指し示すメモリの値 (4バイト分) が oldval であれば newval に変更する、 という操作をアトミックに行なう組み込み関数。 アトミック (不可分) 操作とは、 操作の途中が存在してはいけない操作のことで、 この例なら比較 (メモリの値が oldval か?) と代入 (newval に変更) が必ず 「いっぺん」 に行なわれ、 「比較だけ行なったけどまだ代入は行なわれていない」 という状態が存在しないことを意味する。

アトミックに行なうためには、 当然ながら CPU でその操作をサポートしている必要がある (複数個の命令の列で実現しようとすると、 命令列の半ばを実行中の状態が必ず存在してしまう) わけだが、 残念ながら Intel 386 プロセッサでは、 この compare_and_swap (CMPXCHG 命令) をサポートしておらず、 サポートするのは Intel 486 以降の CPU である。 テストプログラムを書いて試してみる:

#include <stdio.h>

int main() {
    int mem[1], oldval, newval;
    oldval=0;
    newval=1;
    mem[0] = 0;
    __sync_bool_compare_and_swap(mem, oldval, newval);
    printf("mem[0]=%d\n", mem[0]);
    return 0;
}

見ての通り、 mem[0] の値を oldval の値 (0) と比較し、 一致していたら newval の値 (1) を代入し、 mem[0] の値を表示するだけのプログラムである。

関数名が 「__sync_bool_compare_and_swap」 であって、 後ろに 「_4」 がついていないことに注意。 gcc が引数の型 (この例では int) を見て、 その型のビット長を後ろにつけてくれる (この例では int 型は 4 バイトなので 「_4」 をつけてくれる)。

gcc では 「-march=タイプ」 オプションを指定することによって CPU タイプを指定できる。 -march オプションを指定しなかったり (この場合は全 CPU でサポートされる組み込み関数のみ利用できる)、 あるいは -march=i386 を指定したりすると、 コンパイル時にエラーになる:

% gcc -Wall test.c
/tmp/cc4eNX6L.o: In function `main':
test.c:(.text+0x3b): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i386 test.c
/tmp/cc6chtFj.o: In function `main':
test.c:(.text+0x36): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i486 test.c
% ./a.out
mem[0]=1

いまさら i486 というのもアレなので、 今なら i686 を指定するのがよさげ。 私の手元にはいまだ PentiumIII マシンがあるものの、 PentiumIII より古いマシンはない (昨年 ML115 と SC440 を買ったとき PentiumII マシンを引退させた) ので、 pentium3 を指定すれば SSE (Streaming SIMD Extensions) が利用できるようになるが、 glibc をビルドするときに必要かというと、 たぶん必要ない。

というわけでエラーの原因は分かったが、 では glibc をビルドするときは、 どうすればいいだろうか？

とりあえず google で検索してみたら、 gcc の configure オプションに 「--with-arch=i686」 を指定して gcc をビルドする必要がある、 と書いてあるページが見つかった。

--with-arch オプションは、 -march のデフォルトを設定するための configure オプションである。 つまり 「--with-arch=i686」 を指定して gcc を再インストールすると、 gcc に -march オプションをつけなくてもデフォルトが i686 になる。 なるほど確かにそうすれば、 glibc 側で何も変更せずに __sync_bool_compare_and_swap_4 関数が使えるようになりそうである。

いまどき i686 以前の CPU 用のコードが必要になりそうなケースは滅多にないだろうから、 -march オプションのデフォルトを i686 にするのも悪い選択ではないように思えた。 gcc をビルドし直すのは面倒だなーと思いつつも、 ついでに gcc のバージョンを上げておこうと gcc-4.3.4 をダウンロードしてきて 「--with-arch=i686」 付でビルドしてみた。

ところが！

「--with-arch=i686」付でビルドした gcc を使って glibc をビルドしようとすると、 先ほどコンパイラエラーが出た場所より前の段階で、 アセンブラがエラーを出力して make が止まってしまった:

senri:/usr/local/src/glibc-2.10.1.i386 % make
	...
../sysdeps/i386/fpu/s_frexp.S: Assembler messages:
../sysdeps/i386/fpu/s_frexp.S:66: Error: invalid identifier for ".ifdef"
../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1'
	...
../sysdeps/i386/fpu/s_frexp.S:66: Error: ".endif" without ".if"
../sysdeps/i386/fpu/s_frexp.S:66: Error: junk `.get_pc_thunk.dx' after expression
make[2]: *** [/usr/local/src/glibc-2.10.1.i386/math/s_frexp.os] Error 1
make[2]: Leaving directory `/usr/local/src/glibc-2.10.1/math'
make[1]: *** [math/subdir_lib] Error 2
make[1]: Leaving directory `/usr/local/src/glibc-2.10.1'
make: *** [all] Error 2

こちら (コンパイラ側) を立てれば、あちら (アセンブラ側) が立たず、 な二律背反状態。

「invalid identifier for ".ifdef"」 というエラーメッセージが (ぱっと見には) 意味不明である。 続いて 「junk at end of line, first unrecognized character is `1'」 と言っているから、 「.ifdef 1」 みたいなコードなのだろうか？ エラーが起きた sysdeps/i386/fpu/s_frexp.S の 66行目あたりは以下のようになっている。 LOAD_PIC_REG の行が問題の 66行目:

	cmpl	$0x00100000, %eax
	jae	2f

	fldl	VAL0(%esp)
#ifdef	PIC
	LOAD_PIC_REG (dx)
#endif
	fmull	MO(two54)
	movl	$-54, %ecx
	fstpl	VAL0(%esp)
	fwait
	movl	VAL1(%esp), %eax
	movl	%eax, %edx
	andl	$0x7fffffff, %eax

おそらく LOAD_PIC_REG マクロを展開した結果がおかしいのだろうと、 LOAD_PIC_REG マクロの定義 (sysdeps/i386/sysdep.h) を調べてみる:

# define SETUP_PIC_REG(reg) \
  .ifndef __i686.get_pc_thunk.reg;					      \
  .section .gnu.linkonce.t.__i686.get_pc_thunk.reg,"ax",@progbits;	      \
  .globl __i686.get_pc_thunk.reg;					      \
  .hidden __i686.get_pc_thunk.reg;					      \
  .type __i686.get_pc_thunk.reg,@function;				      \
__i686.get_pc_thunk.reg:						      \
  movl (%esp), %e##reg;							      \
  ret;									      \
  .size __i686.get_pc_thunk.reg, . - __i686.get_pc_thunk.reg;		      \
  .previous;								      \
  .endif;								      \
  call __i686.get_pc_thunk.reg

# define LOAD_PIC_REG(reg) \
  SETUP_PIC_REG(reg); addl $_GLOBAL_OFFSET_TABLE_, %e##reg

プリプロセッサの出力を確認してみると、 66行目は次のようにマクロ展開されている:

 .ifndef 1 .get_pc_thunk.dx; .section .gnu.linkonce.t. 1 .get_pc_thunk.dx,"ax",@progbits; .globl 1 .get_pc_thunk.dx; .hidden 1 .get_pc_thunk.dx; .type 1 .get_pc_thunk.dx,@function; 1 .get_pc_thunk.dx: movl (%esp), %edx; ret; .size 1 .get_pc_thunk.dx, . - 1 .get_pc_thunk.dx; .previous; .endif; call 1 .get_pc_thunk.dx; addl $_GLOBAL_OFFSET_TABLE_, %edx

確かに、いきなり 「.ifndef 1」 となっているので、 エラーになるのは明らか。 上記 SETUP_PIC_REG マクロ定義内の 「__i686」 がことごとく 「1」 に展開されていて、 意味不明なコードになってしまっている。

というわけで、 原因に思い当たった。 プリプロセッサで自動的に定義されるマクロを表示させてみる:

% gcc -E -dM -x c /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __pentiumpro__ 1
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
	...
#define __i686 1
	...
#define __i686__ 1
	...

「#define __i686 1」 だから当然そういうマクロ展開が行なわれる、 というわけ。 gcc と glibc では違うソフトウェアであるとはいえ、 gcc のプリプロセッサで自動的に定義される 「#define __i686 1」 とバッティングするようなラベル 「__i686.get_pc_thunk.reg」 をマクロ中で使うというのは、 いかがなものか。＞ glibc

「--with-arch=i686」付でビルドした gcc, あるいは 「-march=i686」 オプション付で実行した gcc は、 -march を指定しない gcc と比べて、 プリプロセッサにおいて以下の定義が追加されるようだ:

#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __i686 1
#define __i686__ 1
#define __pentiumpro 1
#define __pentiumpro__ 1

ちなみに、 SETUP_PIC_REG マクロ定義内で定義されている __i686.get_pc_thunk.reg は、 eip の値をレジスタ reg へ代入するための関数 (というかサブルーチン)。 サブルーチン名の末尾の 「reg」 はマクロ引数で置換される。 この例では dx。 つまり SETUP_PIC_REG マクロを展開することにより __i686.get_pc_thunk.dx というサブルーチンが定義される。

そして、 このサブルーチンを呼び出す (call __i686.get_pc_thunk.dx) と、 スタックトップをレジスタへ代入 (movl (%esp), %edx) して復帰 (ret) する。 つまりプログラムカウンタ (スタックトップに積まれた戻りアドレス) の値がレジスタ edx へ代入される、というわけ。

続いて、 edx に $_GLOBAL_OFFSET_TABLE_ を加算することにより edx にグローバル変数領域へのポインタが代入される (addl $_GLOBAL_OFFSET_TABLE_, %edx)。

__i686.get_pc_thunk.bx は、 gccが用意してくれる関数で、 PC (プログラムカウンタ、EIP レジスタの値) を ebx にコピーします。
　(中略)
なんでここで PC が必要かというと、 グローバル変数にアクセスしたいからです。 PIC/PIE の場合、 実行時に自分自身 (ELF バイナリ) がどの仮想アドレスに mmap されるかはわかりませんので、 アドレス決め打ちで変数にアクセスはできません。 でも、 いま実行している命令 (61d:) から変数までのオフセットは *.o をリンクして so にした時点で判明します (so ファイルのナカミがほぼそのままメモリに貼られるわけなんで)。
　(中略)
mov 0xほげ(%eip) ふが; とか出来れば一番いいんですが(x86_64はできる)、 x86はそういうPC相対のアドレス指定はできません。 というか、eipを直接的に得ることすら出来ません。 なんで、仕方なく一度call命令を発行して、 リターンアドレス（callを発行した命令の次の命令のアドレス） をスタック上に自動push させて、 __i686.get_pc_thunk.bx内でebxレジスタにpopしてます。 x86だと、PIC/PIEなコードでグローバル変数を触るだけで、 関数呼び出しと同じようなコストがかかるんざますよ！奥様。

memologue 2006-09-07 から引用

glibc でどんなグローバル変数にアクセスしているのかと思って、 ちょっと調べてみた:

この sysdeps/i386/fpu/s_frexp.S は、 そのファイル名の通り frexp(3) のアセンブリ言語による実装。 C による実装は sysdeps/ieee754/dbl-64/s_frexp.c にある。 ディレクトリ名から分かるように、 IEEE 754 (IEEE 浮動小数点数演算標準) に基づいている。

double frexp(double x, int *exp) は、 浮動小数点実数 x を正規化小数と指数に分解し、 指数を *exp に格納した上で正規化小数を返す。 浮動小数点実数 x が非正規化数であるとき frexp は x に 2^54 を乗じた上で *exp に -54 を返すのだが、 この 2^54 = 18014398509481984 という定数を double 型で保持するために、 グローバル変数 two54 を使用している。

話が脱線したので元に戻すと、 要は 「--with-arch=i686」 付でビルドした gcc だと、 C のソースだろうとアセンブリ言語で書かれたソースだろうと見境なく 「#define __i686 1」 を定義してしまうので、 相手が C のソースの時のみ 「-march=i686」 を付けて gcc を実行すればよい。 つまり、 gcc は 「--with-arch=i686」 付でビルドしてはいけない。

ではどうすればいいか？ いろいろ方法はあると思うが、 glibc をビルドするときに CFLAGS を 「CFLAGS="-g -O2 -march=i686"」 などと指定して configure を実行するのも一つの解決策。 CFLAGS は C のソースをコンパイルするときだけ使われて、 アセンブルするときには使われないので、 前述したようなコンパイラ/アセンブラ二律背反問題を回避できる。 というわけで、 無事 glibc 2.10.1 をビルドすることができた:

senri:/usr/local/src/glibc-2.10.1.i386 % ../glibc-2.10.1/configure CFLAGS="-g -O2 -march=i686"
	...
senri:/usr/local/src/glibc-2.10.1.i386 % make
	...

EAP (社員支援プログラムではなくて、 拡張認証プロトコル) の認証方式には EAP-MD5, EAP-FAST, EAP-SKE, EAP-SRP, MS-CHAP, EAP-GTC, EAP-GTC, Cisco LEAP, EAP-TLS, EAP-TTLS, PEAP, EAP-MAKE, EAP-SIM などがあるが、 対応機器/ソフトウェアが多そうな EAP-TLS を使ってみることにした。 EAP-TLS とは、 TLS (Transport Layer Security) すなわち SSL (Secure Sockets Layer) のサーバ認証とクライアント認証を行なって、 RADIUS サーバと無線LAN 端末が相互に認証を行なう仕掛けである。

RADIUS サーバとしては、 free RADIUS 2.1.3 を使用した。 自前の認証局 でサーバ証明書とクライアント証明書を発行し、 それぞれ RADIUS サーバと無線LAN 端末 (Windows マシン) へインストールする (自分で発行する証明書だが、 認証する側が自分の管理下なので、 いわゆる「オレオレ証明書」ではない)。

まず radiusd をデバッグ モードで走らせてみる:

# radiusd -X
FreeRADIUS Version 2.1.3, for host i686-pc-linux-gnu, built on Dec  6 2008 at 17:50:58
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. 
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE. 
You may redistribute copies of FreeRADIUS under the terms of the 
GNU General Public License v2. 
Starting - reading configuration files ...
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/clients.conf
including configuration file /usr/local/etc/raddb/eap.conf
group = radius
user = radius
including dictionary file /usr/local/etc/raddb/dictionary
	...(中略)...
Listening on authentication address * port 1812
Ready to process requests.

とりあえず動いているようだ。 Windows マシンからアクセスポイントへ接続してみると、 アクセスポイントを介して Windows マシンと RADIUS サーバ間で、 TLS サーバ/クライアント認証が行なわれ、 無事 WPA2 エンタープライズ モードで接続が完了した。

では、radiusd を daemontools 配下で動かそうと、 次のような /service/radius/run スクリプトを書いて動かしてみる:

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
exec 2>&1
exec radiusd -fxxx

-x を指定して詳細なデバッグ情報を出力させるようにする。 daemontools 配下で動かす場合、 multilog プログラムがログをどんどんローテートしてくれるので、 通常運用でもデバッグ情報を出力させておける。 ログを標準出力 (stdout) へ出力させるため、 設定ファイル radiusd.conf において、 次のように指定しておく。

log {
	destination = stdout
}

これでログが /service/radius/log/main/current に書き出されるはず、 と思ったら何も出力されない... 何故に...?

radiusd(8) によれば、-X オプションは 「-sfxx -l stdout」 と等価らしい。 -s オプションは、 RADIUS サーバを単一スレッド/プロセスで走らせるための指定。 個人で使う分には単一スレッドでも構わないといえば構わないので、 ログを stdout に出力する目的で -X オプションを使ってしまっても構わないのだが、 せっかくだからともうちょっと追ってみることにした。

まず上記 run スクリプトにおいて 「-l stdout」 を指定してみる。 すると、/service/radius ディレクトリに stdout というファイルができて、 そこにログが出力された。 ダメだこりゃ。 -l オプションはマニュアルには記載されていないので、 -l に続く 「stdout」 をファイル名と見なすのも一つの「仕様」と言えなくもないが...

ソース radiusd.c を見てみると、 確かに -l オプションの処理では続く引数をファイル名としてしか扱っていない。 では設定ファイル radiusd.conf に指定した場合はどうかと、 mainconfig.c を見てみる。 「log { ... }」 の中で 「destination = stdout」 を指定すると、 mainconfig.radlog_dest に RADLOG_STDOUT が代入されるようだ。 ところが、mainconfig.radlog_fd を設定するコードがない。 これでは stdout にログが出力されるはずがない。

「-l stdout」 の件は百万歩譲って「仕様」でも構わないが、 mainconfig.radlog_dest に RADLOG_STDOUT を代入しておきながら mainconfig.radlog_fd に代入し忘れるのは、 仕様うんぬん以前にソースとして首尾一貫していないので、 明らかにバグである。

そこで以下のようなパッチをあてて、 mainconfig.radlog_dest が RADLOG_STDOUT あるいは RADLOG_STDERR のときは、 mainconfig.radlog_dest に STDOUT_FILENO あるいは STDERR_FILENO を それぞれ代入するようにしてみた。

--- src/main/mainconfig.c~	2008-12-06 01:37:56.000000000 +0900
+++ src/main/mainconfig.c	2008-12-06 16:16:27.455277946 +0900
@@ -738,6 +738,10 @@
 				cf_section_free(&cs);
 				return -1;
 			}
+		} else if (mainconfig.radlog_dest == RADLOG_STDOUT) {
+			mainconfig.radlog_fd = STDOUT_FILENO;
+		} else if (mainconfig.radlog_dest == RADLOG_STDERR) {
+			mainconfig.radlog_fd = STDERR_FILENO;
 		}
 	}
 

これで無事、 ログが stdout に出力され、 /service/radius/log/main/current に書き出されるようになった。

あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。

故障した HDD WD10EACS を RMA 手続きで交換してみた から引用

文面を再現するのに時間がかかりそうだなぁ～と思っている間に、 交換品の HDD が届いてしまったので、 「暗号」解読するモチベーションを失ってしまっていたのだが、

Posted by 通りすがり 2008年07月02日 00:36
結局、メールにはなんて書いてあったのでしょうか？

同ページ コメント欄 から引用

というコメントを頂いてしまったので、 暗号解読してみることにした。

以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する:

From: "Western Digital RMA" <noreply@wdc.com>
To: <sengoku@gcd.org>
Date: Thu, 26 Jun 2008 02:44:25 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-OriginalArrivalTime: 26 Jun 2008 09:44:25.0728 (UTC) FILETIME=[3861F800:01C8D771]

HIROAKI SENGOKU -l,=D6=81A

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
,=CCfXfe=81[f^fX,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B  RMA
,=C9S=D6,=B7,=E9,=A8-=E2,=A2=8D?,=ED,=B9,=CD,=B1,=CCf=81=81[f<,=C9.=D4=90=
M,=B5,=C4,=AD,=BE,=B3,=A2=81B
=8F=EE.=F1,=AA=90=B3,=B5,=A2=8F=EA=8D?=81A,=B1,=CC"dZqf=81=81[f<,=C9,=CD.=
=D4=90M,=B5,=C8,=A2,=C5,=AD,=BE,=B3,=A2=81B


RMA "=D4=8D?=81F 8083XXXX

--------------------------------------------------------------

O=F0S=B7fhf?fCfu,=F0 5=81`7 ?c<=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B

^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
Z=F3-=CC"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
"=AD'-=8F=F3<=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B

-A'-<=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c<=C6"=FA,=AA,=A9,=A9,=E8=81A,=BB=
,=CCO=E3"=AD'-'=C7=90=D5"=D4=8D?,=AA-LO=F8,=C9,=C8,=E8,=DC,=B7,=CC,=C5=81=
A,=B2-=B9=8F=B3,=AD,=BE,=B3,=A2=81B

O=F0S=B7fhf?fCfu,=CC'-.t=90=E6=81F

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

"z'-<=C6Z=D2=81F     Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
"=AD'-"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

S=D6~AfSf"fN=81F
RMAZ=E8=8F?ZwZ=A6=8F=EE.=F1,=CC?{--/^=F3=8D=FC
  - =

http://websupport.wdc.com/rd.asp?t=3D102&l=3Djp&p=3Dm&r=3D8083XXXX&f=3De

"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
  - http://websupport.wdc.com/rd.asp?t=3D103&l=3Djp&p=3Drp

RMAfXfe=81[f^fX,=CC?{--
  - =

http://websupport.wdc.com/rd.asp?t=3D104&l=3Djp&p=3Dv&r=3D8083XXXX&z=3D21=

3-XXXX

Western Digital fTf|=81[fgfz=81[f?fy=81[fW
  - http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

^=C8=8F=E3=81A
WD RMA f`=81[f?

http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

ヘッダに「quoted-printable」と書いてあるとおり、 quoted-printable エンコーディングを行なったのだろうが、 のっけから「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となっていて、 一体何語なんだ？と思わせる始まり方である。

ちなみに quoted-printable というのは 8bit データを、 「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 (エンコーディング) で、 印字可能でない 8bit データは 16進数で表わして前に「=」をつける (「=」自身は「=3D」で表現する)。 例えば「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」は、 16進数で書くと 「5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD」 という 8bit データ列を意味する。

腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか？

結論から言うと元のテキストは Shift JIS で書かれた日本語である。 海外からのメールなので、日本語以外の可能性を考えてしまったのが敗因だった。 最初から日本語であると決めつけていれば、 もうちょっと早く解読できていたかもしれない。

Shift JIS の場合 1byte 目は 0x80 (16進数で 80) 以上であるはずなのだが、 なぜ冒頭が「5E C8 3F BA ...」になってしまっているかというと、 元テキストにおいて 0x80 ～ 0x98 のデータが、 メール中で以下のように化けてしまっているため。

表中、「元データ」の欄に、Windows の欧文文字コード CP1252 の字形を入れてみた。 それぞれの元データがメール中でどのように化けるかを見ていると、 quoted-printable エンコーディングにおいて、 CP1252 の字形を印字可能文字 (7bit の英字・記号) で無理矢理表現しようとした結果、 このような「文字化け」変換が行なわれてしまったように思えてくる。

注目すべきはこの変換が多対一対応である点、 すなわち異なるデータがメール中で同じ文字に変換されてしまっている点だろう。 例えば、 0x80, 0x86, 0x87, 0x89 のいずれのデータも、 メール中では「?」という文字に置き換えられてしまっているし、 0x93 も 0x94 も区別無く「"」という文字に置き換えられてしまっている。 すなわちメール中に「"」が現れても、それが 0x93 なのか 0x94 なのか、 はたまた「"」自身なのか、区別がつかない、ということである。

元のテキストでは、 冒頭は『以下に表示された』という文字列だったと推測される。 『以下に表示された』という文字列を quoted-printable エンコーディングで変換すると、 「=88=C8=89=BA=82=C9=95\=8E=A6=82=B3=82=EA=82=BD」になるが、 0x88 は上表にあるように「^」に化けてしまう。 同様に、0x80～0x98 の各データについて上表の「文字化け」変換を行なうと、 「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となって、 前掲したメールの冒頭に一致する。

このように元のテキストから「文字化け」したメールを生成するのは、 上表を用いれば簡単に行なえるが、 その逆変換 (つまり文字化けの修復) は複数の可能性 (例えば「^」は 0x88 と「^」自身の二通りの可能性がある) の中から最も日本語として自然なものを選ばなければならない。

というわけで、 化けている文字それぞれについて、 一番自然に見えるものを選ぶ、 という操作を繰り返すことによって「暗号解読」すると、 元のテキストと思しき次の文面が得られる:

HIROAKI SENGOKU 様へ、

以下に表示された RMA のステータスを確認してください。  RMA
に関するお問い合わせはこのメールに返信してください。
情報が正しい場合、この電子メールには返信しないでください。


RMA 番号： 8083XXXX

--------------------------------------------------------------

交換ドライブを 5～7 営業日中に発送します。

以下のドライブを Western Digital は受領しました：

     シリアル番号     製品番号             受領日（GMT）
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

以下に表示された RMA 発送状況を確認してください。

輸送業者のシステムの更新に1営業日がかかり、その後発送追跡番号が有効になりますので、ご了承ください。

交換ドライブの送付先：

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

配送業者：     Fedex
配送追跡番号： XXXXXXXXXXXX

     シリアル番号     製品番号             発送日（GMT）
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

関連リンク：
RMA手順指示情報の閲覧/印刷
  - http://websupport.wdc.com/rd.asp?t=102&l=jp&p=m&r=8083XXXX&f=e

発送と梱包の情報
  - http://websupport.wdc.com/rd.asp?t=103&l=jp&p=rp

RMAステータスの閲覧
  - http://websupport.wdc.com/rd.asp?t=104&l=jp&p=v&r=8083XXXX&z=213-XXXX

Western Digital サポートホームページ
  - http://websupport.wdc.com/rd.asp?t=105&l=jp&p=h

以上、
WD RMA チーム

http://websupport.wdc.com/rd.asp?t=105&l=jp&p=h

「交換ドライブを 5～7 営業日中に発送します」と書いてあるが、 実際にはこのメールが送信された時 (日本時間で 6/26 18:44) には既に発送が完了 (18:02) していて輸送中である。 このメールを 6/27 の時点で解読できていれば、 HDD が届く前に FedEx の追跡ページ で HDD が今どこを輸送中であるか調べることができたはずであるが、 あいにく 6/27 は一日中外出していたので、 解読を始めたのは 6/28 土曜日のお昼過ぎになってからである。 ちょうど解読の糸口がつかめたあたり (元テキストが Shift JIS であることが判明した時分) で HDD が届いてしまった (6/28 15:34)。

参考までに、復号するための perl スクリプトを以下に添付する。 解読はこのような復号スクリプトを徐々に形作りつつ、 前述した表を推測していく形で行なった。

#!/usr/bin/perl
use strict;
use warnings;
while (<>) {
    while (/=\n/) {
	$_ = $` . <>;
    }

    s/\"=D4=8D\?/*94*D4*8D*86/g;	# 番号
    s/=(8[DF])\?/*$1*87/g;	# 合
    s/\?\{\-\-/*89*7B*97*97/g;	# 閲覧
    s/fVfXfef\?/*83V*83X*83e*83*80/g;	# システム
    s/fTf\|=81\[fgfz=81\[f\?fy=81\[fW/*83T*83|=81[*83g*83z=81[*83*80*83y=81[*83W/g;	# サポートホームページ
    s/f\`=81\[f\?/*83`*81[*83*80/g;	# チーム
    s/f\?/*83*89/g;	# ラ
    s/fS/*83*8A/g;	# リ
    s/f\</*83*8B/g;	# ル
    s/f\"/*83*93/g;	# ン
    s/\'-/*91*97/g;	# 送
    s/\'\?/*92*86/g;	# 中

    s/\,(=[0-9A-F][0-9A-F])/*82$1/g;
    s/f(=[89A-F][0-9A-F]|[\^\|ACNSTVXehu])/*83$1/g;
    s/\^(=[0-9A-F][0-9A-F])/*88$1/g;
    s/\?(=[0-9A-F][0-9A-F]|c)/*89$1/g;
    s/S(=[0-9A-F][0-9A-F]|[cm])/*8A$1/g;
    s/\<(=[0-9A-F][0-9A-F])/*8B$1/g;
    s/O(=[0-9A-F][0-9A-F])/*8C$1/g;
    s/Z(=[0-9A-F][0-9A-F]|[qw])/*8E$1/g;
    s/\'(=[0-9A-F][0-9A-F])/*92$1/g;
    s/\"(=FA|d)/*93$1/g;
    s/\"(=[0-9A-F][0-9A-F]|[Fz])/*94$1/g;
    s/\.(=[0-9A-F][0-9A-F]|[it\\])/*95$1/g;
    s/\-(=E2)/*96$1/g;
    s/\-(=[0-9A-F][0-9A-F]|[ALl])/*97$1/g;
    s/\~(=[0-9A-F][0-9A-F]|[ALl])/*98$1/g;

    s/[=\*]([0-9A-F][0-9A-F])/pack("H*", "$1")/eg;
    print;
}

32bit プログラムからの呼び出しに対応するといっても、 基本的には引数の型を変換するだけである。 x86_64 の整数データモデルは LP64、 つまり long int 型とポインタ型が 64bit で (引数の型として多用される) int型は 32bit のままなので、 変換が不要なケースも多い。

例えば ioctl システムコールはファイル・ディスクリプタ (file descriptor, 以下 fd と略記) ごとに カーネルが実行すべき機能は変わってくるわけで、 その実装は各デバイス・ドライバに委ねられることが多い。 したがって 32bit プログラムからの ioctl 呼び出しに応えられるか否かは、 各ドライバが 32bit 対応しているか否かに依存する。 不幸にしてドライバが対応していない場合は、

ioctl32(tv:11028): Unknown cmd fd(5) cmd(40045613){t:'V';sz:4} arg(081ec8b4) on /dev/video0

などといったカーネル・メッセージ (dmesg) が出力される。 このメッセージは、 カーネル・ソース中 fs/compat_ioctl.c の compat_ioctl_error が出力している:

static void compat_ioctl_error(struct file *filp, unsigned int fd,
    unsigned int cmd, unsigned long arg)
{
    ...
    compat_printk("ioctl32(%s:%d): Unknown cmd fd(%d) "
            "cmd(%08x){t:%s;sz:%u} arg(%08x) on %s\n",
            current->comm, current->pid,
            (int)fd, (unsigned int)cmd, buf,
            (cmd >> _IOC_SIZESHIFT) & _IOC_SIZEMASK,
            (unsigned int)arg, fn);
    ...
}

fs/compat_ioctl.c は 32bit 版 ioctl システムコールを実装していて、 32bit プログラムが ioctl システムコールを呼び出すと、 この中の compat_sys_ioctl ルーチンが呼ばれる:

asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd,
                unsigned long arg)
{
    ...
        if (filp->f_op && filp->f_op->compat_ioctl) {
            error = filp->f_op->compat_ioctl(filp, cmd, arg);
            if (error != -ENOIOCTLCMD)
                goto out_fput;
        }
    ...
            compat_ioctl_error(filp, fd, cmd, arg);
    ...
 out_fput:
    fput_light(filp, fput_needed);
 out:
    return error;
}

つまりドライバ側で file 構造体の compat_ioctl 関数ポインタ (filp->f_op->compat_ioctl) が定義されていればそれが呼ばれ、 未定義ならば上記のような「Unknown cmd」エラーが出力される。

ちなみにこのエラーメッセージの「tv:11028」は、 ioctl を呼び出した 32bit プロセスの名前 (コマンド名) とプロセスID であり、 fd(5), cmd(40045613), arg(081ec8b4) は、 それぞれ ioctl システムコールの第一 (つまり fd 番号)、 第二 (ioctl リクエスト番号)、第三引数 (ioctl リクエストの引数) であり、 最後の on /dev/video0 は (第一引数の) fd 番号に対応するファイルのパス名である。

そして、この tv コマンドは 「ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画」で紹介した perl スクリプト であり、 その名称から推測できるとおりテレビ録画を行なうためのスクリプトである。

このスクリプトでは Video::ivtv モジュールを利用していて、 このモジュールが /dev/video0 つまり TV キャプチャ・デバイスに対して、 ioctl システムコールを呼び出している。 上記エラーはスクリプト中 $IvTV->stopEncoding($TunerFD); を実行したときに発生した。

その名称から推測できる通り、 stopEncoding メソッドはキャプチャ・デバイスに対して エンコーディングの停止を指示するためのもので、 内部で ioctl(fd, VIDIOC_STREAMOFF) などと ioctl 呼び出しを行なっている。 VIDIOC_STREAMOFF は videodev2.h にて、

#define VIDIOC_STREAMOFF    _IOW  ('V', 19, int)

と定義されていて、このマクロを展開すると 40045613 (16進) となり、 上記カーネル・メッセージ「cmd(40045613)」と一致する。

というわけで、(少なくとも Linux 2.6.24.7 に含まれる) ivtv ドライバは、 残念ながら 32bit 対応していないことが分かった。 もちろん x86_64 なカーネルではなく、 i386 カーネルを使えば 32bit プログラムから ivtv ドライバを使うことができるが、 x86_64 なカーネルでは、32bit プログラムからの ioctl システムコールを 64bit カーネルが受付けられる形に変換できないということだ。

とはいうものの、 32bit だろうが 64bit だろうが ioctl のインタフェースに大した変わりはないはずだ。 どうして ivtv ドライバは 32bit 呼び出しをサポートしていないのだろう？ と 思いながらドライバのソースを眺めていると... drivers/media/video/compat_ioctl32.c を見つけた。 名前からしていかにも 32bit 版 ioctl のように見える。

compat_ioctl32.c の中の v4l_compat_ioctl32 ルーチンは、 32bit な ioctl 呼び出しを受付けて 引数を 64bit へ変換し (といっても int 型はどちらも 32bit だが)、 本来の (64bit な) ioctl を呼び出し直す仕組みになっている。 なぜ ivtv ドライバは、このルーチンを利用していないのだろうか。

static int do_video_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
    /* First, convert the command. */
    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF32: realcmd = cmd = VIDIOC_STREAMOFF; break;
    };

    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF:
        err = get_user(karg.vx, (u32 __user *)up);
        compatible_arg = 1;
        break;
        ...
    };
    if(err)
        goto out;

    if(compatible_arg)
        err = native_ioctl(file, realcmd, (unsigned long)up);
    else {
        mm_segment_t old_fs = get_fs();

        set_fs(KERNEL_DS);
        err = native_ioctl(file, realcmd, (unsigned long) &karg);
        set_fs(old_fs);
    }
    ...
    return err;
}

long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
        ret = do_video_ioctl(file, cmd, arg);
        break;
    ...
    return ret;
}

ざっと見た感じ、 ivtv ドライバからこの v4l_compat_ioctl32 ルーチンを呼んでも 特に問題は無いように思われる。

そこで、ivtv ドライバの file 構造体 (の中の file_operations 構造体) の compat_ioctl 関数ポインタに、 v4l_compat_ioctl32 を設定してみた。

--- linux-2.6.24.5.org/drivers/media/video/ivtv/ivtv-streams.c	2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.5/drivers/media/video/ivtv/ivtv-streams.c	2008-05-04 09:10:07.581416212 +0900
@@ -49,6 +49,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_enc_poll,
 };
@@ -59,6 +60,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_dec_poll,
 };

このパッチをあてることにより、 x86_64 なカーネル上で i386 な Video::ivtv モジュールを使って、 ビデオキャプチャ・カード GV-MVP/RX2W を コントロールすることができるようになった。 一週間ほど使ってみた (多数の TV 番組を予約録画した) が、 今のところ問題は起きていない。