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では新しいことをやり始めた

作業が倍になり、メンテナンスが大変になった
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.

http://lwn.net/Articles/126782/

このメールに対してすぐに、
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 ;-)

http://article.gmane.org/gmane.linux.kernel/283410

"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

参考:
http://lwn.net/Articles/402512/

2.6.32

2000のパッチがあった。
debianの人が多くの貢献があった。 
redhatでパブリックになって、debianに送って、gregがおくって
oracleカーネルもフィックスした。
小さい修正をして、アップストリームにいれる。
2.6.32はどんどん速くなった。非常にいいプロダクトになった。
現状、最も良い選択肢だろう。

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
という送り先がある。
セキュリティはリリースサイクルとは別だ。
修正したらすぐに直してリリースする。

デモ

先にリリースしたカーネルにバグがあったので、それを修正してきた。
この修正を反映したカーネルを今からリリースしてみる!



壇上でSTABLEカーネルをライブリリース!!