LinuxCon2010/Japanese Kernel Developer Panel

Japanese Kernel Developer Panel

パネリストの表記一覧

F: Fujita Tomonori, Research Engineer, NTT
K: Kamezawa Hiroyuki, Programmer, Fujitsu
H: Hiramatsu Masami, Researcher, Hitachi

Moderated by
J: Jon Corbet, Linux Weekly News

Q: 会場からの質問

パネルメモ

J:
 コアカーネルの技術者は海外の方が多く思われていると思うのですが、
 今回は日本の技術者で、世界的に知られているエンジニアに集まってもらいました。

パネリストの紹介

F:
 藤田です。
 SCSIなどストレージに関連する仕事をしてます。

K:
 富士通の亀澤です。
 メモリ管理の仕事をしてます。

H:
 平松です。
 トレーシング関連の仕事をしてます。
 Kprobeの仕事をしてます。


カーネル開発をはじめたきっかけ

J:
 どのようにカーネル開発に携わるようになったのでしょうか?
 

F:
 2003年ごろに、iSCSIのサポートが仕事で必要になった。
 やりはじめると、iSCSIとは関係のない部分もやるようになりました。


K:
 2004年にはじめた。
 仕事を探していて、カーネル開発ができると履歴書に書いていたら、
 富士通でメモリホットプラグをやることになった。
 メモリリソース管理cgroupを3年ほどやってる。

H:
 大学でLinuxでロボット制御をやっていたが、
 仕事ではじめたのは、2002年ごろからLKSTトレーシングプロジェクトから。
 そのままトレーシング関連の仕事を続けています。


OSS開発に関わりたいと思っている人たちへのアドバイス

J:
 OSSコミュニティで開発を始めたいという人へのアドバイスはありますか?


F:
 自分がやりたいことを見つけるのが良いと思います。
 カーネルハッカーになりたいというだけでは無理だと思います。
 本当にやりたいことを見つけないと無理だと思います。
 あと、パトロンがいる。
 Linux開発ができる会社に入るとよい。

K:
 LKMLを読むこと。
 メールをきちっと読めば、Linuxカーネルのかなりの部分がわかるようになる。
 一日800通のメールを1年も読めばね。

J:
 ちょっと荒っぽいコメントですね!
 Linuxメンテナの何人がLKMLを全部読んでるとは思えないですが・・・

J:
 LKMLにもある程度のやり方があると思います。
 人と関わるときに難しいことはありますか?

H:
 参加はかんたんなのですが、RFCとか、手順がある。
 メンテナが読んで、レスポンスを返すのですが、メンテナが休暇でなかなか返信してくれないときがある。こうしたカンファレンスはチャンスになる。
 メンテナと直接話して、コミュニケーションをとれるので。

K:
 こうした場に立つたびに、「メール送ります」とか言われるんですが、
 日本人からの質問はその後来ないのです・・・。
 LKMLを見てると、面白いテーマがあるはず。
 関心があるテーマがあって、それが開発中だったら、とりあえず動かしてみると良い。
 特に、patchのテストして結果を返すだけでも貢献できる。

J:
 patchのテストはとても助かる。
 信頼も得られる。

カーネル開発で難しかったことは?

Q: (by James Bottomley)
 カーネル開発で難しかったことは何ですか?

F:
 そんなに難しいことはなかったですよ。
 SCSIはJamesがほとんどサポートしてくれましたし。
 SCSIは小さなコミュニティなので、何でも相談できました。
 カーネル開発ではそんなに困難はなかったですよ。
 メンテナによっては苦労するかもしれませんが・・・。

K:
 patchを書いてポスティングするのはそれほど難しくないですが。
 この会場でメモリホットプラグがほしい人はどれぐらいいますか?
  (パラパラと数人が手を挙げる・・・)
 ほら、そこが難しいところなのですよ〜

H:
 私はトレーサが専門で、変更範囲、量が非常に多い。
 最初のpatchを送ったときに、3000行もあって、
 メンテナがレビューもしてくれなかった。
 LKMLのカルチャーを学ぶことだと思います。


カーネルで注目してる分野は?

J:
 いまどんな取り組みをしているか。
 今後、カーネルにどんな期待をしていますか?

F:
 SCSIに関する面白いことがあるかを期待している。

K:
 mem_cgroupをやってる。
 メモリリソース制御に興味があるが、
 今後、io_cgroup、コンテナ(接続性)に興味がある。

H:
 Kprobeの取り組みをやっています。
 perf probeがまだ終わっていません。
 機能性の向上に取り組んで生きたい。

 あと、MCEに興味がある。
 これはCPUの機能です。
 エラーをメモリの中で捉えるものです。


なぜ、オープンソース開発をするのでしょうか?

J:
 なぜ、企業でオープンソース開発をやるのでしょうか?
 世界中に公開されて、競合企業も使いますが。

H:
 トレーシングは重要な部分です。
 たとえば、銀行のサーバーにおいて問題が起きたとき、
 その問題解決を急いでやる必要がある。
 このときにトレーサがあれば簡単に解決できる。
 トレーシングはツールに過ぎず、それを共有することができる。
 しかし、サポートのクオリティは、そのツールを作った人、知ってる人についてくる。
 企業にとっては大きなメリットになる。

K:
 私の部署は、プロプライエタリなシステムを出していて、
 上司は、そこに実装されていた機能の実装を求めてくる。
 あとは、顧客の要望だ。

F:
 顧客はLinuxを使っている。
 Linuxにはストレージ関連の強化が必要だ。
 だから、私はLinuxを開発してる。


オープンソースエンジニアの企業での評価は?

Q:
 みなさん、大企業で働いている。
 大企業は非常に保守的なことが多いが、OSS開発エンジニアは評価されているか?

F:
 Linuxは主要プロダクトであり、
 私の会社では適正に評価されていると思う。

H:
 私も評価されていると思う。
 LinuxがこれからのITシステムのインフラとみなされているので、
 適正に仕事が評価されている。

K:
 富士通は、日本のインフラを支える責任を担っている。
 それは、Linuxをさしていて、エンジニアは評価されていると思う。

何のためにカーネル開発をやっているのか?

J:
 Linuxを開発するのは、お金だけのためにやってるのではないです。

 ブラジルで、こんな議論があった。
 Andrew Mortonは人のためと答えました。
 Linusは自分のためにやってると言っている。
 しかし、Linus人のためになるのがうれしいと感じているからやってる。
 結局、2人は同じことを言ってると思いました。

 みなさんはどうでしょうか?

F:
 Linuxには非常に才能のあるプログラマがいます。
 そうした人たちと一緒に仕事をするのが楽しい。

K:
 NASALinuxが使われている。
 ということは、私の成果はNASAで使われている。
 OSSの仕事は世界の役に立てる。

H:
 藤田さんが言ったのと同じで、この業界には才能があっていい人がたくさんいる。
 これはどんなエンジニアにとっても、良い経験になります。
 みなさんも、是非参加してみてください!

日本人メンテナは登場するのか?

J:
 さっき、パネルの人と話していて、
 treeがたくさんあります。これがトップレベルのtreeにあげられる。
 日本の人たちがトップレベルのtreeのメンテナになることは考えられますか?

F:
 開かれてる状態と言ってもよいのではないでしょうか?
 メンテナンスの重要な役割は誰かがやっていて、

J:
 Jamesが他のことに興味があってSCSIメンテナをはずれるとしたら。
 藤田さん、やりますか?

F:
 できるならやりますよ!

H:
 現行のものを修正するのが得意です。
 すでにメンテナといえるのではないでしょうか。
 いずれかは、新しいトレースツールが出てくるかもしれません。
 いま、gitを使っているのは理由がある。
 日本の企業ではgitのポートも通さない会社も多い。

 内部と外部で2段階のレビューの仕組みがある。
 それで、私はgitツリーを使っていない

Q:(by James Bottomley)
 treeはたくさんあるし、メンテナは日々追加されているので、
 その機会はたくさんあると思う。

F:
 日本人がトップレベルのメンテナやっても問題ないと思います。


カーネルの開発は落ち着くことがあるのか?

J:
 別のカーネルパネルで出てきた質問ですが、
 いろんなシステムを取り込んでいくときに、開発速度が落ちてくると感じたことはありますか?
 2005年に、AndrewMortonがpatchペースが落ちてきていると考え、
 カーネルが完成に向かっていると予言したことがある。
 しかし、そのあとも変更が落ち着く様子は無い。

F:
 新しいデバイスが出てくる限りは続くでしょう。
 SCSIだけを見ても、ファニーなデバイスが次々と出てくる。
 SSDとか・・
 これを対応し続けるのは、世界中の人にとって良いことだ。

K:
 私も開発が終わることは無いだろうと考える。
 1つは、スケーラビリティ。
 1ソケット64コアのCPUが登場してくるらしい。
 そうなってくると、もっと問題が出てくる。
 現時点でのコードは、慎重に開発されているのでスケーラビリティが問題にならないかもしれない。しかし、いままでケアしてなかった部分でボトルネックが出てくるだろう。


H:
 GPUSSDはどんどん出てきている。
 誰かが新しいデバイス、テクノロジーを使っていると、
 新しい可能性を見つけるかもしれない。
 また、新しいユーザー、新しい利用形態が見つかっていく。
 ITシステムだけじゃなく、工場の制御システム、鉄道、交通
 新しいフロンティアは常に存在し、直面していくので、カーネル開発の余地はあるだろう。


これからもLinuxは続くのか?

J:
 これまでのコンピューティング産業を考えて、
 Linuxが他のものに置きかわる可能性はあるでしょうか?
 それとも、Linux Foreverか?

H:
 新しいOSを作るのは非常に難しいと思うが、
 たとえば、誰かが新しいOSを作るかもしれないが、
 やはりそれはオープンソースだと思う。

K:
 私が学生のときに一からOSを作った。
 非常に開発が遅かった。
 新しいOSもオープンソースになるのは確実だろう。

組み込み開発者を巻き込むには?

J:
 日本には組み込みの開発者がたくさんいると思う。
 会場に組み込みの開発者はいますか?
 こうした人たちはあまり見かけませんが?

F:
 理由は良くわかりませんが、組み込みの人たちには何か障害があるのだろう。
 別の世界に住んでるように見えます。
 前に比べると見かけるようになったが。

K:
 先日、富士通エンベデッドシステムからメールを受け取った。
 バックポートの相談だったが、6年間で初めてだった。

H:
 組み込みの中では特別なコミュニティがある。
 CELFとか。
 メインストリームのコミュニティとは違う。
 アップストリームのコミュニティに追いつこうという人もいる。
 Linuxは制御系にも入っている。


最新版カーネルと、製品カーネルとのギャップ

Q:
 実際に会社や製品で使われているカーネルと、現在開発されている最新カーネルとギャップを感じることが多いですが?

K:
 いつも感じてますよ。
 私のサポートしているシステムでもずいぶん古いカーネルを使っていることがあります。
 ギャップもフィードバックをしてくれれば、改善されるかもしれない。

H:
 たしかに、ギャップを感じる。
 そうしたギャップを感じさせるのは、我々の課題かもしれない。
 感じないようにするようにしなければならない。
 これは、組み込みの人たちにとっても大事だと思います。

patchが受理されなかったときの気持ちは?

J:
 カーネルコミュニティでpatchが受理されなかったときはどんな気持ちでしょうか?

K:
 patchを書き直して、認めてもらうようにするしかない。

H:
 リジェクトされた理由を考え、フィーチャーをプッシュする戦略を変えたりして何度も挑戦する。
 SystemTapなどは良い例で、まさにそういうことが行われた。
 現在、SystemTapをいれるために、Kprobeのダイナミックプローブを使っている。
 それも、戦略の一つで、私たちの要件を入れてもらったひとつの例だ。

自分たちの作ったLinuxガジェットが売られてたら感動しますか?

Q:
 秋葉原で最新のガジェットを買って、それにLinuxが乗ってたときの感動はどうでしょうか?

K:
 ガジェットはあまり買えないので・・・・。
 私の使えるお金はリソースコントロールされている。(※)

J:
 私の財布もスケーラビリティがないんですよ。

J:
 続きは秋葉原でビールを飲みながら。
 どうもありがとうございました。


  ※亀澤さんはプロセスグループごとにリソースコントロールをする
   「cgroup」を開発している。