Hisao Munakata, Executive Manager at Renesas
Linux財団のほうでごにょごにょしている。
Renesas ルネサスの人。イケハヤがいたところ。
三菱、日立、NECが最初に立ち上げた半導体の会社。
ARM Linux(ルネサス)
M32R Linux(三菱) SuperH Linux(日立) V850 Linux(NEC)
今ARMがあつい
our development targe is the upstream kernel
自分はもともと日立にいた。自分たちのアーキテクチャを持っていた。
Latest stable kernel 3.14.4
最新のカーネル
IBMとGoogleの間でエンジニアの数が多い。
ルネサスだけでなく他の企業もカーネル開発に参加している。(10番目)
マイクロコントローラカンパニーの立ち位置の中でLinuxを開発している。
なぜそれをやっているのか。
Here we can see the result of intensive effort to control mushrooming of support CPU architecture
2006年あたりにarchを統合した。
クリーンなストラクチャーを作る。
同じようなことがARMでも起こっている。
ARM 2006→2014 20万→80万
リーナス「ランダムにコードを入れるな」
コントロールできることがLinuxの重要なところ。
arch/sh 10万以上のコードおリリース
でも、ARMの方向へと動いている。企業としてではなく趣味としてやってきてた
arch/bloackfin 2011からサポート開始。2014年からサポートを開始しているものもある。
リーナス「新しいチップに新しいフレームワークが出来るの嬉しい」
こういう動きはすごく健全だと思っている。
Where is the LInux technology road-map? Who is resposible for analyze and fix the problem? I can see the governamce mechanism in OSS?
OSSのメンテナンスの方法が、新しい人たちにとって混乱を招いている？
Linux newbie feels confused for OSS methodology
誰が責任を持っているのか。
オープンソースはこういう哲学でやっているので、若い人にとっては分からないと 言われてしまうことが多い。
ボールがランダムに動くイメージで、コーディネーションもなく動いている。
業界の人がどのように開発しているのか。
Open source community developer looks moving randomly. There seems no shared goal.
I know product development is a really hard work.
スケジュールが決まってる。コストも決まっている。 毎日残業で、競合が激しくて、なので常に付加価値を高める必要がある
ゴールが決まったプロダクトは、再利用が難しく、Fixも難しい。 故に、製品開発には妥協が生まれがちである。
次の世代の製品には使えない。
OSSの世界を検証せずに開発をしようとするから、車輪の再発明が起こってしまう。
たくさんのFix 816 すべてのカーネルが長期にメンテナンスされているわけではない。
minor versionでbugfix
migration circle every 70 days ブランチが別れ、小さなボールが生まれ、不要なものは放棄されていく
long-term stable line
どうやってどれを長期のものにしていくのか？
ルールがあるが、正確なガイドラインはない。
pick one kernel per year for long-term stable candidate
1年に1つの安定版を候補として残す。
vendor tree vs. upstream first, which helps you?
長期の安定ライン
new featureを追加したvendor codeはコンフリクトが起こりがち
新機能は新しいバージョンに追加すべきである。
LTSI new mechanism to create the production kernel
LTSI サイクルにプロダクションコードで使う。
community LTS + industry demanded extra patches
業界の人が新しい機能を追加する。
- comply with upstream rules
- industry friendly acceptance (flexible patch forms, etc)
業界の人はすごく頑張っているので、その声を聞くことに寛容である。それがLTSIプロジェクト
production developer
- clear goal
- various restriction
- business oriented
- competition
- accept compromise
community developer
- continuous effort
- collaborative work
- code portability
- 透明性
- 妥協しない
Linuxは銀河。銀河の中から☆が生まれる。我々は、小さなボールに投資をすべき
BSP creation proedure Upstream LTSI
メリット
- レビューしてもらえる
- イノベーションが生まれやすい
課題
- 時間がかかる
- 汎用性がなければならない
結論
- ルネサスはアップストリームのために頑張ってきた
- それは企業の開発にも通用するメカニズムである
- 自分で開発する前にコミュニティの開発したコードをチェックすべきである。
