format-patch」で生成できる。→メールのSubject,本文まで生成してくれる。send-email」でOK。-試す必要があるというか、試す必要がある場合がある(例)sh-2.6のリポジトリをベースにしたブランチにbluetoothの新機能を取り込む・MAINTAINERSにgitリポジトリが書かれている。remoteコマンドで、リモートリポジトリを追加する。headをすると、マージ情報も取得できる。→コンパイル、テストをする。まとめ・リモートリポジトリと、ローカルリポジトリを理解しましょう・パッチを送るときには、rebaseして、最新のパッチを送るようにしましょう・mergeとrebaseは使い分けましょう。→消せるが、バージョン管理そのものが破綻する。分散型なので、みんなのパソコンに残る。・index(昔は、cacheと呼んでた)は、簡単に言うと、次のコミット候補といえる。→ハッシュ値しかない。ある時点での、名前(エイリアス)はtagで管理する。LKMLでも、最初の8桁ぐらいで話をすることが多い。・ハッシュ値がぶつかることがあると思うが。CGitなど、何種類かある。・バイナリの提供、パッケージ配布のインフラが整備されている・開発者の確保、CPUアーキテクチャサポート体制が整備されている。世界的にみれば、5000人ぐらいの開発者がいる。→新しいパッケージを導入するのは、メンテナ次第。→バグ、セキュリティ問題に対応する。poolに、最新のソースと、パッチがためられている。・quinn-diffが、パッケージプールの状態を監視。ここまでは、全アーキテクチャ共通システム。以下は、アーキテクチャ依存システム。エラー、ビルド中、依存パッケージ待ちなどを確認。常にビルドをチェックしている。ビルド結果は、wanna-buildに通知する。→パッケージができたら、パッケージプールに置く。・新しいアーキテクチャを追加するには、builddを備えたノードを設置する必要がある。-その他Xlibなどに依存する。→DebianDeveloperのバックアップやこれまでの活動が大きく影響することもあり。・debportsネットワークに追加される。・90%以上動かないと、stableリリースされない。現在、26000パッケージが提供されている。・gccのテストは1週間ぐらいかかる。アーキテクチャサポートが大変でしたが、サポートが容易になりました。小崎さん・カーネルWatchを書いてます。・日本で数少ないLinuxカーネルジャーナリスト・LKMLにもコミットしてます。1万2千のパッチが1回のリリースで入る。→パッチ集計をcgiで更新して発表しているサイトがある。-組織別187の組織がコントリビュート。-日本企業の順位が上がってきた。組み込み関連の伸びが目立つ。・最初の2週間だけ、機能追加のパッチを受け入れる。それ以降は、バグ修正しか認めない。・調べてみると、マージウィンドウで9割程度が投稿される。→今の開発サイクルは、うまくいっているといえる。無線関連が盛り上がっている。tipツリー(Ingoのツリー。x86関連、ftraceまわり、redhatの都合などをマージしている。SWAPに書くときに、圧縮してから書く。SWAP-lessのシステムで、メモリ空間が広げられる。使ってないプロセスを退避させられるため、メモリ効率も良いはず。独自でメモリ管理をつくってしまったので、まだマージが見送られている。メモリ管理を見てるひとから、説明を求められている。目指しているところは合意がとれている。-開発者のホームページに、性能測定結果が掲載されている。高負荷のときでもメモリがあいている。従来なら、メモリ不足で死んでる状況でも安定して動いている。-LZMAは、GZIPより30%圧縮率が向上。展開時間も、GZIPより速い。圧縮時に時間がかかるので、ユーザーのデメリットが無い。→気づかれずにスルーされている。GregKHとgoogleのエンジニアは気にしているが、後回しにされている。-具体的な使用事例がちゃんと説明されたら入ると思う。組み込みで使われているが、表に出せないといわれて出てこない。-Linuxは互換性が非常に重視されている文化。クズ機能でも、必死でサポートする。機能をオープンにして、議論に参加しましょう。patch!」を返すこと。それが、機能を生かす方法である。この声明には意味がある。メモリ管理に必要な情報がピックアップされた構造体。デバイスごとに内容が異なる。tmpfsのダーティフラグ扱いなど、メモリ管理で参照する。ディスク1個につき、スレッドが1個できる。最近は、SSDとディスク混合などのシステムで、性能が大幅に低下。全スレッドが一番遅いスレッドにつまる。リグレッションの発生が入念にチェックされている。-Andrewが性能系を心配しているが、懸念が解消されたら入るだろう。組み込みにメリットは多い。-AUFSはフレームウォーの結果、nackされた。Linuxのファイルシステムを変えるのに抵抗があった。-ocfs2のシステムコールを追加したい。ファイルシステムから独立したcopy-on-writeの枠組み。-リンクコマンドでリンクをはるぐらいの速度でコピーできる。コピーパフォーマンスが向上する。過去のDevfsは、ユーザー空間との連携がうまくいかない。-udevは、起動時にデバイスをスキャンして、デバイスファイルを作っていく。RAMDISKで速くやりたい。-カーネルの初期化は、先にドライバが動かないとできない。Devfsの再来かということで、フレームしている。AppArmorが歴史的だと思う。LKMLは同じことを2回でてくるのを嫌う。TOMOYOは、過去にイメージの悪いパッチがあったので、たたかれた。・LKML-embeddedにも投げたほうがよいか。自分では判断が難しい。Andrewも、どんどんコメントくれといっている。彼らの発言の過去ログを見るとかが必要。Andrewはすごい良い人。反応してくれる人を指定するのが重要。・mem_notifyのユースケースは、商品依存なので、非常に公開しにくい。デバイス依存の似たような機能は勝手に実装されている。一度、そういった話を対面でして合意を得られれば、一気に入るかも。年に一回のカーネル技術者の集まり。Linuxのロードマップが決まるわけではない。組み込みも当事者である。→組み込みの要望は、ちょっとずつで良いので、どんどん出してほしい。組み込み技術は注目されている。技術的なネタは、LKML-embeddedにどんどん投げてください。CELFdevは、そこに投げにくいものを気楽に投げてください。・イベント開催のやり方などの提案もどうぞ。オンラインでつないで会場間をつなぐなど。出来るだけプレゼンテーション資料は英語で表記してください。絶対ではありませんが、日本語が理解できない方に対しての配慮が出来ればと思います。ジャンボリー終了後、プレゼンテーション資料はこのWikiに残してください。eLinux.orgDisclaimers。