Japan Technical Jamboree 28

From eLinux.org
Revision as of 00:39, 17 June 2009 by Sat U (talk | contribs) (Meeting Memo)
Jump to: navigation, search
HeadTitleOsaka.gif
Date: June 12th / 日付: 6月12日(金)

At Shin-Osaka Station Hotel Annex / 於、新大阪ステーションホテルアネックス

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. / 初めての方はこちらもお読みください。

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

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

StationHotel.JPG

  • Date June 12, 2009
    • Starting at 10 am
  • At Shin-Osaka Station Hotel Annex / 会場 新大阪ステーションホテルアネックス
  • Admission: Free of charge / 参加費用: 無料
  • Not limited for CELF members. / CELF会員以外も参加・セッション持ち込み共に可能
  • Coordinators / 世話役 (Your inquiries in English welcome)
    • Hisao Munakata / 宗像尚郎 (munakata_dot_hisao(a)renesas_dot_com)
    • Shinsuke Kato / 加藤慎介 (kato_dot_shinsuke(a)jp_dot_panasonic_dot_com)
    • Satoru Ueda / 上田理 (Satoru_dot_Ueda(a)jp_dot_sony_dot_com)

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

Time Title and presentor Notes

Presentation Materials

10:00am..
  • Opening and Selfintroduction / 連絡事項・自己紹介
10:30am..
  • Collaboration Summit Report about Moblin (By M. Amano / Miracle Linux)

Video Session
Pdf File (mostly in English)

11:30am.. Lunch break
12:30pm..
  • TomoyoLinux on Android (with demo) (By Daisuke Numaguchi, Giuseppe La Tona/ NTT DATA)

Video 2

Video 3

13:30pm..
  • Git howto (Nobuhiro Iwamatsu/Renesas)

Video

14:30pm..
  • Load to add new architecture in Debian (Nobuhiro Iwamatsu/Renesas)

Video

15:00pm.. (Break)
15:30pm..
  • Latest Kernel Development Status Watch (Kosaki)

Pdf File (with English annotation) Video

16:30pm.. Lightening Session / 飛び入りの時間です
17:30pm.. (we are calling for your session proposals / セッション提案募集中) Japan TJ Session Proposal
  • Please be noted above time table is just a gudeline and may be shifted. / 上記の時間割は目安です。かなり前後する可能性がありますので、あらかじめご承知おきください。
  • Meeting Memo by "Maccya-Daifuku" Memo (Japanese)

Special Remarks

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

Meeting Memo

  • Thanks to Fujimori san
------------------------------------------------------------
ジャンボリーについて

上田さん / 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/31までに登録すると、$200(それ以降は$300)
------------------------------------------------------------
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を
・カーネルパッチとユーティリティの2つから構成
・ディストリビューションではない
・メインライン版
・フル機能版
 →LSMを使ってない、独自フックのもの
・RedHatなどのディストリビューションで開発が進む

・特徴
 -「パス名ベース」で、ポリシー編集が簡単
 -システムの起動から終了まで、「自動学習」
  自分のシステムの把握にも便利。

・導入のメリット
 -被害の局所化
  被害を限定できる
 -不正アクセスの検知
 -誤操作防止
 -情報漏えいの可能性を軽減

・組み込み機器とTOMOYO
 -自動学習
  テストケースがきまっていれば、動作させただけで、ポリシーを反映できる。
 -リンクの区別
  シンボリックリンク,ハードリンクの区別
 -ファイルシステムの制限が無い
 -省メモリ
  4MBで動作
 -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=001
  allow_read       @APP_DATA_FILE if task.uid=001-002

・デモ
 -ポリシーデーモンが動いている状態で、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によって新しい
  アーキテクチャサポートが大変でしたが、サポートが容易になりました。

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! / 日本語を英訳していただくボランティアを大歓迎します!