ヨタの日々(03-15[長年日記])

2002-03-15

_ 場所

神奈川

_ GLU

最近 GLU が頻繁に死にます。起動直後に死にます。いくらなんでも起動直後に死ぬかよと思ってたんですが、そいえば先日 Mozilla を 0.9.8 → 0.9.9 に上げました。

「 Mozilla 1.0 がリリースされるまでは特定のバージョンの Mozilla でしか動作しない場合が多いです。」

GLU のサイトに明記してあります。素な Mozilla で生活中。

_ 貴方が食べてみたいゲーム・アニメに登場する食べ物は?

コメットさん☆ファンは激辛マーボナスに投票しようとかいうことらしい。ていうか苺たんは食べ物じゃないだろ。

_ はにゃ枕

朝出勤して、会社に着くのがだいたい 0810 とかそのくらい。業務開始が 0830 で、それまで web を巡回してます。日記やらニュースやらを読んでます。

平田さんの日記に上記のサイトがありました。会社で見てしまったよ。仕事中じゃなくて良かった。

_ 買物

BSD MAGAZINE

まれにプログラミング講座とかあります。でも Linux で暮らしてるので微妙に実装が違ったり。

_ メモ

err() というのがあるんですね。 BSD MAGAZINE に書いてありました。perror() は知ってるけど err() というのは初めて知りました。

以下プログラム。

#include <stdio.h>   /* std(in|out|err) */
#include <errno.h>   /* errno */
#include <string.h>  /* strerror() */
int main( int ac, char **av )
{
  err( stderr, "%s : %s\n", av[1], strerror( errno ) );
  return 0;
}

その出力。

rin@mariko[~/work/c]% ./a.out foo
a.out: foo : Success
: Success

perror() より便利。最後の「 : Success 」は誰が出力してるんだ。

[ツッコミを入れる]

2003-03-15

_ 朝

今日こそは 0700 に起床しようと思ってたが 0830 起床。0920 出勤。

_ Standard Template Library プログラミング on the web

こんなのがあったのか。絶版になったからとはいえなかなかイキなはからい。

_ 虫

1 匹ずつ。

_ 飯

トビウオの干物食ってたら指に骨が刺さった。痛い。ぃゃ手で持ってかじりついてたんですよ。食いすぎた。

_ たばこ

久しぶりに吸った。父上のマイルドセブン。通称「まいせん」。

隠れて吸ってたあのころ( なに )を思い出した。

_ アニメ

今期見てたのはなんだかんだで以下の 3 つになった。

ヒートガイジェイ
L/R
魔法遣いに大切なこと

父上は興味を持って一緒に見てた。でも母上には退屈らしい。

[ツッコミを入れる]

2004-03-15

_ 休み

0900 ころ起床。やっぱり疲れてるもんだな。

_ FF

なべやんから教わったワールドパスを入力してキャラクター作成。

_ ぐで

昼飯食って 1230 〜 2130 まで寝てた。

ひたすら寝る日。たまにはこーいう日もアリだよね。

ていうか、土曜が徹夜で、弊社の決まりでは徹夜明けは休みになるんだから、これが普通の生活なんだよな。

去年 11 月から今年 2 月まで何度も徹夜したけど徹夜明け休みなんてとったことなかった。

_ 鳴る電話

起きたらうちの留守電に会社からメッセージが入ってた。電話に出てたら会社に出勤するところだった。寝ててよかった。

_ 計算機x2

やっぱ FF 用計算機と IRC 用計算機で 2 台必要だよねというもとしゃんとの会話。

_ FF

ようやっと冒険開始。なにやったらいいかわからないというのはまさにフリーシナリオ。どこぞの wiki にメンバー登録。

[ツッコミを入れる]

2005-03-15

_ 朝

....。\

0620 起床。

だる。

_ 仕事

弊社。

なんかいろいろ変わってる。

とくにヲレの席まわり。

マウスとか。

ディスプレイとか。

ディスプレイは 15 inch か？

小さい。

あとこのマウス、べたべたするんですがっ

_ [mew-dist 26006] Re: 日本語名の添付ファイル

埋もれてた。

_ 買物

4334032915

_ とびでばいん Complete Soundtrack

先日 Sweep Record で買ったとびでばいんのサントラ( 2005-03-09。
サントラは disc 2 枚組。
disc 1 はオリジナルサウンドトラック。
disc 2 はアレンジ( 以下とびでばいん disc 2 )。
とびでばいん disc 2 を手もとの計算機 Dell DimensionXPS GEN2 の CD/DVD なドライブに入れても Windows は CD として認識してくれない。マウントできてない。同時に購入した他の CD たちは CD として認識できてる。
上記を SweepRecord のサポートに報告した。
disc 2 は使用する計算機によっては CD として認識できないというのは既知らしい。普通の？ CD プレイヤーならば再生可能とのこと。あいにく普通の？ CD プレイヤーは持ってない( RD-X3 が使えるじゃんかよ )。
よってがんばって計算機で CD を聴きたい。
すると Sweep Record は別のとびでばいん disc 2 2 枚目を送ってきてくれた。とびでばいん disc 2 2 枚目は Sweep Record のほうで動作確認した CD であるとのこと。
とびでばいん disc 2 2 枚目を計算機に入れてたがやはり認識できない。
これを Sweep Record に報告した。そのとき「いま使ってる計算機以外の計算機か、または CD プレイヤーを入手するまで( RD-X3 を使え ) とびでばいん disc 2 の再生は待つことにするよ」と言っておいた。
Sweep Record はとびでばいん disc 2 の CD-R を送ってきてくれた。

手書きの付箋紙である。

これは認識できた。

最後まで丁寧にサポートしていただいた Sweep Record サポートのかたに感謝。お疲れさまでした( サポートから届いたメールには「担当佐宗」とあったが佐宗綾子さんのことだろうか。日記のほとんどが Not Found だな... )。

ここで注目してほしいのは、手順 11 において私は「別の機器を入手するまで待つ」と言っているにもかかわらず、SweepRecord のサポートのかた「そーっすかあ、ぃゃすんませんねえ」などとは言わず、「最後の手段です。これでどうよ」と CD-R を送ってきてくれたことである。この対応は称賛する。

SweepRecord 万歳。

_ 飯

散らし寿司( こうなご、桜えび )、ほうれんそう、味噌汁。

寿司酢はもう少し砂糖を減らそう。

本日のツッコミ(全4件) [ツッコミを入れる]

_ のぶ [PC のドライブで認識できないなら、RD-X3 でも認識できない可能性が高そうな気が。]

_ みわ [言葉が足りなかったっす。計算機というより、CD/DVD ドライブに依存するのです。ためしに父上が使っている計算機に..]

_ さいき [う〜んうちのＰＣ、すっかりＣＤドライブがお亡くなりになったな〜（涙次のバージョンアツプ計画は、ＤＶＤドライブだ..]

_ のぶ [バルクのドライブ、随分安くなったよなぁ]

2006-03-15 :-)

_ 仕事

2100 川崎。

0900 退勤。

はう。

_ Amazon.co.jp ご注文の発送

お客様からご注文いただいた商品を本日発送させていただきました。

ファイナルファンタジーXII

amazon がめずらしく早い！

_ TOEIC

申し込んだ覚えがない TOEIC 受験票がきた。

_ 史跡

終わりのクロニクルの史跡は何があったかなと。

立川
国立
神田
鹿島
出雲

...

ううむ。

「終わりのクロニクル」「史跡」でぐぐった。

ヨタの日々がトップだった。

ありがとうございました。

ref. 終わりのクロニクル - Wikipedia

_ 買い物

amazon

B000EBDCNC

_ web 巡回

Youichi’s Log(分家) - 有名ハッカー・高林哲がgoogle 社員と告白

私は Matzにっき(2005-09-13) で知りました。

これ。

高林くんや小松くんがGoogleにいったのはオープンソース開発者だからかもしれないなあ。

lambdaを予約語に入れるのはダメですよ。みんなbを抜かしてコンパイルエラーに悩むから。

( via 今日のなんでやねん )

よくスペルミスします...。

フィンローダのあっぱれご意見番・一覧

( via Phinloda の裏の裏ページ )

というか、単行本にできないのかな、これ。

ぜひ！

ほかに目当ての記事は無いけど「あっぱれご意見番」目当てで C マガジンを買ったこともあります。

良い育児書、悪い育児書

子供は居ないので子育てしてないのだけど、大人どうし( 大人ってなにということは置いておいて )の会話でも通用する話題っす。

ここに反応。

正しい怒り方があるように、まちがった怒り方もある。それは、すでに答えが分かっている質問をすること。ウソの上塗りを強要するか、子どもを追い詰めているだけ。最高にまちがった怒り方は「どうして…なの！」。それは質問ではなく、「おまえは…なんだ！」と強烈なメッセージを送っている（決め付けている）。決め付けられた子どもがそいつを改めると思うか? 自分に当てはめてみるといい。

私は自分が「どうして…なの！」と言われるのがイヤなのでひとにたいして「おまえは…なんだ！」を実践してます。

たとえばこう。

どうしてお前はチーズケーキばかり食うんだ？ → お前はチーズケーキ食いすぎだ！

すいません...。

[ツッコミを入れる]

2007-03-15 :-)

_ [箱根][富士屋ホテル]箱根紀行 2 日目朝飯

朝食はウィステリアで和食にしました。お品書き。ピントがあってません。

湯豆腐。

リンゴのゼリー。

_ [箱根][富士屋ホテル]箱根紀行 2 日目外観

1 日目に外観を見なかったので外に出てみました。

フロント前の広場から見える花御殿です。

本館

_ [箱根][富士屋ホテル]箱根紀行 2 日目ちょっと休憩！

先ほど朝食を食べたばかりだけどせっかくだからオーキッドでケーキを食べるのです。

_ [箱根][富士屋ホテル]箱根紀行 2 日目家に着くまでが休憩です

ということで箱根紀行は終了です。

温泉に行ってまったりしようと思って箱根に来てみたのだけど、富士屋ホテル内で過ごすだけでもじゅうぶんでした。もうね、ホテルが広いんですよ！子供のころだったら間違いなくかくれんぼして遊んでます。古い建物なので雰囲気というか居心地が良いです。秋葉原 UDX みたいないかにも「最新設備でオシャレでしょ」みたいな感じが無くて過ごしやすいです。それくらいワクワクする建物でした。

値段はそれなりにします。1 人での利用だったのでプラン無し。定価でした。食事代は普段の 3 倍くらいしました。くふ。でも気分よく過ごせたので良しとします。

_ [一純悠人][Amazon][R-TYPE]買い物

amazon

第三回あたりの電脳的悠人放送局で一純悠人さんが「 R-TYPE の音楽がかっこいいんだよ」と言っていた記憶が脳内キャッシュにヒットして amazon で「あわせて買いたい」になっていたので 2 つ買ってみました。彼女が言っていたのは初代の R-TYPE のことかしら。

B0000AFOPB

B00005FQO2

_ [7つの習慣][主体性][罪と罰][Win-Win][他力本願][人間関係][パラダイム]7つの習慣

最優先事項は以前読んだのだけど[ 2004-12-31 ] 元祖である「 7つの習慣」は読んでませんでした。

7 つの習慣とは以下の 7 つです。

主体性を発揮する
目的を持って始める
重要事項を優先する
Win-Winを考える
理解してから理解される
相乗効果を発揮する
刃を研ぐ

要点は以下の 1 つです。

自分が変われば世界が変わる

他力本願では何も変わらない、自分が変わる必要がある、自力で変わる、というものです。たとえば、「彼女が居れば変われるのに」「彼が理解しないからいけないんだ」といった言葉が出るときは他力本願です。「罪と罰」[ 2005-02-03 ]のラスコーリニコフは結局自力では変わらずにソーニャのおかげで変わりました。ラスコーリニコフは他力本願です。「 7 つの習慣」では他力本願で生きるのはやめよう、自力を鍛えようというものです。そのための習慣を紹介しています。

このなかで第五の習慣「理解してから理解される」に注目しました。第五の習慣は自分のことを相手に理解してもらうのではなく、先ず相手のことを自分が理解することが重要だと言っています。言われなくてもそんなことは分かっているつもりでした。

話をしているとき、ほとんどの人は、理解しようとして聞いているのではなく、答えようとして聞いているのだ。話しているか、話す準備をしているか、二つにひとつである。聞いている話をすべて、自分のパラダイムというフィルターを通して 自分の自叙伝を相手の生活に映し出しているだけである。例えば、「そうだ、そうだ。気持ちはよく分かるよ」とか、「私も同じ経験をしたんだよ。それはね…… 」といった具合である。このような人々は、常に自分のホームビデオをほかの人の生活に映写している。接するすべての人々に、自分がかけている眼鏡をかけさせようとする。人間関係( 夫・妻、娘、従業員との間など )において問題が発生すると、そういう人たちは決まって「相手が理解していない」という言葉で表現する。( p.354 )

自叙伝とは！

これはガツンと来ました。

私も「そのようなときは私はこうしたよ、だから同じようにするといい、それが正しい道だ」「 ( 私が出来るのだから )君も出来るだろう」というような言葉はよく使っています。言葉そのものはこうではなくても心の内ではこのようになっていたり、態度に現れているかもしれません。相手を理解するという行為は、自分というフィルタをいっさい通さないで相手の立場になって相手の話を聞くことが重要なのだそうです。

4906638015

_ プロンプト

( via Makinya's雑メモ )

> prompt $c´Д｀$Fノ
とかやったりしてますが(笑)

ということでやってみました。

C:\Documents and Settings\rin>prompt $c´Д｀$Fノ

(´Д｀)ノpwd
C:\Documents and Settings\rin

(´Д｀)ノgrep
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.

(´Д｀)ノ

(*´Д`)ノprompt $c*´Д`$F

(*´Д`)ハァハァ
'ハァハァ' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

わははははは。マヌケだ笑

_ [飯][蔵]飯

蔵で飯。

一人です。箱根土産を渡しに行きました。

話題を誘導されてあやうくセクハラになるところでした。

本日のツッコミ(全2件) [ツッコミを入れる]

_ さいき [相変わらずブルジョワな生活してるな〜にわさん（ｗまあそれで日々のストレスがとれるのであればＯＫかな？]

_ みわ [さいきくん年に 1 度くらいは贅沢するのです :^) かなりまったりゆっくりできて素晴らしい時間を過ごせました。]

2008-03-15 :-)

_ [BETTA FLASH]mini ALBUM「BETTA FLASH」発売記念！ライブ＆サイン会

＠タワーレコード渋谷店

行ってきますった。

_ [tuvasa2001][細江慎治][quad][LINEAR]LINEAR vol.25

＠Heavy Sick Zero (Nakano)

quad さんステージの途中から入りました。

細江慎治さんはエロゲの歌アレンジ？ウッウーウマウマで会場みんな踊ってて ~~キモイ~~ 笑った。

tuvasa2001 さんとこもウッウーウマウマ。最後は「りにあのうた2 REMIXES」 M-Projectアレンジかしら。

次回の告知してたから書いて良いんだよなあ。

次回
- 5/17 あたり。渋谷のなんとか
ゲスト
- ESTi
- 大久保博
- 佐野電磁
- 三宅優
- 他たくさん

_ [おやつ][とちの実せんべい]おやつ

とちの実せんべい。

[ツッコミを入れる]

2009-03-15 :-)

_ 朝ッ

0900 起床

頭痛い

_ [AsiaBSDCon]AsiaBSDCon 2009 4日目

K1: Internet Mail ? Past, Present, and (a bit of) the Future

Sendmail を書いたひと。伝説上の人物としてはｒｙ

_ [輪環の魔導師]輪環の魔導師5

エルフール王国編は終了。六賢人はロマサガ2 の七英雄のような存在か。

4048675982

_ 天体戦士サンレッドを見ていたら川添珠姫が登場した

バンブーブレードも神奈川が舞台[ 20080328#p03 ]だから良いのか。

_ [リッジレーサー7]リッジレーサー7

走行距離 10844.810 km
RSGP 進行度 100.0%
名声 18005 FP

_ [おひる][ナポリタン]おひる

ナポリタン

_ [おやつ][グラマシーニューヨーク]おやつ

グラマシーニューヨークのチーズケーキ。GIOTTO はたまに名前を見かけるんだが同じグループなのか。

_ [飯][じゃがいもとえびのにんにくパン粉炒め]飯

じゃがいもとえびのにんにくパン粉炒め(ref. きょうの料理 2007-05 p.20 )。えびを入れ忘れた。

[ツッコミを入れる]

2010-03-15 :-|

_ 朝ッ

0530 起床

_ 仕事

0830 出勤

_ 芝居やるから見に来るといいよ、と案内が来た

あと「たまには店に顔出せよ」とも言われた。

すんません

最近つらくてね...(財布的な意味で)

_ PCの画面の縞模様

縞模様っていうか。ディスプレイがほげってるのかと思ったが背景色によって縞模様が変化するのでどうやら OS 側の問題らしい。キャプチャしてみたらキャプチャした画像にすでに縞模様(?)が表示されている。どうしてこうなった。

背景によって縞模様(?)が異なる

_ ドライバーがあったのでインストール(アップデート?)してみた

Graphics Drivers & Software

RADEON 9800 TX

Windows にログオンしたあとに画面が真っ暗になったり微妙にまだ解決してないうえにモッサリする。

_ [リッジレーサー7]リッジレーサー7

オンラインバトル。ミスったりラグったり。どうも「○○さんがルームに入りました」などに気が散ってしまい集中が足りぬ。

走行距離 70935 km
RSGP 進行度 100.0 %
名声 22310 FP
オンラインバトル勝利数 644/2399

[ツッコミを入れる]

2011-03-15 :-(

_ 午前

0500 地震 && 起床

0610 IDカードを忘れたことに気付いたので振り出しに戻る

0640 南武線武蔵溝ノ口到着

0740 4 本くらい電車を待ったが混雑のため結局乗れず

0800 @huhehe からのツッコミによりバスの存在を思いだす || バス通勤

1000 川崎到着

1020 出勤

_ 午後

1400 コード書き書き

1700 退勤

_ 夜

1800 飯支度

1900 飯

[ツッコミを入れる]

2012-03-15 :-(

_ 午前

0520 起床

0830 出勤

0900 検討

_ 午後

1300 検討

1500 自社業務

1700 退勤

_ 夜

1900 ぐったり

2100 災害用伝言ダイヤル(171) 練習

2130 飯。ブリの塩焼き

2230 日本酒gkgk

_ 買い物

＠スイープレコード

特典つき

RIDGE RACER - PLANETARY SOUNDS - SweepRecordSHOP

_ [NetBSD][翻訳][posix_spawn]NetBSD Blog - posix_spawn syscall added posix_spawn システムコールの追加

February 26, 2012 posted by Martin Husemann

2012/2/26 Martin Husemann による投稿

Charles Zhang implemented the posix_spawn syscall during Google Summer of Code 2011. After a lot of polishing and rework based on feedback during public discussion of the code, this has now been committed to NetBSD-current.

Charles Zhang は Google Summer of Code 2011 の間に posix_spawn システムコールを実装した。公開討論のフィードバックを基にたくさんのコードを洗練し、再作業したものだ。現在これは NetBSD-current にコミットされている。

This caused some fallout and ended in a tight race with the imminent branch date for NetBSD 6. Now that the dust has settled, it is time for a look back at the mistakes made and lessons learned.

もうすぐ来る NetBSD 6 ブランチにおいて、競合の終了時{ ended in a tight race }にたまに異常終了する{ fallout }。現在は安定したので、ここでは過ちと教訓を振り返る。

What is posix_spawn? ( posix_spawn とは？ )

Traditionally BSD systems used the vfork(2) hack to improve speed of process creation. However, this does (in general) not play well with multi-threaded applications. The posix_spawn call is a thread-safe way to create new processes and manipulate a tiny bit of state (like dup/close/open file descriptors) upfront.

従来の BSD システムではプロセス生成の時間短縮のために vfork(2) ハックが用いられている。しかし、(一般的に)これはマルチスレッドアプリケーションではよろしくない。posix_spawn を呼ぶとプロセス生成をスレッドセーフとし、いくつかの状態( dup/close/open のようなファイル記述子 )を操作する。

Work continued after GSoC ( GSoC 後の継続作業 )

The results Charles had at the end of his GSoC term were a working in-kernel implementation of posix_spawn and a few free-form test cases, one of which failed. The kernel code duplicated a lot of other code, which clearly was not acceptable for commit to the NetBSD source tree. The reason Charles solved it this way was the short time frame available - and that the best solution we could think of during the summer was very intrusive.

GSoC 終了時の Charles の結果は、カーネル内に posix_spawn を実装し、2, 3 の自由な形式のテストをおこない、1 つが失敗した。カーネルコードは他のたくさんのコードと重複しているので、これを綺麗にしないと NetBSD ソースツリーへのコミットは許されない。Charles は短時間のフレームを有効にすることで解決した。GSoC 期間中に考えられたこの最善の解決策はとても intrusive だ {intrusive ????}。

In preparation for a potential merge into the NetBSD code base, I reworked the code to avoid copying helper functions (like file descriptor manipulations for other processes), cleaned up and debugged a bit using a LOCKDEBUG kernel, which pointed out a few more issues. After solving those as well as intensively testing all error paths, I posted a patch for review.

NetBSD コードベースにちゃんと { potential???? }マージするための準備としては、コードからコピーした補助関数(他プロセスのファイルディスクリプタ操作など))を削除する作業をし、綺麗にして、課題以外のいくつかの点で LOCKDEBUG カーネルで少しデバッグする。これらを解決するだけでなく、集中的にすべてのテストをパスしたあと、レビューのためにパッチを投稿した。

At this point the integration was already prepared completely - a new syscall, new libc functions, new manual pages need a lot of set lists updates and test building a "release" at least once (preferably on an architecture providing 32bit compat libraries), furthermore the posix_spawn code needed (simple) machine-dependent code to be added to all architectures, which at least requires test-building a representative set of kernels.

統合の準備はすでに完了している。セットリストをアップデートし、最低でも release を構築する( できるならば 32bit アーキテクチャ互換ライブラリを提供したい )ためには、新しい syscall、新しい libc 関数、新しいマニュアルページが必要だ。

Another complete rework (別の完全な再作業)

In response to the posted, very intrusive, patch, YAMAMOTO Takashi suggested a pretty elegant way to solve the problem without a lot of the intrusive changes. The idea was simple, and it actually worked after a few adjustments. This led to another public patch for review.

この投稿へのレスポンスはとても intrusive だ。山本貴志さんによるパッチは、それほどたくさんの intrusive な変更をせずに問題を解決することができるとてもエレガントな方法を提案してくれた。アイデアはシンプルで、ちょっとした調整をするだけで動作するようになる。この led {?????} はレビューのため別の公開パッチとする。

This version already included an atf version of the test programs, which all passed (both on amd64 and sparc64). I felt pretty confident with this state and expected a smooth integration.

このバージョンでは既に ATF のテストプログラムも含んでいて、すべてパスした( amd64 と sparc64 の両方で )。この状態でとても自信を持てたし、滞りなく統合できそうだ。

Unexpected fallout (期待していない異常終了)

More for completeness I did a full test run (not only the posix_spawn related tests) - and found some unexpected test failures, all in rump based tests. I retried and got different failures. Suspicious - I did not touch rump, besides regenerating the syscall definitions. I rebooted a standard kernel (without posix_spawn), did a full test run and only got failures in the posix_spawn tests (of course). So something in the change must have broken something else.

まだすべてのテストを走らせていないし( posix_spawn 関連のテストだけでなく )、rump ベースのテストすべてのうちいくつか期待していないテスト失敗がある。再度試したら異なる失敗になった。rump には触れていないので、syscall 再定義により再生成されたところ以外があやしい。通常のカーネル( posix_spawn なし )で再起動し、全テストを実施したら当然ながら posix_spawn のテストだけが失敗した。つまり、変更したもの以外の他の何かが壊れているのだ。

Analysis was a painful process, so only a short summary of the results: the modified kernel exec path used a pointer to a kernel stack variable, which was later copied to a saved data structure - but the pointer was not adjusted accordingly. Later the pointer was referenced, and only a single bit checked. Depending on what was in memory at the stale old stack location at that time, a branch was taken or not. This caused the ELF auxiliary data vector to sometimes contain a different effective UID, and ld.elf_so switching into secure mode - in which case it ignores environment variables like LD_PRELOAD. This causes big failure in many test programs using rump (at least).

解析はしんどい作業だ。結果の短い概要しかない。exec path を適用したカーネルがカーネルスタックポインタの変数を使った場合、後でデータ構造を保存するためにコピーしているんだが、このポインタはそれに応じて調整されていない。後にこのポインタが参照され、1 bit のみチェックされる。このときの失効した古いスタック領域のメモリの内容に応じて、ブランチは取得されたりされなかったりする。これは、ELF auxiliary データベクターが時々異なる実効 UID { effective UID } を含むことが原因だった。その場合には LD_PRELOAD のような環境変数を無視する。これは rump(少なくとも)を使用している多くのテストプログラムで大きな障害が発生する。

While I was debugging this, discussions continued. We were not sure if we should add complex code like this to the kernel, where a pure userland implementation clearly is possible (FreeBSD uses this, for example). I did a few benchmark runs, but was unable to show any clear performance benefit for either implementation - the differences were in the sub-promille ranges, with noise in the 2-3 percent range, clearly no usable result from a statistical point of view. Another topic under discussion was the near planned branch for NetBSD 6. According to our rules, we do not want to add a syscall post-branch to a release branch.

これをデバッグしている間も議論は継続している。このような複合コードをカーネルに追加しようとすることは自信が無いものだ。純粋にユーザーランドに閉じた実装 {implementation clearly} は可能だ( 例えば FreeBSD はそうしている )。いくつかベンチマークを走らせたが、実装の間でのそれほど明確なパフォーマンスの向上{ benefit }は見られなかった。違いは sub-promille ranges が 2, 3% の間でノイズがあった。はっきりいって、総合的に見て残念な結果{ no usable result }である。この議論では他に直近の NetBSD 6 ブランチ計画があった。我々の規則によるとリリースブランチの後のブランチに syscall を追加するのは望ましくない。

Go ahead, finally! (ついに!)

The discussions ended with the core team voting for a kernel version, and the release engineering team voting for a pre-netbsd-6-branch integration. So I updated my posix_spawn source tree, did another test build, ran tests (again on amd64 and sparc64), updated again - and committed in a few steps.

カーネルバージョンについてのコアチームによる投票と、リリースエンジニアリングチームの pre-netbsd-6-branch との統合の投票で議論は終了する。posix_spawn ソースツリーをアップデートしたので、他のテストビルドをし、テストをし( amd64 と sparc64 で )、再度アップデートし、これらの手順についてコミットする。

Big fallout (ヤバイ異常終了)

Checking mails early next morning (a Sunday, before walking the dog) I found a PR already: running the m4 configure script crashed i386 and amd64 kernels. Tsutsui kindly had provided a backtrace in the report, and it looked suspiciously familiar to me. While walking the dog I thought about it and when I got home I checked: indeed I had seen and fixed this before, when testing error paths in the first instance of the change. However, when dropping all the intrusive modifications I had in my tree and redoing the version without them, I must have accidentally dropped the fix for this (it was in sys/uvm instead of sys/kern). No big deal, I had fixed it once already, so I could fix it again. Committed, asked for verification - and did get a NAK. However, with a different back trace this time. Tried on my amd64 notebook - worked for me. Duh?

翌朝メールをチェックして( ニチアサの犬の散歩に行く前に )、既に PR されているのを見つけた。i386 と amd64 カーネルで m4 設定スクリプトを走らせるとクラッシュする。筒井さんがレポートにバックトレースを提供してくれたんだが、私にはちょっと信じられなかった。犬の散歩をしている間これについて考え、帰宅してから、修正する前にこの変更の最初の実例でテストがパスしたことをたしかに確認した。しかし自分のツリーですべての変更を破棄し、これら抜きのバージョンで再度実施したら、全て落た。この突然死を修正せねばならない( これは sys/kern を含む sys/uvm にある )。どうということはない。すでに一度修正したので再度修正できた。コミットし、適当かどうかを訊いてみたが、とくに拒否されなかった{ NAK }のだが、異論があればバックトレースする。自分の amd64 ノートブックで試したらウマくいった。あれ？

Looking at the code and fixing the second fallout now was straight forward, and also provided the hint why I did not see it before: I was not running a GENERIC kernel on my notebook, and had (some time way back in the past) removed options DIAGNOSTIC from this configuration. Stupid me!

コードを見ると第二の異常終了が修正されていることはすぐ分かった { straight forward ????? }。私が以前やったことのヒントがあった。設定から DIAGNOSTIC (ときどき過去に遡る方法として使われる) を削除した GENERIC カーネルを自分のノートブックで動作させていなかったのである。あたしって、ほんとバカ

I received more feedback (YAMAMOTO-san pointed out some race conditions) and had a discussion about the place where the test programs should live in the source. To not risk delaying the netbsd-6 branch, I applied a minimal fix for the races, moved the test programs - and added a few more test cases covering the initial m4 configure problems (the rework earlier had made it pretty simple now to test all error paths from atf test cases).

さらにフィードバックをもらった( 山本さんがいくつか競合状態を示してくれた )。ソースのどこにテストプログラムを設置するか議論した。netbsd-6 ブランチに間に合わないことは問題ではない。競合へのちょっとした修正を適用し、テストプログラムを移動し、初期設定 m4 問題をカバーするテストを追加した( この再作業は atf テストケースでは早い段階から全テストをパスしていた )

This caused the automatic test setup to crash on every run ("Tests did not complete"). At this point I am still not sure why I did not catch this before commit - but there is no point in arguing, human failure - my fault (most likely explanation: after the last changes to the test cases, I did not test again on amd64 but only sparc64 - the test cases triggered a KASSERT in the x86 pmap, but not in the sparc64 one).

これにより、自動テストセットアップは毎回クラッシュするようになった ("Tests did not complete")。この時点で私がだコミットする前にこれをキャッチしなかった理由は不明だ。しかし私の失敗が人為的ミスであったということを指し示すものはない。( 説明: テストケースを最後に変更した後に、sparc64 でのみテストし、amd64 ではテストしてない。このテストケースは x86 pmap で KASSERT のトリガーになるのだが、sparc64 にはないのである )。

I fixed this, and also another PR, interestingly about m4 configure again. Simple argument validation bug, not covered by the test cases yet - so I added another test.

これと他の PR も修正し、件の m4 を再度設定する。単純な引数の検証のバグはまだテストケースでカバーされていないので他のテストを追加した。

Are we there yet? (ほかには？)

Luckily fallout seems to have stopped now, but we are not completely there yet. The new process created by posix_spawn keeps the parent lwp blocked until it is done with all file descriptor modifications and setup, and the new process is ready to go to userland first time. This provides a proper error return value from the parent (the posix_spawn syscall itself), but it stops the new child from (for example) already running on another CPU early. This will be simple to change, but after all the fallout we have seen, I will only touch it after very extensive testing again.

運よく異常終了が停止したら、それはまだ完成していない箇所だ。posix_spawn によって生成された新しいプロセスは、全てのファイルディスクリプタを更新してセットアップする間親の lwp をブロックする。新しいプロセスは、最初にユーザーランドとして準備される。この提供は、親から proper error を返す( posix_spawn システムコール自身による )。が、新しい子が、たとえばすでに別 CPU で動作していたりしたら、停止させる。この変更は簡単だろうけど、それでもまだ異常終了に遭遇する。再び非常に広範なテストの後に触れたいと思う。

Lessons learned (教訓)

When bringing in a new syscall with several supporting libc functions, fallout is always to be expected. It can be minimized by including test programs early - but in the end, real life will teach you what tests you have missed when writing the test programs. It is also important do full test suite runs early, and test on different architectures. Even better if you test on kernels with (at least) DIAGNOSTIC enabled. But in the end, mistakes will happen nevertheless.

いくつか新しいシステムコールに対応した libc 関数を使用すると異常終了がいつでも期待できるようになった。これは早期のテストプログラムによって最小限に抑えることができる。しかし最後にはテストプログラムを書くきに見逃していたテストを教えてくれる。それは、早期の完全テストを実施することが重要だということであり、異なるアーキテクチャでテストしろということだ。少なくとも DIAGNOSTIC を有効にしてカーネルをテストするとより良い。それでもやはりミスは起きるだろう。

本日のツッコミ(全2件) [ツッコミを入れる]

_ tsutsui [自分の関係するところだけコメント。当時の雰囲気はこんな感じ? --- However, when droppin..]

_ みわ [オウフ.... did not get NAK と読み違えてしまった。読んでてなんとなく混乱した状態になってた雰..]