LinuxCon2010/Linux Kernel Panel
SCSIメンテナのJames Bottomley（メモでは”B”と表記）、
カーネル開発者でLWNエディタのJon Corbet（メモでは”C”と表記）、
USB & PCIサブシステム、STABLEカーネルのメンテナのGreg Kroah-Hartman（メモでは”G”と表記）、
スケジューラ開発者Peter Zijlstra（メモでは”P”と表記）、
KVMとかやってるChristoph Hellwig（メモでは”H”と表記）、
そして、Rusty Russellがモデレータというカーネル開発者パネル。
カーネル界隈の内輪ネタを生で聴けて面白かったです。
パネリストの表記一覧
B: James Bottomley
C: Jon Corbet
G: Greg Kroah-Hartman
P: Peter Zijlstra
H: Christoph Hellwig
R: Rusty Russell
Q: 会場からの質問
パネルメモ
カーネルのリリースについて
R:
カーネルのリリースは終わった？
B:
終わらないよ。
カーネルの半分以上はドライバで、新しいハードウェアが出続ける以上、新しいドライバが必要になってくる。
インテルとかがデバイスを作らなくなったらカーネルの開発は止まるでしょうけど。
なぜカーネル開発を続けるのか
Q:
なぜ、カーネル開発を続けられるのでしょう？
H:
カーネルを開発をやってる人たちと仕事をするのが楽しい
G:
ドライバでちゃんとハードが動くようになるのがるれしいです。
C:
システムの中に何があるのかを知るのをうれしい。
B:
人類のためにといいたいが、給料のためにやってます。
日本人が開発に参加するには？
C：
コントリビューションの5%は日本から来ていた。
ここ数年、日本からのコントリビューションが多かった。
Q:
日本からのコントリビューションが増えているというが、
どこからはじめたらいいか？
また、どこが必要とされているか？
G:
ドキュメンテーションが必要だし、入りやすいだろう。
何より、自分のやりたいことが一番良いだろう
B：
メーリングリストに入ることだ。
メーリングリストを読んで、他の人がコントリビューションしていないかなどを確認してほしい。
HowToにしても、カーネルの情報が必要だ。
R：
他の人のパッチをレビューすることも重要だ。
貢献するひとつの方法だろう。
C:
パッチのレビューは初心者にとっては恐ろしいものになるかもしれない。
動作がしない、わからない、といった指摘でも良い。
これが問題解決につながり、改善につながるだろう。
カーネルの開発プロセス
Q：
最近、StagingTreeなど、新しいカーネル開発の仕組みができたが、どのように運営しているのか？
P:
新しいドライバで、完全に入れなおしもあったし、
ごみみたいなコードも多い。
C:
Stagingツリーは、カーネルに入れるステップというよりも、
準備のためのツリーとして役には立っている。
B：
SCSIのパッチだと、最初のベンダーコードは使えないことが多い。
正しい実装になっていない。
これは誰にも直せない。
データシートも公開されていない。
C：
メーカーにも、ドライバはStagingツリーに入ることを伝えておかないといけないだろう。
そうすると、ベンダー開発のモチベーションになるだろう。
B：
ベンダーはStagingツリーの存在も把握して、コンパイルが通るようにして、
システムを保つべきだろう。
Linuxコミュニティに入るには何から始めるべきか
Q:
日本の開発者はLinuxのコミュニティに入りたいと思っているが、どこからはじめればよいか？
P:
興味のある分野をやればよい。
C:
カーネルのBugzillaを見るのもよい。
バグフィックスは良い貢献になる。
B：
SCSIがお勧めです！
R:
メーリングリストを読んでほしい。
G：
カーネルMLは大事なところだけ読んだら良いのでは？
B：
サブシステムのメーリングリストもある。
ある程度こうしたのでなじんでから、発言すればよいだろう
R:
ネイティブでないひとにはMLは難しい？
ジョークがわからないとか。
P：
そんなに難しくないと思いますよ。
全体としては、開発に言語はそれほど問題にはならない。
B：
シンプルで丁寧に言葉を使うようにしているし、
メールは送る前に読んで、考える時間がある。
時間を割いてください。
H：
簡単な文章を書くようにしたら良いと思います。
あなたの将来のためにもなる。
失敗談を教えてください。
Q:
カーネルコミュニティで経験した失敗を教えてください。
R:
たくさんありすぎて困るが・・・・
B：
難しいですね・・・
メンテナは失敗を成功に持っていくのが仕事ですし。
また、失敗をわからないようにするのもテクニックだ
G：
ユーザーのハード・データを壊したことも！
ユーザのPCを何回も再起動させてしまったり、
HDD壊したり・・
少なくとも5-6回はあるｗ
R:
カーネルディベロッパに、とんでもないものを作ってると指摘されたことがある。
ただ、そのおかげで、問題を指摘してもらいやすくなった。
質問が私のところに来るようになった。
カーネル開発に必要なスキル
Q:
コントリビューションするには、どんなスキルが必要か？
P：
「C言語！」
C：
バグを見つける能力は必要だろう
R：
バグを見つけるのはすばらしい能力だろう
あと、継続して修正することがあるので、継続する力が必要だ
P：
フィードバックを粘り強く聞くという能力が必要だ。
Q：
ユーザースペースから入るのはどうか？
R；
TTYもひどいが、ユーザースペースがひどい。
ユーザースペースでひどいところはSambaだが・・・
ユーザースペースで仕事するのは退屈だ。
H：
QEMUなんかは単一テストだけでも難しい。
開発はデバイスが限定できるので楽だと思うが。
Q：
Rubyとか、楽しいのでは？
B：
オレはRuby知ってる。
カーネルのデバッグツールは？
Q：
デバッグはどんなツールを使ってますか？
printk以外で・・
P：
「vi」
G：
トレーサを使う。
でもprintkかな。
H：
デバドラはどうしてもprintkになる。
traceをすることで、printkをやめて楽になった。
R：
ネットワーク系はツールが役立つ
パケットフィルタとか
C：
デバッグFSは有効だ。
Linuxのバージョン
Q:
2.6は次のバージョンに上がらないのでしょうか？
G：
確かに、2.6の中だけで変更が多すぎる。
混乱してるので、ナンバリングを変えたい。
最初の”２”をとってしまうとか。
B:
Stableなブランチとunstableなブランチもできた。
そのほうが簡単に見えた。
マージウィンドウなどの仕組みもできた。
仕組みでカバーしている、
H:
もともとの開発期間に戻ってきた気もする。
