linuxのstable kernel reviewに参加してみませんか

はじめに

この文書は2013 Kernel/VM Advent Calendarの2日目のために書いたものを2016/2/2に編集したものです。

Linux の stable kernel というカーネルのリリース作業、およびそれに関わると、何がいいかということを説明します。自分がかつて2年ほどこの作業に関わっていた際は、自分自身の成長、および世界中のLinuxユーザに役立ったという実感が持てました。

stable kernel とは

Linux Kernel の公式サイトには、やたらとたくさんのカーネルソースが並んでいます。まずは、Linus Torvalds 氏が管理する mainline と呼ばれるカーネルです。この mainline カーネルに対して、機能追加をせずに(厳密には PCI の device ID なんかは追加されますが)バグフィックスのみを適用したカーネルが stable kernel です。上記サイトにおいて stable や longterm という印がついているものがそれです。これ以上の詳細を知りたいかたはここの説明をごらんください。

stable kernel review とは

stable kernel はリリースの 2,3 日前になると、メンテナの Greg KH 氏から、こんなかんじで「review cycle が始まったぜ!」という通知メールが飛びます。それから 2, 3 日後までが stable kernel の review cycle と呼ばれる期間です。この間にテストや取り込み候補のパッチをレビューしたりするのが stable kernel review という作業です。

参加する利点

以下に、異なる目標を持つ様々なかたにとっての利点を列挙します。ご自身に当てはまる箇所を読んでいただければと思います。

linux についての知識を得たい人

stable kernel に取り込まれるパッチは、通常、冒頭に「この機能は A の動作すべきだが、実際には B という誤った動作をする。このパッチはこれをこのように修正した」という記述の後に、ある 1 つだけのバグを直す短い修正パッチが続くという構成です。このため、全く知識が無い機能であっても、それなりの C 言語(と、たまにアセンブラ)の素養があれば、なんとか理解可能です。パッチレビュー作業をしばらく続ければ、linux kernel の様々な機能について相当詳しくなれます。

linux kernel を理解するには、この巨大な(総行数は現在一千万行超)ソフトウェアに真正面から突撃するより、細かいパッチをたくさん見る方が遥かに近道だと私は常々考えていましたし、実際やってみて、その思いは前よりも強まりました。

ソフトウェア開発に関する知見を得たい人

stable kernel への取り込み対象になるパッチは、強制終了やハングアップなどの、発生するとユーザがすごく困るようなバグの修正であり、かつ、実際に発生しうる(理論的に起こるだけでは駄目)ものに限られます。詳細についてはカーネルソース以下にある "Documentations/stable_kernel_rules.txt"内の"Rules on what …" の節をごらんください。

駆け出しのエンジニアは、とかく「バグであれば何でも直さなければ」と判断しがちですが、stable review を通じて、「実際に発生すると困るバグ、直すべきバグとは どのようなものか」という実務に必要な知見が得られます(もちろん人/組織によってポリシーは違うので、あくまで一例ですが)。

なにかしら社会的な貢献をしたい人

みなさんがリリースに貢献したカーネルは今後、何百万、何千万、あるいはそれ以上の数のコンピュータシステム上で動作します。自分で作成したパッチが取り込まれたりなんかした日には、 changelog に永久に名前が刻み込まれます。こんな経験が少しの労力でできてしまうんですよ、すごい!さらに、貢献度が高いと判断されれば、名うてのOSS エンジニアとして名を馳せられるかもしれません。

本職の linux エンジニア(とくにカーネルエンジニア)の人

上記の通り、stable kernel に取り込まれるパッチは、発生するとユーザが困り、かつ、実際に発生しうるバグです。さらに、どのバージョンのカーネルで発生するかがわかる(カーネルソースの "Documentations/stable_kernel_rules.txt" の"Procedure for submitting patches …" の節を参照)ことも多いです。これは、みなさん自身や、そのお客様の環境で使われているシステムにおいて発生しうる障害についての情報を、早期に知りうることを意味しています。これはエンジニアにとって非常に強いアドバンテージになることでしょう。

あらゆる人

この作業に貢献した人には、毎回Greg 氏から気持ちのよい「ありがとう」の言葉が得られます。「子供じゃあるまいし」とお考えかもしれませんが、自分の貢献が認められるということは想像以上に気持ちの良いものです。是非実際に体験してみてください。

作業内容

  1. linux stable ML (linux-stable@vger.kernel.org)を購読する ここを参照に購読手続きをしてください。

  2. review cycle が始まったら test/review を実施する。 linux stable ML には 1, 2 週間に 1 回、既存の stable kernelのreview cycle が始まります。メールの Subject は "x.y.z-stable review" です。そのメールの後に、個々のパッチのメールが返信形式で連なるという構造になっています。

作業内容は大きく分けるとテストとレビューの 2 つです。

2-a. テスト レビュー対象のパッチを適用したカーネル(全パッチをマージしたパッチも提供されます)、あなたの環境でビルドして、好きなテストを流すなりして、結果を Greg 氏に報告してください。現在私の知る限り、定期的にテストを実施している人は、それぞれ別の観点でテストしていますので、新たにテストをするかたは、なるべく別の観点でテストすると喜ばれるかと思います。

2-b. パッチレビュー レビュー依頼メールにくっついてくる個々のパッチセットをレビューし、レビューした事実と問題の有無を Greg 氏に報告します。問題がある場合は、修正パッチを添えると、さらに喜ばれます。「パッチがバグっていることなんてあるの?」と思われるかもしれませんが、ここだけの話、実はけっこうバグっています。わたしはこれまでに百個前後パッチをレビューしてきましたが、その中で 5 つくらいはバグを指摘した記憶があります。

一見簡単そうに見えるパッチでも、「バグってるわけない」という色眼鏡を外し、

  • 新たに増えたルートに新規バグを仕込んでいないか、
  • メモリリークはないか
  • 似たようなコードの他の箇所に同様のバグは無いか、

などの基本的なルールに従ってチェックしてゆくと、けっこうバグが見つかるもんです。慣れてくると怪しい箇所が光って見える特殊能力が身につきます(本当です)。

毎回死ぬほどパッチの数が多いので(たとえば 3.12.2 は 116 個)、全部見ようなどとせず、自分の興味ありそうなもの、まともなコメントがついているもの、コードが短いものを選ぶと、長く続けられると思います。同様に、「この作業をやらなきゃ」と考えるより「できたらやる」くらいでちょうどいいと思います。わたしも面倒くさい時や忙しい時にレビューをすっぽかしたことがたくさんありました。

他にも色々貢献方法はありますが、詳細が気になるかたは Greg 氏のブログエントリをごらんください。これは数年前のメールですが、別に今も実施する内容は変わっていませんし、いきなり参加して咎められることもありません。きっと歓迎されると思いますよ。

おしまい。