サーバー仮想化担当 James Bottomley
いろんな変わったアーキテクチャを共有している。
- Kernel Developer
- SCSI Subsystem Maintainer
- PA-RISC architecuture Maintainer
- Linux Foundation TAB
not John Corbet
Community Health
現在のカーネルについて
Relased kernel 3.14 last year 3.9
73076 Change(パッチ) from 3632 Authors
Linusの管理もうまくいっている
うまくスケーリングできている。
カーネルに一緒に入れるツールとかを除外すると…
excluding staging and tools 65464 Changes from 3407 Authors (素晴らしい数字！)
Staging and tools accounts for 10.4% of the total commits with 555 Authors, 255 working exclusively
28731 files changed, 3691072 insertions 1748959 deletions
カーネルのサイズは17270921行 カーネルサイズもどんどん増えていっている
毎年100万行くらい追加されている
OpenStack already passed the kernel in active contributions
OpenStackのコミットがカーネルのChangeを上回った
John Corvet Chasing Brake Lights
Linuxのカーネルは他を追いかけているのか、それとも他を先行しているのか
面白いSubsystem SCSI Subsystem Changes
Well, while we're on the subject: immutable biovecs
SCSI用のノートPCで動かせる時代がいつ来るのか
Security
In March, it had been a great year for security
No Significant Vulnerability Problem
In May, not so much(例のOpenSSL heartbleed よく知らないジャーナリストがLinuxはクソとか書き連ねた)
TTYのサブシステム問題
アラン・コックス
問題のあるものを本番カーネルに入れてしまうのは常について回る問題
Cを使うのをやめるまではこの手の問題は続くであろう。
いつか「セキュリティは完璧である！」と言いたいけど、 そんなことをいう輩は信用できない。
完璧なセキュリティは存在しない。
Containers
Since 2011 been working on Container API Unification(パラレルズとかGoogleとか独自のAPIを持ってた)
これ以降複数の会社が協力してAPIを統一しだした
Kernel memory accounting
Last missing feature is kernel memory accounting (est 3.16)
メモリマネジメントサブシステム
全てがうまくいっているわけではない。
先月のメーリスでも衝突していた。
Different Container tools sitll do the same actions differently
様々なツールが使える 同じアクションであるべきものを違うやり方でやっている。
Specific problems are devices
How do containers make devices appear?
Project in from the host or virtualize devtmpfs(どうやって仮想化するの？→仮想化しない)?
ポリシーをカーネルに埋め込むのは非常に悪いアイデア
Nasty mess: devtmpfs, like devfs before it embeds policy in the kernel
サブシステムの仮想化するためにはそのための方法が必要である。
Container virutalisation is simplest when the policy is injected from the outside.
ポリシー自体を仮想化しないといけない
こういうことをするとコードが爆発してしまう。
2009年には戻れない
If you have to virtualise internal policy, the code just explode
mounts
どうやってマウントするの？
コンテナのなかにどうやって
別の方法が必要
Some container mounts (like / proc or secondary devices) become bind mounts
Ideal may be to vector mount request to host and have it decide policy
Need to agree on single best practise for all containers and code for that
一緒になって1つのコミュニティになるのがベストプラクティス？
Containers are still the success story of Linux
Dockerは新しいストーリー
コンテナではなくアプリケーションとしてコンテナを活用する。(今年の大きな成功)
No other operating system even comes close
CONFIG_HOTPLUG is finally dead
No Architectures really care about not defining it
CONFIG_HOTPLUG いろんなセクションがある CPUとか。 きちんとしたラベリングが必要となってしまう。
but we had an elaborate set of test machinery for enforcing it
Essentially it was a vast make-work project for the kernel
余計な作業が増えてしまってメンテナーにとっては負担
250くらいのパッチ
Goodby and please don't bother to write
メンテナーにとっては本当にたるい。
Kernel Patching
No fewer than three new projects to replace ksplice
Ksplice：Oracleの考えるOSのセキュリティ (オラクルエンジニア通信 - 技術資料、マニュアル、セミナー)
思った以上に複雑な問題
Oracleが買収
kspliceのパッチを作るのは本当にしんどい
kgraft and kpatch is similar
パッチの作り方、複雑性の問題
どっちも触りたくない
Both produce a patch as a module in a similar way and insert into a running kernel (difficult, no major version upgrade)
パッチが作れないものもある。
大きなバージョンアップグレードも出来ない
Slight advangge kgraft doesn't have to stop the kernel while patching.
Rebootless Kernel Updates (Parallels)
パッチを作るのに時間がいらない
Just replaces old kernel with new one using checkpoint/restore
Does zero copy of the in-memory image via a capsule
カーネルの状態で構成する
早い時は数秒、2秒
外からカーネルを操作
Can upgrade major version 3.2→3.10
slight service interruption (few seconds ) while kexec ing to new kernel
よいalternative
Could Storage Performance
5%のカーネル開発者にとってはどうでもいい箇所
クラウドに乗っかりたい人にとりストレージの早さは重要
Most Cloud Storage systems use FUSE
Except CEPH which use its own RBD
先週OpenStack
カーネルサミット8月
だいたいFUSEを使ってる
カーネル内にシステムを入れる
FUSEがすごい遅い問題
バックエンドでキャッシュが起きていない
3.14で加速パッチを用意した
これによりすべてのクラウドシステムがかなり素早くなるはず
すっごく遅いファイルシステムが50%くらい早くなる
逆にCEPHが相対的に50%遅くなる
UEFI
MSが数年前に全てのマシンにこのインターフェイスを搭載することを宣言
Now mostly just works(run)
most recent fix was kexec (now works with UEFI) kexec UEFI Secure boot patches still not in (物議を醸しているため、まだ入っていない)
MSが機嫌を損ねる
理想的なSecure Boot System
MS向け
妥協案としてSecure Bootはやる。MSがboot systemに署名するのを気にしない
Linuxセキュリティ改善にすすめられる
Conclusions
Linux is leading the wolrd in relevant innovations
なんだかんだでメディアの中心にいる
LinuxがなかったらMSはヘンテコなシステムを世界中に提供してしまっていた。
その他のOSが引き続きブートできる。
MSさえも意のままにできるLinux
No other Operating System comes close
Everyone else eats our dust
Presented using impress.js by Bartek Szopka
今や俺はweb開発者
質疑応答(追記)
寄る年波には勝てぬ。(超意訳)故にLinux Kernel Reportのプレゼンは後進に任せたい
