LinuxCon2010/The Stable Linux Kernel Tree, Delivering a Stable Platform on a Constantly Moving Base
The Stable Linux Kernel Tree, Delivering a Stable Platform on a Constantly Moving Base
Greg Kroah-Hartman, Fellow at Novell
最近の安定版Linuxリリースについて
Linuxは最も進化の速いソフトウェアプロジェクトで、安定することはない。
Linuxの目標は安定させることだが、継続的に修正してリリースするしかない。
- 最近のカーネルの規模を示す数値
- 33315files
- 1200万ステップ
- 2478 developers
- 342 companies
- 変更量を示す数値
- 116000lines added
- 50000lines removes
- 2300lines modified per day for all 2009
- 5.51change/hour !
Linuxの歴史
初期
15年前、Linux2.0.0が始まった
ドットコムブームがはじまり、開発をstableにする要望が高まった。
4ヵ月後に2.1.0がでた。
このあと、偶数が安定版という位置づけでしばらく続いた。
このルールで848日と141リリースした。
Linux2.2.0がでた
2.3.0
USBがポーティングされ、2.2にバックポートした。
変更要望や修正が多く、開発サイクルをもっと早くしたかった。
2.4.0
Linuxの開発が早くなった、フルタイムエンジニアも増えてきた。
10ヵ月後、2.5.0を作り始めた
2.5では新しいことをやり始めた
- ホットプラグ、SCSI・・・・
- ユーザーが望んでいたフィーチャーをどんどん取り込み、
- エンタープライズディストリビューションにどんどんバックポートしてきた
作業が倍になり、メンテナンスが大変になった
1057 days and 86 releases later....
BitKeeperの活用など、いろいろ工夫した。
2.6.0
インクリメンタルな形で開発が進み、安定化カーネルバージョンを作らなくても良くなった。
rc1,rc2....
と、リリース候補のマージウィンドウを作るサイクルで回りだした。
このサイクルは2年ぐらい続いた
ここで、いろいろ不満がでてきた。
リリースサイクルが3ヶ月になったので、修正が3ヶ月かかるようになった。
安定版カーネルに、最新のパッチやバックポートをする要望がある。
もちろん、バックポートはたいへんだ。
Linusから、誰かやってくれないかなあというメールがきた。
From: Linus Torvalds
Subject: Re: RFD: Kernel release numbering
Date: Thu, 3 Mar 2005 08:23:39 -0800 (PST)I'll tell you what the problem is: I don't think you'll find anybody to do
the parallell "only trivial patches" tree. They'll go crazy in a couple of
weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
line? What's an acceptable patch? And if you get it wrong, people will
complain _very_ loudly, since by now you've "promised" them a kernel that
is better than the mainline. In other words: there's almost zero glory,
there are no interesting problems, and there will absolutely be people who
claim that you're a dick-head and worse, probably on a weekly basis.
このメールに対してすぐに、
stableカーネルをパラレルでやる人はLinus含めてだれもやらないだろう!
という返信があったにも関わらず、
その20分後にGregが返信!
> Anybody?
Andres Salomon (-as patches) and I have been talking about that at least
regarding security fixes. It's worth trying in a more complete and
formalized way. Guess I can be branded a sucker ;-)
"sucker"とか呼ばれてたことも。
Stableブランチを作ることで、うまくいくようになった。
これは楽しいプロジェクトになりました。
stableツリーの運用ルール
- stable_kernel_rules.txt(Stableツリーの運用ルール)
- 正しいテストをしたものでなければならない
- 100行より大きいものはいれない
- ひとつの物事の修正
- 本当のバグ、問題だけ直す
- Linusツリーにすでに入ってるものだけいれなければならない。
書き直すのならLinusのツリーにも入れるべきだ。
ソースコード管理ツール(git)を使うとこうした運用は非常にうまくいく。
こうしたルールも読んでほしい。
LTS(Long Term Support)
2.6.16は多くのstableリリースがあった
非常に長い間使われたバージョン 2年ぐらい。
エンタープライズ分野で採用されると、長くメンテナンスされている。
同様に。2.6.27も長期メンテナンスしているバージョン。
いわゆるLTSカーネル。
アップストリームにバグをプッシュできるし、このやり方はうまくいく
現在のLTSは2.6.32
各種ディストリビューションで同じカーネルを使うようになった。
STABLEのエンタープライズカーネルとして確立した。
安定版カーネルリリース
version # releases # patches
2.6.11 12 79
2.6.12 6 53
2.6.13 5 44
2.6.14 7 96
2.6.15 7 110
2.6.16 62 1053
2.6.17 14 191
2.6.18 8 240
2.6.19 7 189
2.6.20 21 447
2.6.21 7 321
2.6.22 19 1584
2.6.23 16 613
2.6.24 7 383
2.6.25 20 419
2.6.26 8 321
2.6.27 54 1584
2.6.28 10 613
2.6.29 6 383
2.6.30 10 419
2.6.31 14 826
2.6.32 23 2003
2.6.33 7 883
2.6.34 7 601
2.6.35 6 442
STABLEへの修正パッチ投稿方法、レビュー、修正サイクル
stable@kernel.orgにパッチを送れば、gregに自動的に行く。
Jamesがいいスクリプトを書いてくれる。
gregが確認して、入れるか入れないを判断して取り込んでいく。
ルールに従えば、だれでもバグフィックスできる。
stable_kernel_rules.txtさえ守ってもらえればよい。
Review cycle
- patches are sent to maintainers and authors
- 48-72 hour review
- new release happens
Get Involved
- tag your patches!
- send commit ids to stable@kernel.org
- stable-reviewpkernel.org
Gregがビルドしてマシンをブートして、確認している。
Q&A
セキュリティパッチをどうやって送ればいいのですか?
security at kernel.org
という送り先がある。
セキュリティはリリースサイクルとは別だ。
修正したらすぐに直してリリースする。