by shigemk2

当面は技術的なことしか書かない

Linux Kernel Report #linuxcon

サーバー仮想化担当 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のプレゼンは後進に任せたい