You are using an outdated browser. For a faster, safer browsing experience, upgrade for free today.

LinuxCon最終日レポート、大物カーネル開発者がアドバイスする「Kernel Developer Panel」など

最終日は、Linuxカーネル開発者によるパネルディスカッション「Linux Kernel Developer Panel」で幕を閉じた。

モデレーターは、stableカーネルのメンテナーであるGreg Kroah-Hartman氏(The Linux Foundation、以下Greg氏)。パネリストとして、リアルタイムパッチなどのメンテナーであるThomas Gleixner氏(linutronix)、cgroupのメンテナーの一人であるZefan Li氏(Huawei)、ブリッジなどネットワーク分野のメンテナーであるStephen Hemminger氏(Vyatta)、組み込み分野で使われるdevice treeのメンテナーであるGrant Likely氏(Linaro)と、異なるバックグラウンドの4人が登壇した。

モデレーターのGreg Kroah-Hartman氏(The Linux Foundation)左から、Thomas Gleixner氏(linutronix)、Zefan Li氏(Huawei)、Stephen Hemminger氏(Vyatta)、Grant Likely氏(Linaro)

最初の自己紹介でGreg氏により「最初のパッチは?」というお題が出されるという、カーネル開発者らしい始まりなった。なお、Greg氏の最初のパッチは、USB関連だったそうだ。

壇上では、device treeに関する議論などがなされた。Likely氏はdevice treeについて、組み込み分野で登場した技術と説明。ハードウェアの仕様のデータをカーネルが参照できるようにして抽象化する仕組みで、いろいろなハードウェアの違いの問題を解決するものとして採用されたという。一方、ARMサーバーではACPIを採用することになり、ARMのカーネルにもACPIのサポートが追加された。Likely氏は、両者は同じようにも見えるが違うもので、device treeは当分消えることはないだろうと主張した。

LinuxCon最終日レポート、大物カーネル開発者がアドバイスする「Kernel Developer Panel」など

そのほか、cgruopのインターフェイスの変更について不満の声が上がっていることや、ネットワーク分野でnetlinkの拡張に関して議論が起こっていることなどが話題に上り、「変更について、その部分ではうまくいっても全体でどうか判断するのが難しい」「APIを公開すると後から変更するのが難しい」「といって判断に何年もかかるのは困る」「インターフェイスについて過去の問題の経験のある人が考慮する必要がある」といった意見が出された。

会場からも活発に質問が出た。コードのテストについては、バグがわかるので助かるという声や、変更のときにテストが必要だが定期的には実行していないという声、自動ビルドツールを用意して壊れていればメールが来るようにしている話、ビルドのコンフィグの組み合わせが大変という話などが交わされた。

メンテナーがどのように大量のメールに対応し、効率的にパッチをレビューしているかの質問については、まずGreg氏が、コマンドラインのメールソフトを使いスクリプトも駆使していると回答した。また、Hemminger氏が「パッチの種類によって優先度が違う」と答えると、Gleixner氏は「そのほか、過去の実績のある人のパッチは信頼できるが、新しい人や過去にひどいパッチを出した人の場合は時間をかけてレビューする必要がある」と補足。Likely氏も、「自分が信頼している人がレビューしているパッチは私はレビューする必要はない、ということを学んだ」と語った。そのほか、Li氏は「cgroupとMySQLで問題が起きたときのパッチは、詳しくない分野でよくわからず困った」というエピソードも語った。

「日常的にstableカーネルを使っているか」という質問について、stableカーネルのメンテナーであるGreg氏は「使っていない」と回答。パネリストは、最新カーネルを使っている人や、仮想マシンのホストでstableカーネルを使ってゲストで最新カーネルを使っている人などさまざまな答えだった。また、「スマートフォンのカーネルをハックしているか」という質問には、昔やったが今はやっていないという回答から、まったくやっていないという回答、「スマートフォンを持っていない(笑)」という回答まであった。

英語の問題について質問が出ると、「Changelog(変更履歴ドキュメント)なら簡単」という声から発展して、Changelogに関するアドバイスとなった。パネリストからは次々に、「どう変更したか」ではなく「なぜそうしたか」を書くことが重要という意見が出た。これは、意図はコードからはわからず、どうしてその機能が必要かの説明のためであり、またレビューのときに目的に対してアプローチがよくない場合はアドバイスできる、さらに2年後に自分が見たときになぜそうしたか分からなくならないようにする、といった説明がなされた。

「新しくカーネル開発者になる人に伝えたいこと」という質問については、それぞれ熱心なアドバイスが語られた。Greg氏は、「まず興味のあることからやってみよう」とアドバイス。Gleixner氏は、「気後れしなくていい。パッチのコードが間違っていても、問題を指摘してくれればほかの人のガイドになる」「レビューにフィードバックしたときに、焦ってちゃんと直らないで再提出するとレビュアーもうんざりするので、じっくりフィードバックを読んで考えてほしい」「レビュアーは自分ではわかっているから手短に返すので、よくわからなかったら質問したほうがいい」と心がけを伝えた。

Li氏は、「過去のパッチを見て、特に大きな変更が加わったコードを見て、変更のやりかたを学ぶといい」とアドバイスした。Hemminger氏は「メンターを見つけるといい。私は『いい仕事だね』とポジティブな言葉をかけるようにしている」と、自分が心がけていることをまじえて説明した。Likely氏は「私も最初はどうしていいか分からなかったが、Linux Symposiumに参加して開発者に会ったら相手の顔がわかってパッチを送りやすくなった」という経験を語った。