Attendee

原木、黒川、田口、丸山、山口、上村、たにかわ、光成(敬称略)

場所

WebEx

日時

11/6(水) : 13:30 - 16:30

AMM議事内容

原木さん(キーノート)
山口さん
- CAN に関しては、ユーザ空間ライブラリの役割をきかれた
- OBD2といった標準フォーマットと独自の境界がどこか、という質問がきて、SocketCANのレベルでは独自データを流してユーザ空間ライブラリのところで、OBD2などに変換するという回答をした
谷川さん
光成
- Warning Buzzarが機能安全の対象になるときは、IVIの音がうるさすぎて安全侵害する可能性があるのでは？その場合は、Safety側からIVIの音を強制的にミュートにするなどの処理が必要という指摘があった。(AudioKineticのフランソワからの指摘)
  - これは利便性にかかわることであって、機能安全には関係ないと考える
山口さん Safety Critical Summit
- ELISAとのコラボ
  1. Function Safetyの分析
  2. QM対応したオープンソースのソフトウェアスタックの作り方
- ClusterのASILは他のASILの警告を通知するための端末、という位置づけ
- AGL側でミニマムセットを打ち打さないといけない

今後のスケジュール

日時	内容	TODO	Remark
10/9	IC EG meeting
10/11	ボードセッションのアウトライン
10/21	事前打ち合わせ
10/22-23	AMM	キーノート Session x 2
10/24	SAT	IC EG Update 1h	前回残った話(IC EG core profile, branch)
10/31	Open Source Safety Critical Summit	ELISAと話す	山口さんがCFPを出している→ 採択されました。おめでとうございます。
11/5	IC EG Call
11/6	IC EG Tech Meeting 13:30 - 16:30
11/11 - 13	Integration Session(SC)	CES #3? 各社デモ	IC EGがFundする
11/19	IC EG Call
12/3	IC EG Call
12/10 - 12	hackfest/CES Integration session in San Francisco	CES #3? 各社デモ?
12/?	発送
1/7 - 10	CES

進捗の確認

Sound

特に進捗なし
- PulseaudioのAuthenticationでパーミッションエラーが発生している
pipewireに切り替える(unicense)

Graphics

コンテナ上でwayland backend でwestonを動かすことを試す
- 11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
  ＝＞QML Scene使って、IVI-shellの問題かWMの問題か切り分ける。直近はwayland-backendでの課題に注力する。
- https://lf-automotivelinux.atlassian.net/wiki/download/attachments/17990299/2020ces_agl_ces3demo_20191106.pptx?api=v2

Ethernet

LXC
meta-verbalizationのレシピが古いので最新に切り替える。

今後

AMMに向けての振り返り
今後の活動
- CESデモの状況の共有
★各社分担した作業を行う
- 複数社にまたがる仕事について : リーダを決めてリーディングするか、話し合って決めるか
- Fundingを使う場合、見積もり、RFQを出す必要がある
  - テンプレはWaltからいただいている
  - 進め方を相談したい。
  - 意見
    - 誰と話せばいいかを決めてほしい
    - SCでIC EGのFundingの話がある
      - やりたいことのイメージはネタとしてもっておいたほうがいい。
    - Fast bootは日下部さんに1枚絵を描いていただく
    - いつまでにアーキテクチャに対応したコードを出すか決める必要がある。
Requirement SpecはCluster EGが範囲
- 3月くらいまでにほしい
製品化のライフサイクル & Product Readinessとは何か
- ハードウェアの依存性など
  - 現在E3でSpecが分かっているが、普遍的ではない。何年くらいで更新していくか
  - カーネルバージョンへの対応
- オープンソースを利用したメンテナンス(同じSoC)、次の世代の切り替えをどのようにしていくか、の議論が不足している。
  - メンテナンスポリシーは各社で異なる。
  - オープンソースを大きくチューニングする会社もあれば、できるだけオープンソースを変更しない会社もある
- メンテナンスの言葉の定義が必要
  - 様々なユースケース(Securityパッチ、カーネルバージョンアップ、顕在化したバグフィックス、機能拡張など) があるので、細分化して議論していく必要がある
  - ディスカッションの機会を作成して議論を深めていく
  - クラスタを中心としたシステムに対して、どのようなメンテナンスが必要なのか考える。
  - LTSや製品Readyとは何か。
- IntelはHardwareが共通化されているが、ARMはHardwareが変わるとソフトウェアに影響が出る。
AMM(3月)
- AGL側でLSBのようなミニマムなスタンダードが必要だと打ち出す

マイルストーン(Implement Goal)

2019.12 RFQ
2019.2 Start development
2019.6 Cluster Container

時期		備考
2020.3	Cluster Service(API) Container Management Spec Reference design(絵) Requirement Spec	APIの決定
2020.6	QMの考え方 Cluster container Privilege Host Container Management Imple(CAN) Fast boot
2020.8	Sound Window Sample Cluster Service IVI container

QM : 考え方

次回

12/4(水) 13:30 - 16:30

=== Appendix 10/8の議事 ====

F2F ミーティングの議事内容

https://wiki.automotivelinux.org/agl-distro/sep2019-f2f

9/24 Pre-meeting

目的 : Continental, Volkswagen, Bosch のメンバとコンセプトの共有

コンテナアーキの方向性を共有
- 2日目の話をする前に状況を理解してもらう
VolksWagen, Continental, Bosch に方針を理解していただいた
- Low AGL target is full digital cluster
- Lowをターゲットにしているが、Highにも適用可能である
- LinuxのDevelopmentをマネジメントすることは難しい。Safetyを担保できない
Reference HardwareにはすべてのHWが含まれているか?
- Autosar(CAN)の実装はLinuxの外にあるべき
- CANの応答(reply)性能を守れるか、が大きな課題になる
vxcanはいつからKernelに入っているか?
- 4.14から入っている
SafetyとNon Safetyの切り分け
- Micro kernelの考え方
  - QNXはMicro kernel
  - Integrityはちがう
コンセプトをFixしたらどう進めていくかが気になるとのこと

　　ちなみに

　　水山氏がAMM 2日目にキーノートでMain FunctionとIsolation Method(Hypervisor)のインターフェイス(virtio)に使えるAPIの標準化の話をする。

Virtualization Groupとの連携は?

→ Opensynergyの人と繋がる。ELISAもつながりそう。

9/25 Instrument Cluster EG Update

資料
- Document storage
この資料をベースにAMMのキーノートを作成する
- ただし、デベロッパー向けの資料などは削除する
AGLはyoctoを利用し、IVI Core Imageを作成している。クラスタのCore ImageはIVI Core Imageと異なる
- branchという言葉でmeta-aglのbranchだと思われた。
- pokyの継承はしないかもしれない、ということを伝えればよかった。
- (pokyを引きずった時点でIVI前提になる)
- meta-xxxx を否定しない
Non Safetyが2つに分かれると困る(QM 分割) を早めに伝えるべきだった。
- 改善案 → AGL All Member Meeting 2019 Europe
KernelのQM対応については、ELISAとコラボすることを伝えた
Kernelだけでなく、ユーザ空間の基本的なSWスタックもELISAとコラボすることを伝えるべきだった
QM Isolationをコンテナでやる理由が弱い
- Hypervisor
- Linuxを並べる無駄さと複雑性の増加をうまく説明したい
- メリット : Linuxで並べるなら、アプリケーションコンテナを扱うほうが手軽 => コストが安くなる。HypervisorだとToo much
- メリット : 大きなシステムを分割できる。一方、Hypervisorは分割された違うシステムをインテグ。
- Hypervisorでやるとしんどいことが経験則でしかない。インテグレーションコストが大きい。特に密結合するようなアプリケーション

9/25 CES 2020

資料
- https://wiki.automotivelinux.org/_media/agl-distro/2020ces_agl_ces3demo_20190924_v2.pptx
CES #3のデモにContainerを利用したデモ
たにかわさん LEAD

9/26 Instrument Cluster Architecture

資料
- Document storage
Container Architecture
CAN
- 質疑
- Implementの方法(CAN proxy)
  - CAN ProxyがKernel空間にある案を採用する
  - SPI(shm)
- 車両信号のルーティングのAutosarの仕組みを教えてもらった
  - PDU(https://www.autosar.org/fileadmin/user_upload/standards/classic/3-0/AUTOSAR_SWS_PDU_Router.pdf)
  - 外にCAN Communicatorを置く場合は、上の資料を参考にするといいとのこと
Graphics
- 質疑
- Nested Compositor
  - 描画の機能を保つために、Low levelにひとつHW Compositorが必要
  - HWに依存する。
  - DRMでうまく抽象化してもらえるとありがたい。
- monolithic の Graphic Architectureも使える、ということを伝えるべきだった。
  - コンテナでグラフィックスの話をすべきでないかもしれない。
Sound
- 質疑
  - 1コンテナに複数のアプリがいたときはどのようにするのか? → 説明が足りていなかったので、Soundに追加しました。Sound
    - Roleのことを触れていた。識別できるかを気にしていた。
  - Authenticationについてジョージから提案あり → Soundに追加しました。
  - Walt : Pipewireを使う? → PulseかPipe、どちらでも可
  - パフォーマンスのRequirementに触れないといけない。
  - エコキャン/ノイキャンありき
  - AGLのApplication Frameworkのセキュリティモデルに従ってアーキテクチャを作成する
    - そこから実装手段
  - Audio Focusの話に触れていない
    - AGL All Member Meeting 2019 Europe
  - Authenticationは入れなくてもいいのではないか。

AMMに向けた活動

Keynote

Status
- 原木さんが発表する
- いつ?? → まだ決まっていない。2日目の予定
- 話の流れは作成完了(原木さん)
  - 山口さん、光成レビュー中
- 原稿は作ったので、今週いっぱいめどに展開される。
お願い

Session

Status
- 山口さんが大枠を作成
  - Graphic, Soundを追加する
- 3名が無理? → 2名 x 2セッションで発表する必要がある
  - QAのタイミングを変えて、前半後半
  - ゲストが出てくる形
ToDo
- いつまでに作る?
  - 全体の時間を確認する。(50分)
  - Outlineだけ今週中に出してください。

CES2020

Status
- コンテナ入っているうれしさが訴求できるようにしたい
- 作りこみはできない
- AGLの資産そのままで動かし、より作りやすいことを訴求したい
  - ポスターが肝になるかも
- ステアリング
  - 対応は必要か? (日下部さん) → 特になし
  - もし#3に使えるならClusterに使いたい
  - walthamでClusterからIVIにイベント送れるか
    - surfaceにfocusをあてて、surfaceにイベントを送ればよい
  - LINで送られてくる
- SoC : H3 Starter Kit (3.0) + KingFisher
  - LINはそのままつなぐ
  - AGLはH3サポートされているか?
    - HH8.0.1からサポートされている
    - HH8.0.2はubootを新しくしないといけない
    - KingFisher用にするにはデバイスツリーを変更すること
ToDo
- 特になし
- アイディアがあればください。

Requirement EGとのコラボについて

Requirement EG とのコラボ、どうなりますかね?
Responsible of IC EGでRequirement Specが浮いている
sound system, window system
- Containerで動かせるようにするための方法を考える。
- コンテナ間のインターフェイスより上のレイヤーを変えないでほしい

前回の確認

F2Fに向けた議論

TODO

進捗

Graphics
- 進捗は特になし。
- Host側もAGLで、という要望ありなので、どうするか。。

Sound

別のコンテナからPulseコンテナにストリームを流せなかった
- pulseaudioをユーザセッションで立ち上げると、そのユーザしか使えないため、別のユーザ(コンテナ)からアクセスできない
- pulseaudioをシステムで立ち上げる必要あり(未実施)

黒川さん

AGL demo platformを動かしてみると、SMACKで引っ掛かったとのこと
- SMACKについては、グルーピングができるとのことなので、Joseに聞いてみるといいかも
ダウンロードするmanifest.xmlを一つにする

CAN

測定条件

M3をA57だけにして測定した。

8byteのCANデータを転送している。512回試行した平均値。

周期は30msec

vcan0→ vcan0 : 20 usec
- メモリコピーくらいしか走っていない
- コンテキストスイッチくらいのオーダー
vcan0 - > vcan1 : 22 ~ 23 usec
vcan0 → vxcan : 23 usec
CAN_GWを通っても性能劣化しないことがわかった。
測定観点のアドバイス
- 8byteを10msecで実施するとよいのではないか
- 受取側が2processだとどうか?

今後のスケジュール

日時	内容	TODO	Remark
10/9	IC EG meeting
10/11	ボードセッションのアウトライン
10/21	事前打ち合わせ
10/22-23	AMM	キーノート Session x 2
10/24	SAT	IC EG Update 1h	前回残った話(IC EG core profile, branch)
10/31	Open Source Safety Critical Summit	ELISAと話す	山口さんがCFPを出している→ 採択されました。おめでとうございます。
11/5	IC EG Call
11/6	IC EG Tech Meeting 13:30 - 16:30
11/11 - 13	Integration Session	CES #3? 各社デモ
11/19	IC EG Call
12/3	IC EG Call
12/10 - 12	hackfest/CES Integration session in San Francisco	CES #3? 各社デモ?
12/?	発送
1/7 - 10	CES

次回打ち合わせ

10/22 - 10/24 : All Member Meeting

=== Appendix 9/12の議事 ====

F2Fに向けて

進め方の確認
- F2F＠ベルリンでコンセプトを説明してキーメンバーに了承得る。その後、AMM-ABで報告を狙う。
- UCBではなく要素開発。現時点ではgerritにはコードを置かないことを伝える。
アーキテクチャコンセプトレビュー
- 資料レビュ：light weight で用語統一
  - Fast boot : 製品向けそのものではなく、今のAGLをどう軽量化すればよいかを示す。
  - 作るのは主要機能部分。機能安全そのもの、isolation method部分は対象外とすることをはっきり伝える。
    - 将来的にSafety部分をLinuxで実現することもあるだろうが、今回の話題ではない。
    - メインファンクションとしてのクラスタは作成。IVIとクラスタを共存させることはしない（相反する）
      ＝＞コンテナを使う。
  - QM Isolation
    - QM isolation に対応するkernel 部分の開発、対応が課題。Elisaで期待できないか。
- 一日目か二日目(AM)にクラスタのアーキの話をして、個別のアーキの話をする
ToDo
- アーキテクチャの資料の修正(原木さん、山口さん、光成)
  - 2日目(25日)の午前中にアーキテクチャの概要のセッションを実施する
  - 詳細のアーキは2日目か3日目のAMにする
  - 機能安全は初日の感触で。
- 9/18までに個別アーキテクチャを埋める → 全体の課題をまとめたConclusionを23日に作成する@ベルリン
- AGLを使ったとき、コンテナらどうなる?
- GUI
  - アプリケーションコンテナでweston起動する(起動のやり方を記述する(アプリコンテナにすることでinitが変わる))
  - dmabufの原因を調べる
- CAN
  - CANに関わる主要要件をTier1, OEMで議論してCANの資料に載せる
- 進捗
- 機能安全と非機能安全の境界
- Interfaceの具体的なたたきだいを出す(原木さん、丸山さん、田口さん、光成)
- GUI
  - Qemu環境でX11と waylandを動かしてみる(谷川さん)
    - Containerだけだと少し扱いにくい
    - X11を動かした。表示はできるが、このままでは開発には耐えられないので整備が必要(sshでコマンドを送っている)
    - デフォルトでGPUアクセラレーションのセットアップができていない
    - 原理的には動く
    - コンテナマネジメントの方法を考えたい
    - Qemuの方は開発環境(LXD)を整える方向で考える
  - R-CARでコンテナ上でwaylandを動かしてみる(宗像さんと端山さんのところで相談してもらう)
    - westonをコンテナで動かせていない(R-Car)
    - x86環境
      - Containerはdocker
      - コンテナ外: driやXDG_RUNTIME_DIRをbindすれば動作した
      - コンテナ内に入れると、いろいろ問題が出た
        input deviceやttyデバイスが見れないと起動できない
    - R-Car
      - LXCをcontainerとして使う
      - driをbindすれば動作する
        ただし、/run/user/<userID>は変更する必要がある
      - コンテナ内外GPUにアクセスすることは問題ない?
        GPUのシェアリングは可能
        コンテナに入れるのがClientだけだと専用ドライバ不要で問題ない
      - udevが見えない
        アプリケーションコンテナを試す価値はあるかも
        今はシステムコンテナで動かしており、いろいろ上書きされて何か悪さをしているのかも?
        システムコンテナは今後クラスタの機能を優先して入れるので、コンポジタはアプリケーションコンテナであるほうがよい
      - システムコンテナでwestonが動かない
        weston初期化時にpvrモジュール内でdmabuf importに失敗している
        GPUは動いている
        ゴールのClusterでGPUをアクセスするケースがあるので、いずれシステムコンテナでGPUを触れる必要がある → 単独のglアプリが動くのか見てほしい
        GPUの制約を知りたい
        namespaceが絡んでそう
- Yocto(山口さん)
  - thudに変更した
- Sound
  - まだ別コンテナから出力できていない
  - pulseaudioのdomain socketのパスを変更することは可能なので、流せると思う
  - pulseaudioがユーザセッションでしか起動できない
- CAN
  - vcanで評価する環境を作成した
  - CAN FDは必要か?
    - 直受けは考えていない。Gatewayで間引かれた後で受ける
    - CANのままではなく、serialで受ける
    - イベントドリブンよりポーリングするほうが時間を守りやすい
    - Linuxアプリからは/sys/fsにアクセスすれば加工されたデータがあるとよい
    - packetでやると優先度管理や定常的にだれかデータを引き抜く必要がある(Realtimeを守るため、CPUが固定される?)
    - 相手(RTOS or CANマイコン)側でStateを持って、shared memory をFIFOでシェア
    - OSIモデルにならって3つくらいの階層に切って定義してみるのはどうか
    - 演算系は外のRTOSで行い、抽象化されたデータを受け取るのがいいのかな、と思う
  - 主要要件をCANの資料の中に記述する
    - Tier1, OEMで議論する
    - CANのデータのやり取りはOEMによって異なる
    - たとえば生データでやり取りする、演算したデータを受ける
- Container Manager(光成)
  - LXDについて調査した
  - 指摘内容を修正して資料をConfluenceに置く
- 要件
  - 整理中
  - テスト方法も考え中

次回打ち合わせ

10/8 webex
もしF2Fで必要であれば、AMM会期中に行う

=== Appendix 8/28の議事 ====

議事

前回の資料の確認
アーキテクチャコンセプト
- 分散型アーキテクチャの絵を追加
  - 一番見せたいのは機能安全も含めた全体像ではなく、複数のシステムが同居していること。機能安全ソリューションがいると言いたいことがぼける
  - 分散型アーキのページとProposalの間にワンクッション必要
  - 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
F2Fにおいて話す内容
- ある程度固まったアーキを話したい
- 何を開発する必要があるのか提案したい。
  - Container Management
  - QMをどうやって達成するか
  - Document - 製品側はどうやって使っていくか、カスタマイズしていくか、というものが必要
- セッションは2つに分けたほうがいい。目的をクリアにしないと、手段が目的になりやすい
  1. どういう製品像を目指しているのかを紹介
    - どういうふうに使いたいかを紹介する
    - なぜIVIと同じ作り方だとダメなのか
      - 経済的観点(機能拡張をすると検証工数が爆発する)
      - システム要件(起動時間など)
      - SDLなどはOTAなどでのアップデートが前提
    - セキュリティが目的ではない
  2. より技術的な話は、興味を持った人で行う。Graphic, Soundなど、Containerの経験がある人と技術的ディスカッションがしたい

進捗確認

機能安全と非機能安全の境界
- ライブラリのレベルでinterfaceを切ってみた
  - kernel subsystemのレベルで吸収したほうがよいのではないか
- ブザーもASILの対象
- 「機能安全を達成する機能」と、「達成手段」は分けて考えたほうがよい
- 機能安全の方法は網羅的に出したほうがよいか？
  - やりかたは各社それぞれ
目標性能
- No update
Sound
- CarPlayとAndroid Autoの経路の確認
  - 構成図があるのでConfluenceにアップする
  - レイテンシ要件が厳しい。
    - Softwareで解決が難しい場合、SoCに性能達成を要求する必要がある
    - 目標性能のみ記載する(NDAが絡むので、なぜそれくらい必要なのかは記載しない)
  - Softwareでのノイズキャンセリング/エコーキャンセリングはPrivileged Containerに配置すると思うが、パスが多くて複雑
    - パスは一つのサーバーに集約したほうがよい
- pulseaudioでの音声出力
  - ユーザセッションでコンテナ内で起動、音声出力確認できた
    - システムワイドで起動しない
    - pulseaudioみたいなユーザで起動する
  - コンテナ間通信をトライする。(domain socketの共有)
CAN
- Gatewayの使い方、性能
  - no update
- LXCでCANを使えるようにする
  - LXCでCANを配信可能
  - Domain socket(コンテナ間の通信)はcontainer managerで設定してあげる必要がある。
    - Readmeに記載する
  - パスを空ける = そのパスを通じてコンテナ内の全アプリが外部アクセスできる。セキュリティ的に大丈夫?
    - パスを空けないと通信できない
    - セキュリティが必要であれば、カスケードできるものが必要。それは必須事項ではない。
- GUI
  - Qemu環境でX11 or Westonを動かす
    - no update
  - R-Carでコンテナ上でwaylandを動かす
    - まずデスクトップで、dockerを使って確認
      - Docker Clientでhostのwestonと通信し、wayland clientを動かすことができることを確認した。
    - LXCで動かしてみる
Yoctoのバージョン
- thudに変更する
Container Manager
- リファレンス実装を作成する。製品ではオリジナルになる
- LXCを前提としたものにしたくない
- 機能がAPIやライブラリになっているほうがいい(westonとlibwestonみたいな関係)
- LXDを参考に、どのようなマネジメントが必要なのか整理する

TODO

アーキテクチャコンセプト
- 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
機能安全と非機能安全のインターフェイス
- 機能安全達成とinterfaceの絵を分ける、どういう機能が機能安全で必要なのか説明する絵が必要(光成)
要件整理(原木さん)
- 目標性能
全体アーキテクチャの整理(山口さん)
技術課題
- Sound
  - CarPlayとAndroid Autoの構成図(日下部さん)
  - Container間でSound出力を行う(光成)
- CAN
  - Gatewayの使い方、性能(日下部さん)
- コンテナ間通信の方法をREADMEに追記(山口さん)
- GUI
  - Qemu環境でLXC上でX11 or westonを起動(谷川さん)
  - R-CarでwestonをLXC上で起動(黒川さんチーム)
- Container Manager
  - LXDを参考に、どんなマネジメントが必要なのか整理する(光成)

=== Appendix 8/8の議事 ====

機能安全について
- Incstrument Cluster System全体でASIL-Bをとるには、Linux側もQMを取得する必要がある
- OSS側と量産(機能安全)の時間軸が異なることが課題
- QMも機能安全の一部である
- 機能安全やQM(長時間, 量産)とアップデート可能部分(短時間の開発スパン, OSS, Linux)が同居できるシステムにする必要がある
Monotithic Architecture
- アプリが死んだらリセットというプロセスになりがち
- スマホはモノリシックアーキテクチャだが、APIで分離(Binder)して、アプリケーションの独立性を高めている
  - スマホは汎用コンピュータになっている
分散システム
- マルチOSにすることは実は難しい。ハードウェアの違いを吸収するためOSを変更したり、仮想化したり、課題が多い
- やりやすい方法がないか、ということで出たアイディアとしてコンテナ
- 垂直統合であればHypervisorは向いているが、自動車業界は同じレイヤーのソフトウェアに複数のベンダーがいる水平統合
リアルタイム確保について
- そもそもリアルタイム確保をアプリケーションプロセッサで行うことについて議論すべき
- アプリケーションプロセッサでは時間を予測できない
コンテナ
- 既存資産を利用しつつ、システムを作りたい
- glibcを使わない、という選択ができる
  - 例えばQMが必要な領域に対しては小さいlibcを選ぶことで、検証工数を減らすことができる
- カーネルは選ぶしかない
- 組み込みに適したコンテナ
  - サーバー系コンテナはネットワークとストレージしかサポートしていない
  - ホットプラグ
  - CAN
  - 描画
  - アプリケーションマネジメント
    - メッセージ通信はdbusが一般的
    - 今季はなんちゃってでいい
- システムコンテナとアプリコンテナの区別
  - Hypervisorとの置き換えが容易
- できるだけアプリコンテナを増やし、ポータビリティを上げたい
- メモリ、ROMは消費する
性能要求
- 量産に耐えうるレベルの要求値を出してほしい
Linuxを採用することに対して
- OSS≠コストダウン
Sound Architecture
- 特権コンテナにサウンドサーバを置くアーキで合意
- 一方で、従来クラスタはIVIと関係なく音を出すことができる
  - クラスタコンテナ専用の音が出せるようにデバイスのprivilegeを与えればよい
- pulseaudioを試す
- エコーキャンセリングなどはどうするか → 次回以降
CAN
- Linux 4.12からGatewayの機構が入っている
- LXCがCAN GWを設定できないかもしれない → LXCを変更する必要があるか調査する
- CANのラベル
  - メータは多くて50前後
  - IVIは300 ~ 500くらい
- ルーティング
- 抽象化
  - W3Cとか？
    - 定義されているもの以上のラベルは競争領域
- ライブラリ(libcan)で各アプリレベルで抽象化するようにしたい
  - サーバーを作っても使われない
  - First Stepとしてはライブラリがいいのではないか
  - CとC++で作ってほしい
AGL Container Profile
- 対象はHostのみ
- コンテナライフサイクルを管理するものが必要
GUI
- Compositor
  - 必要であればPrivileged コンテナで動作する
  - Xでもwaylandでもどちらでもいい
    - Containerアーキはそもそも取り換えられることがコンセプト
  - SharedやIPCはコンテナで可能
  - XはWindow Managerを分離できているが、Waylandはできない(統合されている)
- Chrome Browser
- Input
  - 要検討
  - Privilegedコンテナから配送するか?
- Home画面(ショートカット)はPrivileged?
  - 機能はPrivileged
  - HMIはApplication Container
- 9月末までにsimple-egl(GPUアプリ)をPrivilege経由で動かしてみる
AMMでセッションを開きたい

Browser not supported