Japan Technical Jamboree 28

= Special Notice / 注意 =
 * The epidemic condition of swine flu in west Japan area is calming. This event will be held as scheduled.
 * 関西に於ける新型インフルエンザの流行が沈静化してきました. このイベントは、予定通り開催出来る見込みです.

= Introduction / はじめに =
 * The Japan Technical Jamboree is a forum-wide technical meeting of the CE Linux Forum. This meeting will be located conveniently in Japan and use Japanese as the native language of the event.
 * A general guidance page is available. / 初めての方はこちらもお読みください.
 * JapanTechnicalJamboreeGuidance (Japanese/English)

Special remarks for non Japanese speakers

 * This page is Japanese/English bilingual. Please allow some contents on this page are not translated into English because of this event is Japan regional one, though we try to place English translation.
 * If you would like to perform your presentation in English, we also welcome you to join! We hope you to speak slowly without any complicated expressions.  Most Japanese developers are capable to understand plain English.

Previous Jamboree

 * Please look into the wiki page. / 下記のWikiページをご覧ください.
 * Japan Technical Jamboree 27

= Date and venue... / 日付・場所... =

Registration / 参加登録

 * Registration Page / 参加登録
 * Registration is only to forecast the approximate number of the attendees. No confirmation mail will be delivered.  It is not mandatory.
 * 参加登録は大まかな参加人数把握のためにお願いしています. 入力をされても確認メールは発信されません. 参加登録をしないで出席していただいても構いません.

= Main Topics =

= Agenda / 進行 =

Agenda

 * Please be noted above time table is just a gudeline and may be shifted. / 上記の時間割は目安です. かなり前後する可能性がありますので、あらかじめご承知おきください.

Special Remarks

 * Please place some detail descriptions about each presentation topics.
 * こちらに各プレゼンテーションの詳細などを記載してください.

Meeting Memo

 * Meeting Memo by "Maccya-Daifuku" Memo (Japanese)
 * Followings are donated by Fujimura san with many thanks!

ジャンボリーについて 上田さん / Sony ■　ジャンボリーについて ・CELFジャンボリーの活動は、海外でも注目されてきた. →レポートが英訳さてていて、メインラインの技術者も見ている. ・今回のWebサイト http://elinux.org/Japan_Technical_Jamboree_28 ・次回は7月17日 中野サンプラザ ・Japan Linux Symposium開催（10/21～23に東京） （The Linux Foundation主催） →「今年は重要な年」になる位置づけ 前日に、「カーネルサミット」がある. カーネル技術者がハイレベルでディスカッションする場. カーネルサミットの翌日なので、海外から来たエンジニアの ほとんどが集まるはず. 10/21のキーノートは、Linusが話をする. 翌日からのテクニカルセッションにも、組み込み向けのセッションが 多数あります. 8/1までに登録すると、$200（それ以降は$300） (8/31とお伝えしましたが8/1の誤りでした. )

Collaboration Summit Report about Moblin 天野さん / Miracle Linux ※Skypeで東京から講演. ■　Moblinとは ・Atomベースに最適化されたディストリビューション ・Intelから、コミュニティベースの開発に完全移行された. ■　天野さん ・ミラクル・リナックス ・moblinプロジェクトには、1年ぐらい前から参加 ・開発ツールのメンテナ ■　Moblin概要 ・Linux Foundation Collaboration Summit（LFCS）から ピックアップして紹介 ・モバイル向けLinuxプラットフォームを推進 ・フォーカスしているのはケータイ（MID） 車載、組み込みボードをターゲットにしている. ・プロジェクトの歴史 2007年7月にプロジェクト公開 ・moblin v1 　ubuntu（dev）のパッケージ管理 →パッケージコンポーネントとして提供 ・moblin v2 　RPMパッケージ管理 →ディストリビューションとして提供 ・2009年1月に、Intelが、LinuxFoundationに移管した. ■　moblin v1 ・GNOME mobileベース ・カーネル2.6.24 →チップセット用のパッチを提供 ・Xserver1.4 ・Ubuntu8.04ベース ■　moblin v2 ・ディストリビューション提供を考え、ソフトウェアモジュールを提供 -3Dレイヤー OpenGLベースのライブラリ ・カーネル2.6.29 -CONFIG_FASTBOOT=y ・Xserver1.6 ■　CONFIG_FASTBOOT ・SSD最適化（先読み機能（sreadahead）を最適化） ・カーネルカスタマイズ -デバイスモジュールは組み込み. （ロード時間の短縮） -ネットブック用や、MIDなどの提供形態 -非同期・並列初期化による高速化 ・initrdは使っていない. boot　splash無効 ・sysvinit ・グラフィックドライバxorg-x11-drv-intelの調整 ・起動時間はコールドブートで10秒ぐらい、ベータでは6-7秒になった. →目標は2秒 ただし、ブートローダーからの時間（BIOSは除外） ■　開発体制 ・Bugzilla，Git，メーリングリスト，IRC ・ベータがリリースされてから、開発が活発になってきた. ■　Pickups from LFCS ・LFCSはホテルで開催. 複数のセッションで、技術発表が行われた. （Intel中心） ・librest，mojito twitterやFlickerなどのソーシャルネットワークと、GUIを統合するAPI →つなげるアプリを簡単に作れる ・Connection Manager -モバイルシステム用のネットワークマネージャ -過去のネットワークマネージャは、様々な機能のため拡張が難しかった. バグはディストリビューターがPatchしていた. GNOMEに依存した実装など、問題があった. -このため、moblin用のネットワークマネージャを独自で作った. -有線LAN，無線LANなどをプラグイン化. -デーモンとして動くとメモリを食う. 必要最低限のリソースだけ使うように、デバイスごとにプラグイン化 -即時接続 -DNSはローカルホストを参照するなどの工夫 ・Clutter Project -OpenGLのライブラリを簡単に使えるように提供する. -3Dユーザーインターフェースライブラリ -ほかのGUIライブラリ、Webサービスと統合して実装できる. Qtライブラリ、GTKライブラリ、 Webブラウザ 物理エンジン これらを、clutterから統合して使える. Cでも作れるが、Python，C#などからbindして使える. ・Moblin SDK -KVM，VMWare実行イメージ USBブートイメージなどで提供 -ツール イメージ生成ツール LinuxProjectGeneratior（Autotoolsなどを簡略化して使える） -ドキュメント APIリファレンス，DevelopersGuide ■　将来の展開 -現在はネットブック向けに提供を予定しているが（09/Q3）、 来年あたりにMID向けにも提供 -次の世代のネットブック向け ■　日本での情報 ・日経Linux2008/09，2009年7月から連載 ・ITProの記事 ■　Q&A ・Atomアーキテクチャのサポートしているが、32bitだけか？ AtomはCore2と同じアーキテクチャを採用しているので、 64bitも対応できるだろう. 現状は、32bitのみ提供. ・debからrpmに移行した理由は？ ちゃんとした答えが返ってきてない. もともとのrpm，debの特徴もあるが、開発者がrpmが使いやすいと 判断したらしい. ・LinuxProjectGeneratior -組み込みは、機種展開、アーキテクチャのスケーラビリティがかぎになる. -コンフィグレーションの自由度（アーキテクチャ対応）や、 ビルドシステムのスケーラビリティ そして、イメージ生成ツールとの連携などは工夫されているか. ・Anacondaでカスタマイズ カーネルのコンフィグレーションはパッケージを組み込んだり、 アーキテクチャごとのext3ループバックイメージを提供 ・LinuxFoundationで、moblinのみのイベントも企画している. もう少し深いお話もできると思います.

TOMOYO Linux / TOMOYO Linux on Android 沼口さん / NTTデータ Giuseppe La Tonaさん / NTTデータ ■　最初に ・2.6.30リリース -TOMOYOのリーダー原田さんよりご挨拶. -TOMOYO Linuxがリリースされた. -日本で始めて、メインラインをやったら？といわれたのは、 CELFジャンボリーが最初. http://sourceforge.jp/projects/tomoyo/wiki/ThankYou -終わりではなく、スタート. メインラインを保っていく. 事業として確立する. -TOMOYOは、Linux進化の第一歩に入った. これからは、原田さんだけでなく、使う人たちが発展させていかなければならない. 組み込みでも、この発展に寄与できるものは、どんどんやっていきたい. ■　TOMOYO Linux（沼口さん / NTTデータ） ■　TOMOYO Linuxの概要 ・「つかいこなせて安全」なLinuxを ・カーネルパッチとユーティリティの２つから構成 ・ディストリビューションではない ・メインライン版 ・フル機能版 →LSMを使ってない、独自フックのもの ・RedHatなどのディストリビューションで開発が進む ・特徴 -「パス名ベース」で、ポリシー編集が簡単 -システムの起動から終了まで、「自動学習」 自分のシステムの把握にも便利. ・導入のメリット -被害の局所化 被害を限定できる -不正アクセスの検知 -誤操作防止 -情報漏えいの可能性を軽減 ・組み込み機器とTOMOYO -自動学習 テストケースがきまっていれば、動作させただけで、ポリシーを反映できる. -リンクの区別 シンボリックリンク，ハードリンクの区別 -ファイルシステムの制限が無い -省メモリ ４MBで動作 -2.4カーネルでも使える ・SE Linuxとの比較 -いろいろと違いがあるが、棲み分けができるもののはず ・たとえば、使い方 -Webサーバー 読み込み専用にしたりできる -アプリケーション 操作を限定できる. -ファイル 読み書き実行制御，名前空間制御 -ネットワーク IPアドレスなど ・利用の流れ -カーネル、ユーティリティをインストール ↓ 　-システム動作を学習 ↓ 　-自動作成されたポリシーを確認・修正 学習、修正を何回かまわす ↓ 　-運用 ・TOMOYO のポリシー ドメイン＋制御モード＋アクセス許可 -アクセス許可 ホワイトリスト方式 -ドメイン すべてのプロセスはいずれか1個のドメインに所属 -制御モード ・デモ SSHの動作制御 学習させたコマンドだけ実行できる ・Q&A -いちから動作をすべて網羅させるのは大変では？ →現状、システムテスト段階でポリシーを自動生成させるのが一番一般的な方法 あるサーバーシステムでは、2週間、テスト状態で放置し、すべてのプロセス、 CGIを網羅させる. -ハードが壊れたときのフェイルセーフの処理が走らないなどが懸念されるが、 回避策はありますか？ →2002年にやった導入事例では、フェイルセーフのプロセスを走るようにして、 対応していた. ただし、ハードの故障時の対応などは対応が難しいところもある. →ターボLinuxは最初にポリシーファイルが配られている. -ポリシーのノウハウがたまれば、配布も考えている. 現在も、wikiでポリシー募集しているが、いまはユーザーが少なく、 うまくまわっていない. →「こういうポリシーつくったよ！」があれば、教えてほしい. ■　TOMOYO Linux on Android（Giuseppe La Tonaさん / NTTデータ） -インターンでNTTデータの研究所で勉強中. -セキュアOSグループでTOMOYOを研究中. ・Android概要 -AndroidSDK1.5では、Linux2.6.27をサポート. 2.6.29も準備している ・Androidの起動プロセス -アプリケーションは、dalvikVMで動くJavaアプリケーションである. -ZygoteProcess zygoteProcessが、DalvikVMをforkし、アプリケーションが動く. zygoteがリソースを管理する、idleプロセスである. ・Androidのセキュリティモデル -すべてのプロセスは、DalvikVMの区切られたプロセスである. -すべてのプロセスは、「secure sandbox」である. -LinuxのDAC（アクセスコントロール）はall -アプリケーションには、ユニークなUIDが割り当てられる. -アプリケーションのデータは、/data/dataに、UIDのフォルダで区切られて管理される. ・AndroidのTOMOYOパッチ TOMOYOLinuxによるポリシーを用いて接続制御を行う TOMOYO Linux1.6.8(non-LSM)を適用 Goldfishエミュレータ（ARM）用のクロスコンパイル ccspatch1.6.8にパッチ →ccstoolsは、組み込み向けに、サイズ削減、ポリシーエディタの簡略化で対応 Androidには、ポリシーローダーとして、/bin/css-toolをインストール /data/css /system/css でセキュアなデータ，ファームウェアを管理 ・Androidのポリシーファイル UIDごとに異なるアプリケーションのドメイン制御が問題だった. すべてが、app_processになるため、アプリケーションごとのドメイン制御が難しい 解決策として、インターネットアプリケーションにくるタスクのUIDによって、 アクセス制御できるようにした. （例） allow_read/write @APP_DATA_FILE if task.uid=10001 allow_read      @APP_DATA_FILE if task.uid=10001-10002 ・デモ -ポリシーデーモンが動いている状態で、operaブラウザを動作させて、 ポリシーを覚えさせる. →ほかのアプリケーションがネットワークにつなごうとしても、 ブロックされることを確認. -toolboxのシンボリックリンクも、ポリシーエディタが ひとつのプロセスとして認識してくれる. ・動作環境 -カーネルメモリは43kbぐらいの増加 -ポリシーデータで80kb程度のハンドリング ・Q&A 後でインストールしたアプリが使うデータも、ワイルドカード指定などで、 編集可能な領域を指定できる. また、ネットワークアプリケーションのuid許可も、パス名で安全性の制御ができる. インテントの制御はできるか？ →ioctlの制御が複雑で、TOMOYOで追っかけるのは難しかった. ただ、一通り動かせば、アプリの動作は追えるはずなので、 それでポリシー制御をしてみては.

Linuxカーネル開発者予備軍のためのGitHowto 岩松さん / ルネサス ■　 どうやって、Gitにパッチを送るのかをテーマにした. ■　岩松さん ・SHのカーネル開発 ・SHブートローダーのメンテナ ・debianのメンテナ ■　Gitの基本的なコマンド ・Subversion（集中管理型）との違い リポジトリにコミットするには、コミット権が必要 ワーキングコピーを作る ・コミット、チェックアウトはローカルリポジトリへの操作 ・プッシュ、フェッチはリモートリポジトリへの操作 ・Git 作業者もリポジトリを持つ. ローカルでコミットして、リモートリポジトリにマージする. ・基本コマンド 14個（多い！）を覚えれば、すべて使える！ ワーキングコピー、index、ローカルリポジトリ、リモートリポジトリ. 4つのステージを理解すれば、動作の流れをつかめる. ■　Gitを使った開発の流れ ・流れ -パッチは、開発者の最新のコミットに対して修正を送る -カーネルでは、各機能ごとにメンテナがいるので、 メンテナンスしてるリポジトリに対して修正を行う. -メーリングリストにも送る. ・環境の設定 -名前とメールアドレス 「git config」で設定. システム全体に反映させる -リポジトリをコピーする SHアーキテクチャのGitリポジトリはMAINTAINERSファイルに書いてある. 「git clone」でコピーする -ローカルリポジトリではorigin/headsという扱いでリモートリポジトリの ブランチを管理する　※originはリモートリポジトリの状態 -cdでソースディレクトリに入る -不具合の修正をする 修正前と修正後のdiffをみる -修正ができたら、コンパイル、テストをする -コミットする 「git commit」 -sオプションは、Signed-offをつけるという意味 エディタが立ち上がるので、コメントを書く. Signed-offをつけると、名前とメールアドレスが入る. カーネルの場合は、メールのサブジェクトになる. 空行を入れて、次の行からがメールの本文になる. -git logでメッセージと差分を確認. 「-p」でコミットしたときの差分とメッセージも表示してくれる →これで、ローカルのブランチ（heads/master）が変更される. -修正している間に、リポジトリが更新されている可能性があるので、 状態をアップデートする. 「git remote update」 origin/masterブランチが変更される. →ここで、リモートリポジトリの状態に対して、rebaseを行う. 「git rebase origin」 mergeは、共通のコミットを探して、それに対して差分適応するので、 注意が必要. （普通は使わない. ） 　-メールに送るpatchは 「git format-patch」で生成できる. →メールのSubject，本文まで生成してくれる. -パッチをメールで送る 「git send-email」でOK. ■　最新機能を試す -最新のドライバとか、最新の機能とか -試す必要があるというか、試す必要がある場合がある （例）sh-2.6のリポジトリをベースにしたブランチにbluetoothの新機能を取り込む ・MAINTAINERSにgitリポジトリが書かれている. ・git remoteコマンドで、リモートリポジトリを追加する. git remote update bluetoothで最新の状態にアップデート git branchでmasterブランチを作成 git mergeで、blutooth/masterの状態を反映 git show headをすると、マージ情報も取得できる. →コンパイル、テストをする. ■　まとめ ・リモートリポジトリと、ローカルリポジトリを理解しましょう ・パッチを送るときには、rebaseして、最新のパッチを送るようにしましょう ・mergeとrebaseは使い分けましょう. ・知っておくと良いこと -Gitオブジェクトの仕組み -indexの動き -コンフリクト時の復旧方法 -git blame←誰がいじったか ■　Q&A ・過去の履歴を消すことはできるのか →消せるが、バージョン管理そのものが破綻する. 分散型なので、みんなのパソコンに残る. ・index（昔は、cacheと呼んでた）は、簡単に言うと、次のコミット候補といえる. ・リビジョン番号はあるのか？ →ハッシュ値しかない. ある時点での、名前（エイリアス）はtagで管理する. →とはいいながらも、40桁でやりとりするのは面倒なので、 LKMLでも、最初の8桁ぐらいで話をすることが多い. ・ハッシュ値がぶつかることがあると思うが. →日付とか、名前の情報を入れて、それを圧縮したファイルのSHA1ハッシュ値を 使うなどしている. ・Gitハブのような、Webフロントエンドはないか？ CGitなど、何種類かある.

Debianに新しいアーキテクチャを追加するには 岩松さん / ルネサス ■　岩松さん ・Debianに新しいアーキテクチャとして、SHを追加するために活動中 ・本日は、DebianのビルドシステムとDebianパッケージの作り方 ■　DebianProject ・自由なOSを目指すプロジェクト ・11個のアーキテクチャをサポート ・LinuxとFreeBSDをサポート ・ソフトウェアは同じバージョンでリリース AutobuilderNetworkが、全アーキテクチャのイメージをリリースしまくってる ■　Debianに追加するメリット ・ライセンスの問題がクリア ・パッケージポリシーが明確 ・バグの集約、パッチ、アップストリームとの連携が密 ・バイナリの提供、パッケージ配布のインフラが整備されている ・開発者の確保、CPUアーキテクチャサポート体制が整備されている. 世界的にみれば、5000人ぐらいの開発者がいる. ■　Debianに追加するデメリット ・ソフトウェアバージョンの依存 →新しいパッケージを導入するのは、メンテナ次第. ■　Debianのアーキテクチャサポート ・パッケージメンテナ -Debianパッケージのメンテナ ・Builddメンテナ -Autobuilder Networkとアーキテクチャ用のbuilddのメンテナンスチーム ★今回の話題 ・リリースチーム -Stableリリースを管理するチーム ・セキュリティチーム →バグ、セキュリティ問題に対応する. ■　Autobuilder Network ・Package poolに、最新のソースと、パッチがためられている. Wanna-build＆databaseをbuilddメンテナが管理 ・quinn-diffが、パッケージプールの状態を監視. 差分があれば、「need build」フラグを立てる ここまでは、全アーキテクチャ共通システム. 以下は、アーキテクチャ依存システム. ・Wanna-buildは、パッケージのビルド状態を管理 エラー、ビルド中、依存パッケージ待ちなどを確認. ・これを、実際にビルドするデーモンが走っているマシンが、 常にビルドをチェックしている. ビルド結果は、wanna-buildに通知する. →パッケージができたら、パッケージプールに置く. ・新しいアーキテクチャを追加するには、builddを備えたノードを設置する必要がある. ■buildd nodeを構築 ・最初はクロスコンパイル ・debuild　dpkg-cross，devscripts，equivsを使って、クロス環境でパッケージを構築 ・できないものはバグ報告 ・Buildd nodeに必要な環境 -build-essential ビルドに最低限必要なパッケージ（dpkg-dev，g++，libc-dev，make） -essental-packages ユーザー空間で必要なパッケージ郡 -その他Xlibなどに依存する. ■Buildd node完了後 ・Debian-ports MLで宣言 新しいアーキテクチャを追加したいことを通知 →DebianDeveloperのバックアップやこれまでの活動が大きく影響することもあり. ・debportsネットワークに追加される. ・あとは、自動でビルドされていく ■その他 ・90%以上動かないと、stableリリースされない. 現在、26000パッケージが提供されている. ・gccのテストは1週間ぐらいかかる. ■　まとめ ・昔はポーティングが大変でしたが、debportsによって新しい アーキテクチャサポートが大変でしたが、サポートが容易になりました.

Latest Kernel Development Status Watch 小崎さん ■　小崎さん ・カーネルWatchを書いてます. ・日本で数少ないLinuxカーネルジャーナリスト ・LKMLにもコミットしてます. -Signed-off-by数でTOP10%に入るぐらい -mm/ディレクトリ以下に限定すると10位 -Reviewd-byでは7位ぐらい ■　カーネルの開発状況 ・過去2年のコミット数推移 2年で2倍. 1万2千のパッチが1回のリリースで入る. →パッチ集計をcgiで更新して発表しているサイトがある. ・2.6.30のコミットレート -12000ぐらいのパッチ -組織別１８７の組織がコントリビュート. 一位はHobbyists -日本企業の順位が上がってきた. Fujitsu， Renesas（SH関連）， NTT（TOMOYO，ファイルシステム） -ディストリビューションベンダー、サーバーベンダーが強かったが、 組み込み関連の伸びが目立つ. ■　マージウウィンドウ ・3ヶ月に1回コミット ・中心となるツリー(Linus)からツリーが各々分かれており、 ネットワーク関連(davem/net-next-2.6)のものなど複数存在 ・最初の2週間だけ、機能追加のパッチを受け入れる. それ以降は、バグ修正しか認めない. ・調べてみると、マージウィンドウで9割程度が投稿される. →今の開発サイクルは、うまくいっているといえる. まだまだ開発が加速している状況 ■　サブツリー勢力図 ・Linusツリーに献上するサブツリーたち davem/net-next（デービッド・ミラー1440） ネットワーク関連. 無線関連が盛り上がっている. tipツリー（Ingoのツリー. 1270） 　　x86関連、ftraceまわり、redhatの都合などをマージしている. かなり広範囲. mmツリーなど（Andrew，975） mchehab V4L2 tiwai Audio関連 rmk →上位三大勢力と、各サブ機能ツリーという感じ ■　最近の注目パッチ ・Compcache RAMの一部をSWAPとしてみせかける SWAPに書くときに、圧縮してから書く. SWAP-lessのシステムで、メモリ空間が広げられる. 使ってないプロセスを退避させられるため、メモリ効率も良いはず. 独自でメモリ管理をつくってしまったので、まだマージが見送られている. メモリ管理を見てるひとから、説明を求められている. 目指しているところは合意がとれている. -開発者のホームページに、性能測定結果が掲載されている. Compcacheを使うと、プロセス増加に伴うメモリ増加がゆるやかになり、 高負荷のときでもメモリがあいている. 従来なら、メモリ不足で死んでる状況でも安定して動いている. -LZO圧縮 圧縮時間の短さを優先 ・カーネル圧縮の改善 -Support LZMA/BZIP2 -LZMAは、GZIPより30%圧縮率が向上. 展開時間も、GZIPより速い. 圧縮時に時間がかかるので、ユーザーのデメリットが無い. ・/dev/mem_notify on memcg →組み込み界隈からの投稿 →気づかれずにスルーされている. . 　　GregKHとgoogleのエンジニアは気にしているが、後回しにされている. -具体的な使用事例がちゃんと説明されたら入ると思う. 組み込みで使われているが、表に出せないといわれて出てこない. -Linuxは互換性が非常に重視されている文化. クズ機能でも、必死でサポートする. どんどん、機能をオープンにして、議論に参加しましょう. -組み込み屋さんは、1行でも良いので、「good patch!」を返すこと. それが、機能を生かす方法である. この声明には意味がある. ・Per-bdi writeback flusher thread -bdi（backing device information） メモリ管理に必要な情報がピックアップされた構造体. デバイスごとに内容が異なる. RAMDISKなら、キャッシュの必要がないとか、 tmpfsのダーティフラグ扱いなど、メモリ管理で参照する. ディスク1個につき、スレッドが1個できる. -いままでは、ディスク2-3個でも問題にならなかったが、 最近は、SSDとディスク混合などのシステムで、性能が大幅に低下. 全スレッドが一番遅いスレッドにつまる. デバイスごとのスレッド分割が基本的なアイデアだが、根本的な部分なので、 リグレッションの発生が入念にチェックされている. -Andrewが性能系を心配しているが、懸念が解消されたら入るだろう. ・VFS based Union mount -stackableなファイルシステム ReadOnryとReadWriteの領域をうまく利用できるので、 組み込みにメリットは多い. -AUFSはフレームウォーの結果、nackされた. 入らない. UnionFSは、VFSをいじると、100種類以上ある Linuxのファイルシステムを変えるのに抵抗があった. →もうしばらく議論が必要 ・reflink -ocfs2のシステムコールを追加したい. ファイルシステムから独立したcopy-on-writeの枠組み. -リンクコマンドでリンクをはるぐらいの速度でコピーできる. コピーパフォーマンスが向上する. ・devtmpfs -Devfs再び. 過去のDevfsは、ユーザー空間との連携がうまくいかない. -udevは、起動時にデバイスをスキャンして、デバイスファイルを作っていく. やっぱり、RAMDISKで速くやりたい. -カーネルの初期化は、先にドライバが動かないとできない. デバイスファイル用のファイルシステムを提供するアイデアだが、 またDevfsの再来かということで、フレームしている. ■　質疑 ・小崎さんの最大のフレームウォーは？ AppArmorが歴史的だと思う. LKMLは同じことを2回でてくるのを嫌う. TOMOYOは、過去にイメージの悪いパッチがあったので、たたかれた. ・LKML-embeddedにも投げたほうがよいか. 自分では判断が難しい. いろいろ投げたほうが良い. Andrewも、どんどんコメントくれといっている. ・クリストフとかアルビロの性格は？ 彼らの発言の過去ログを見るとかが必要. Andrewはすごい良い人. 反応してくれる人を指定するのが重要. ・mem_notifyのユースケースは、商品依存なので、非常に公開しにくい. デバイス依存の似たような機能は勝手に実装されている. 一度、そういった話を対面でして合意を得られれば、一気に入るかも.

最後に ■次回のネタ フラッシュファイルシステムのお話とか ■カーネルサミット In 東京 ・2009年10月 年に一回のカーネル技術者の集まり. 初のアジア開催 ・誤解しないで！ Linuxのロードマップが決まるわけではない. 組み込みも当事者である. →組み込みの要望は、ちょっとずつで良いので、どんどん出してほしい. ・なぜ東京か -多様性を求めて. 組み込み技術は注目されている. -日本の組み込みOSS技術者にとってチャンス ■　コミュニティーの意義 ・現代の組み込み機器は高級なOSがもはや不可避 -独自に作ってメンテナンスし、世界水準についていけるのか？ ・開発者視点から -世界最高峰の技術と触れ合うチャンス -最高峰に見てもらうきっかけを作るチャンス -セッションの提案を積極的にチャレンジしませんか ■　その他 ・LKML-embeddedとCELF-devの使い分けは？ 技術的なネタは、LKML-embeddedにどんどん投げてください. CELFdevは、そこに投げにくいものを気楽に投げてください. ・イベント開催のやり方などの提案もどうぞ. オンラインでつないで会場間をつなぐなど.

= Ask for your help / お願い =

Presentation Materials

 * We wish you to prepare the materials in English. / 出来るだけプレゼンテーション資料は英語で表記してください. 絶対ではありませんが、日本語が理解できない方に対しての配慮が出来ればと思います.
 * Please leave your material in this wiki site after the event. / ジャンボリー終了後、プレゼンテーション資料はこのWikiに残してください.

English Translation Volunteer

 * If you can help the translation volunteer from Japanese to English, we would be very much appreciated! / 日本語を英訳していただくボランティアを大歓迎します！