日経BPのサイトに、誰も読まないOSのソース・コードという記事がアップされている。

わりと衝撃的な見出しから始まるのでさくっと引用

　まず，結論から言おう。　「エンジニアがOSのソース・コードを読めるようになると，活躍の場が一気に広がる」。そして，「コツさえ分かれば，OSのソース・コードはびっくりするほど簡単に読める」。

　赤松氏が「ソースを読んでいる人がほとんどいない」と感じる理由はもう1つある。それは，誰もがよく使うソフトでさえバグが大量にある，ということだ。少しでもソースをのぞけば，誰にでもすぐに見つけられるほど簡単なバグなのに，ネットにも情報が上がらず放置されているという。例えば，赤松氏が見つけたバグの具体例を一つだけお見せしよう。

まあ、寝言は寝てから言ってくれといった感じだが、カーネル読めるぐらいで生活は楽にならんっちゅーの。
だいたい、アンタprocfsとネットワークしか読んでないならカーネル屋としては全然駆け出しやんけ。

最近のLinuxでごろごろ変わっているエンタープライズ向けのスケーラビリティー向上パッチに追従できてナンボやで。


閑話休題

ところで、しょーもない不具合が長年放置され続けるってケースはオイラも結構実体験があったりする。
しょーもなさすぎるから、みんなが「ま、いっか」モードになってしまうわけだな。

具体例を一つ。

えーと、UNIXなタイマーってのはとっても貧弱な機能しかAPIとして提供してないので
大規模開発になるとすぐにSIGALRMの取り合いになってしまうという根本的に間違って仕様になっています。

んで、普通はタイマーを管理するサブシステムやらスレッドやらを作るのだが、当時オイラが関わっていた
プロジェクトでは10msの精度が必要だったのでタイマー担当者が以下のようなスレッドを作ったのだな

	while(1){
		usleep(10 * 1000);
		for(elem=list_head(); elem; elem=elem->next){
			elem->remain -= (10 * 1000);
			if( elem->remain == 0 ){
				/* timer fired */
				elem->func( elem->arg );
			}
		}
	} 

ま、エラー処理とか大幅に省略してあるけど、雰囲気は伝わると思う。

で、動かしてみるとなぜかタイマーがかっきり２倍近く狂ってしまう。
多少の誤差は覚悟していたが、なんで２倍やねんと。まあ、そういう話になってだな。

ソースを見てみたんよ。


で、出てきたのは以下（当時のソースはもうないから、lxr.linux.no の2.4.28のソースより引用してる）

linux/kernel/timer.c より

836 asmlinkage long sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp)
837 {
838         struct timespec t;
839         unsigned long expire;
840 
            (中略)
860 
861         expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
862 

linux/include/linux/time.h より

32 timespec_to_jiffies(struct timespec *value)
33 {
34         unsigned long sec = value->tv_sec;
35         long nsec = value->tv_nsec;
36 
37         if (sec >= (MAX_JIFFY_OFFSET / HZ))
38                 return MAX_JIFFY_OFFSET;
39         nsec += 1000000000L / HZ - 1;
40         nsec /= 1000000000L / HZ;
41         return HZ * sec + nsec;
42 }

見て分かるように、時間をjiffiesに変換する処理で端数切り上げ
（当時はカーネルタイマが100Hzなので10ms単位）
してるのに、呼び出し側でさらに１足している。

つまり、usleep(0)は本当に０と解釈するけど、usleep(10 * 1000)は内部でusleep(20 * 1000)にされてしまっていたわけ。

うーん、ugly


一瞬パッチを作ろうかとも思ったが、いつものように「それが仕様だ」「usleepは引数以上の時間寝ることを禁止していない」
「今あるアプリが誤動作するかもしれない」etc.. と返ってくる返答が容易に想像できたのでやめた。

んで結局、タイマーサブシステムを書き直して対処しましたとさ。


ま、この程度の「うがーーー、なんだこのuglyな仕様はーーーー！！！」と叫んで初めて一人前って気もする。
Linuxの場合。昔からすんげぇ癖が強いから。



で、ここでさらに話を変えて
この話に言及していたブログでこんなのを見つけました。

でいずおぶぱーがとりー様

「LinuxのOSコードを読めるようになれば、イロイロわかるよ～。コツさえ掴めばなんとかなるよ。」
ッて話。
にしても、Cを知らない俺には敷居高いと思う。だから、とりあえず関連有る連載が始まった日経Linuxでも立ち読みしてみるかな。

おほほほ。
Ｃ言語なんてカーネルを読んで勉強するものですわよ。

実際オイラは、情報系の学校とか出てないのでＣ言語はK&R本と、日本橋で買ってきたFreeBSD2.2 のCDのソースコードで
覚えましたわよ。

といっても、カーネルをいきなり理解できるはずもなく、半分以上理解できなかったが、データ構造の作り方の定石とかが
いきなり学べたのは本当にうれしかった。
たぶん、僕はカーネルを読んでＣ言語を覚えた最後の世代だと思う。同年代でそういう話あんまり聞かないし。

さらに言うとUNIXカーネルの動きがちゃんと理解できたと確信できたのは、

Haskellを勉強するためにPugsのソースを読むというのは、Cの勉強をするためにUnixのカーネルの読むようなものだ。いいねいいね、この主客転倒ぶり。*1

*1：Lionsの本(Lions’ Commentary on UNIX)はCのいい教科書でもある。 Cでどのように表現するかという勉強になるしね。

と、未来のいつかの日記でもオススメされている
Lions本を読破した後だったりする。
まじでいい本です。

僕はLinux 0.9 とかを読むより、こっちをすすめるな。
x86はカーネルの本筋じゃないところでやたら複雑だから、途中で心が折れる気がする。
はじめの一歩にぶん殴られたかのような衝撃が襲うものな。 ＞ Linuxのブートまわり



どうも、話が脱線してしまった。
結局いいたかったのは

・Linuxはそんなにバグバグじゃないよ。コードの質たかいよ
・でもuglyな仕様は、すごいたくさんあるよ。そこはuglyさ加減を楽しもうよ
・Ｃ言語できなくても気にすることないよ。カーネル読んでいけばそのうち覚わるから
・赤松ナントカはシッタカ・うそつき

って事ぐらいか


そして、まとまらないままに、了


追記：
上であげたusleepの問題は2.6系列では問題ない。
なぜならjiffiesが1024になったときに問題自体が自然消滅してるから。
1ms単位の精度だと、どうせ元から全然保障できてないので
（精度が細かすぎてちょっと割り込み入っただけで崩れまくる）
1msずれるぐらい、気にならない。というか気にしてられない

関連記事

• pfmonの使い方 (2006/04/12)
• 誰も読まないOSのソース・コード (2006/04/08)
• read で読み出すのと mmap で叩いていくのとどちらが速いか (2006/04/07)

これ、Perlにも言えてるな(苦笑)The C Programmming LanugageK&R革命の日々！-誰も読まないOSのソース・コード結局いいたかったのはLinuxはそんなにバグバグじゃないよ。コードの質たかいよでもuglyな仕様は、すごいたくさんあるよ。そこはuglyさ加....
【2006-04-11 Tue 01:32:28】 | 404 Blog Not Found

使い方を限定すると良い。1991年の初版以来、現在も重版改定を重ねているロングセラー！UNIXは、範囲が広く、方言も多いですが、その歴史や、ファイルシステム、Cシェル、vi、ネットワークなど、UNIXの概要・基本を非常にコンパクトに簡潔にまとめてあり、ひととおりマスタ
【2007-08-24 Fri 07:53:56】 | OSのレビュー