議事録 2020/02/20
Attendee
原木、黒川、日下部、田口、駒形、山口、谷川、丸山、光成、Damian(敬称略)
場所
東京・パナソニックセンター有明 会議室６
Webex
日時
2020 2/20(木) : 10:00 - 17:30
アジェンダ
10:00 - 11:30 : DRM Leaseのファンディングについて(黒川さん)
11:30 - 12:30 : 昼食
13:00 - 15:30 : Cluster Serviceアーキについて(丸山さん、田口)
15:30 - 15:40 : 休憩
15:40 - 17:00 : LTSの件 (山口さん/谷川さん)
17:00 - : Wrap up、次回予定、幹事確認、解散
DRM
DRM lease 資料（）
Q. Displayの名前にエイリアスはつけれる? （Page14）
既存のアプリケーションの実装を変えたくないので、設定依存のことはしないほうがいい
Host側のマネージャでDisplayを分配する。
Containerの役割としては、マネージャから渡されたファイルに書かれていることをスキャンしてDisplay nameなどを取得できるようにしたい。コンテナのWesonなどはDRMをスキャンしないようにしてほしい
udevの問題もなくせる?
表示に関わる課題はなくなるはず。
Inputのやり取りに関する課題は残る。これはHostにinput managerのようなものがないといけない
CESデモでは、remotingのためにvirtual displayを扱っていた。Lease Managerは仮想デバイスも扱うか?
DRM Lease managerが扱うのは物理デバイスのみ。仮想デバイスはContainer側
Westonでしか動かないシステムにはしたくない
Westonはいろんなパッケージに依存している。QM汚染になってしまう。
SoCに依存せずに、DRMのリソースの引き渡しなどができるとありがたい。
マルチカードなどの技術はSoCに依存してしまう。
ホストにDBUSをもつことは致し方ないかもしれない。
よく使われている仕組み
DBUSをホストに使うことについては、QMと関わりがないから、コード検証しない、という選択をすることができる。
libdrmはコンテナに置かないといけない?
Yes
lease managerはlibdrmを使う?
lease managerが使う(実装依存)
そんなにコード量は多くない
コンテナが落ちたときに、Lease Managerは画面状態をキープできるか?コンテナが落ちても保持してほしい。
できなくはない。
基本的には画面は消えるが、実装によって保持機能を付ける
CESではホストのwestonがキープしてくれていた。
落ちてもブラックアウトしないことがRequirementにある。
復活するときには、クライアント側が工夫しないといけないこともある。
固まってはダメなものもある。カメラ映像が最たる例
カメラ映像は別経路にするべき
クラスタ
固まっていいものとないもの(Telltaleなど?)があると思うがどうか
分別しないといけない。
コンテナを早く起動しなおすことが肝要
本当にまずいものはコンテナではなく、ホストに置くことも考えないといけない
それでも満たせない場合は、カーネルレベルで解決など。それは商品のRequirementによる
DRMで実現できないことは別の手段を考えたほうがいい
AGL側は使えるユースケースやスペックの提示が必要
Requirementをまとめる
Requirementを分析し、どういう品質レベルが必要か精査し、マッピングしたい
メータ側の人たちでまとめる
ちなみにRear Viewは同じIVIのSoCにいるだけでシステムは別
ガイド線は、だれが書くか、という問題はあるが。
違うQMのコンテナの内容を一つのディスプレイに表示したいときはどうすればよいか。
コンポジット機能が外にないといけない
一番厳しい要件に引っ張られる。Requirementによって適切な実装を選択する必要がある。
提供できる選択肢を増やす方がいい。 = Product Ready
スケジュールについては、11月のCESをターゲットにしてほしい。マージは不要。
Kernelのバージョンの問題もある。現状は4.14を使っているので、バックポートをしている
Kernelのバージョンアップは間に合わない
Clusterアーキ
・前回からのアップデート
・service部：共通部、OEM固有部
・IFとAPIを使い分けて書きた方がいい。
・なにを使って実装するのか？フレームワークを提供する？
・AGLはbinderを提供している
・アーキテクチャの中でAPIという表現は構わない
・AbstractionLayerでcommon IF
・表示のフローとデータ生成のフローは分けて記載したほうがよい
・出力系はいろんなソリューションがあるよ、これ使えそう、または無いから作らないといけない
→メータfunction軸と要素軸で分けて、なにを共通化するのか
・OSSだとライセンスの課題もあるので、変にプロセスを分ける分けないを規定しないほうが良い。買い入れを採用するケースもある。
・AMMの発表スライドのときはタイトルを細かく変えること
・実装はサプライヤ次第。
・Safetyとの間はCAN以外にあるのか？
・①コマンド転送/②映像転送(H.264など)/③ダイレクトレンダリングを使えば、IVIが描画した内容をメータに重畳可能。
・①は製品固有、③はBSP依存、②はオープンソースソリューションもある。
・AGLとしてはどのソリューションでもできるように提供することが重要。
①と③がAGLでは現状、実装持ってない。
・チャレンジするなら③。チップ依存が大きいのが課題。実装レベルでの議論をしないと意味がないレベル。
・ボタン系の入力をどう制御する？InputManager
→OEMとしては入力を制御するECUを同じものにしたい
・キーイベントを待っているアプリに対してInputManagerがメッセージを振り分ける必要がある。
→UI仕様に依存する部分が大きい。かっちりは決められない？？
・Tier1としても毎回作り直している部分。ダメだった事例ならたくさん出せる。
・システム側で固めすぎると、変なUIが出てきてしまうのもこまる。
Test spec
・テストコードのイメージは？
→C0C1カバレッジを想定できるようなもの
・対象は、アーキ上のClusterServiceの部分。
→リンクするライブラリが課題。
・案としては、使っていいライブラリを用意もしくは限定して、一緒にコントリビュートする、など。
・目的は均一なテストを実施できるようにすること。ライブラリの組み合わせでばらついたり、動かないなどは避けたい。
※全てのライブラリに対してMISRA-C運用やテスト適用は不可能。
・テストプログラムの配布方法どうする？テスト実行環境も。
→リファレンスバーチャル環境みたいなものも必要かも。
・異常系のテストケースは項目を抽出することが難しい。
LTS
・先週のSCでLTSの話が出た。UserLandに対するLTS。
・Pokyのトラブルとして、昔あったフォルダがまるっと消えているケースなど。
・MetadebianはLTSが現状無い。
・昔のスナップショットが消えている課題あり。
・MetadebianのモチベーションがLTSに無い。
・お試し環境はコンフルエンスにある。
URL: おためし！meta-debian！
・Redhatのほうがプロダクト観点でも良い。パッチレベルの指定可能、トレースしやすい。課題はベースがないこと。
Redhat8のメンテフェーズが27年まで。23年24年のLO製品はちょうどいいタイミング。
次回予定
3/11(水) 13:00～ ＠？？？ ：幹事 丸山さん
=== Appendix 2020/1/22～23の議事 ====
ELISA
ユースケースを提案(Telltale)
SafetyとNon Safetyをわけることを提案
すべてLinuxでできないのか、と言われている。
動くものはLinuxで作れる、と主張される
なぜLinuxでできないのか、を伝える必要がある。
車に載せれない、という理由を具体的に説明する必要がある。日系、欧州で使わない理由。機能ではなく、品質面でLinuxを使うことを受け入れれないラインがある。
→ できること、できないことを分けるアプローチをとっていることを説明する
AMMでIC EGで2つセッションを出す
品質(山口さん)
量産に向けた課題解決
どうやって品質(QM)を担保するか
アーキテクチャ(田口さん、丸山さん)
黒川さんがコンテナデモでわかったことを発表する
コンテナ化に紐づけて、AppFWについて見直しの提言
CESの反省
Lessons learned from AGL UCBコンテナデモ
init
Host : systemd, Guest: systemd
図らずも、systemd serviceのツリーは、きれいに構築された。逆に言うと、ゲストでSystemdを使う限り、HostにSystemdを残す必要あり？
もしかすると、
ホストでは、ベースとしてA：FS Container（独自init）と、B:QM Isolation Container（sysytemd)と置き、QM Isolation Containerの中に、IVIやICのゲストコンテナ(systemd)をネスト？
全コンテナの下に、最小構成のホストRootfsを置くアーキは理想だけど、現実的ではない？
全デバイスドライバがユーザーランド化でもしない限り、例外的なバイパスを開けまくるか、ゲストからホストに処理を移動する形になり、全体アーキが崩壊しかねない
minimum init (fork)-> systemdを起動したほうがよいのでは。
FS containerはminimum initが起動。
initも分離しないといけないと考えた。
思ったほどHost環境を守れない
例）CESデモでは、MOSTドライバの初期化が(sysfsのwriteを利用する方法で）ユーザーランドにあるため、これをホスト環境に組み込む必要があった
理由：LXCでは、sysfsは原則ro、rw可すると、全sysfsがゲストに丸見えになる。LXCでないとしても、sysfsの原則roは正しいと思う
Security Model
AGLは、AppFwとLSM(SMACK）が密結合（ついでにいうならsystemdとも密結合）
きほんてきにSMACKはhostで設定しないといけないのに、AppFWが設定している
本来は、システム構成(インストール時)に基本システムのセキュリティが決まる。
後からインストールされるアプリには、後から3rdパーティ用のセキュリティポリシーを割り当てるべき
AppFWはSmackを利用しないようになるが、我々でもセキュリティモデルを考えないと
SELinux, AppArmorをコンテナでどのようにマネジメントしていくかを検討したほうがいい
専門家がいない。
Android, サーバー屋さん
コンテナとLSMの連携がどうなっているのか知りたい
システムコンテナのレベルで一度制約をかける。その中で、アプリ単位で制限をかける。もちろん、コンテナの制約を破れないように。AppFW + SMACKだとうまくいかない
namespaceは対応しているはず。
結果、SMACKを丸ごとホストからバイパスしないと、アプリケーションがインストールも起動もできないというトンデモな事態に
結論：AppFwとLSMを密結合してはいけない？ AGL UCBのセキュリティモデル（特にMAC)を再考する必要あり？
USBホットプラグ
LXCは、USBホットプラグが難しい。コンテナにデバイスを追加、削除するプリミティブなAPIは存在するが、それだけでは足りない。
LXCは、コンテナの中でudevが機能しない。udevはホストにあり、udevの対象は基本ホスト。技術的には、例えば、udev経由でLXCのコマンドやAPI叩いてゲストに作用させる方法はあるが。。。
例）USBメモリ
ホスト環境では、USBのデバイスの接続・切断、USBストレージデバイスの認識が可能だが、ゲストからは、ただのSCSIディスクにしか見えない
AGL UCBには、ストレージマネージャのようなサービスが存在しないので、まだ課題が顕在化していないだけ。
USBが抜かれても、ゲストに通知がこない。(USBデバイスが見れないので)
いまのAGLにストレージマネジャーがない
Bluetoothも同じような悩みがある。
Bluezをホストに置かないと、Bluetoothの接続、切断イベントがとれない
動的に出現/消滅するデバイス
AGL UCBで解決することは難しいかもしれない
e.g. ストレージが抜かれたときにアプリをsigtermを送る機構など
それをホストで実装するとホストが膨らむ
ゲストでやると、ホストとの連携が課題
既存のソリューション(Tier1が持っているストレージマネジャなど) を入れて、分離できるように
USB認証
車載で使えるUSB, Bluetooth, その他ネットワーク系(WiFi, DCM)のコンテナでのハンドリングは、サーバーやPCでは利用しない。車載特有のため、AGLで議論するしかない。
課題を明確にして、商品開発の段階で作りこむのが現実解か
商品開発に移行しやすいような環境をオープンソース
Requirementを渡さないと、オープンソースの人は理解できない
AMMでABに申請したい
Sound
Unicens
agl-serviceの責務が明確化されていないため、本来サービスにあるべきではない処理が含まれる場合がある？
例）agl-service-unicensをホストとゲストの両方で実行しないと、MOSTが正しく初期化されず、音がでない、曲の再生が始まらない、という不具合あり
Pipewire
現状は、IVIゲストに存在。AGL AppFw？Signal composer?とPipewireが密結合している模様 → ホストや別コンテナに分離ができない → ICゲストから音を鳴らす方法が存在しない
サウンドのあるべき論を出してガイドラインを作って、サービスを作ってもらう。
Grahpics
DRM問題
Waltham backend
Nested westonは、当初の想定外に上手く機能している（wayland-backendのwestonは起動が軽く、結果、IVI,ICコンテナの再起動が非常に早くなる）
ホストに軽量コンポジタを置く構成は良いと思う。
wayland通信は軽量なので、ネストの影響は小さい
コンテナマネージメント
LXC-Launcher
デモ実装やっつけだったが、Nestコンポジタアーキをうまく動かすためには、ここが肝となるかも。
理由：デモでは、IVI_SHELLで、ゲストWestonのライフサイクルを管理。一方で、LXCとホストWeston(IVI-SHELL)は、そのままでは、何も連携できない。
RunLXCでのアプローチ：LXCのAPIを使ってコンテナのライフサイクルと、ホストWeston（IVI-SHELL)のSurface/Layer管理を結合し、コンテナのライフサイクル管理（再起動デモ）を実現
サーフェス、ディスプレイマネジメントとコンテナマネジメントは統合する必要があると考えている
コンテナマネージャもGUIを認識しないといけない。
IVIのリブートは5sec程度、Clusterコンテナは1sec程度でリブート可能
DRMのマネジメントをゲストに見せるのはローレベル過ぎる
Host環境
systemdをベースにする
minimum構成に外せないものは何か
yoctoを使ったsystemdは大きい
CES2020(1/23) - 黒川さんから
アプリケーションコンテナは利用していない
アプリケーションからどのコンポジタとバインドするのか、ホスト
ホスト側
全部アプリケーションコンテナにするのは、組み込みには向いていないかもしれない
SMACKは本来介入しなくてよいはず
ホスト側で設定したセキュリティポリシーに従って、アプリFWがMACコントロール
QM isolationも含め、hostの分離の仕方(initから) を考える
LXCそのままで続けていくのは無理があるかもしれない
Ethernet
systemdがDNSを起こすと、LXCと競合する
名前解決ができなくなる
DNSマスカレードの設定をレシピ化
ネットワークのネームスペースはホスト側に置くべき。
ローカルリンクはLXC
Hostのconnmanは物理デバイスの制御
将来的にはスライサーが欲しい
バックエンドはホスト → ホストは大きくならざるを得ない → ホストの検証範囲が広がってしまうので、どのように切り分けるか、がコツ
アプリケーションはアプリコンテナ
早いところ、アプリを分離したい
DRM lease
複数の独立したコンテナでディスプレイを分配したい。
DRM leaseを利用すれば、Hostのmasterがゲストのコンポジタにdisplayのmaster権限を貸し出しできる
unix domainなどでfile descriptorを渡す必要がある。
1GPU - 2 Display というケースで必要
R-CARはRender Nodeの仕組みが必要
lease managerはmaster権限を貸し出すだけで、初期化はコンテナのweston
アーリーレンダリングに必要
GPU描画をQMの対象外にしたい
メータの中でもQMのレベルを分ける必要がある。
GPUのドライバは検証できない。GPUのIPベンダのみ。
セットの動作保証はできない
Pros
出力の宛先を切り替えたい
1GPU - 2 Displayのようなユースケースに対応できる
IVIの中を分けることもできる(IVI + RSE)
inputについてはユースケースの定義が必要
一つのタッチイベントやボタンイベントを共有する
4月から開発スタートしたい
CESでプロダクトレディーの状態にしたい
次のミーティング
2/20
AMMのどこか
TODO
USBのRequirementを提案する必要がある
Requirementのたたき台を日下部さんに出していただく → Dr. Yamaguchiがまとめる。
Security Modelの構築(SELinux, AppArmor) ... メータのEG
考え方の整理からスタートする
IC Service ... メータTier1 ですり合わせていただく
Linux Graphic stackのQM実現方法
既存のほかのOSのやり方を学ぶ ... メータTier1 ワーキングから出してもらいたい
GPU(OpenGL)
デジタルクラスタのときに、どういうQMの考え方をしたのか
モータから絵を描画することに変化して、QMのレべルをどう切り分けたか
カーネルのQM Isolationについて、ELISA(SIL2Linux)に考え方を確認する
DRM lease
Connectivity のデバイスに対する要件の整理 ... 担当者を探す
ある程度要件がまとまった時点でContainer Managerのデザインを行う
GUI Reference ... 田口さん
3月までに
アーキテクチャレビュー
今後のタスク
DRM lease :
Security Model :
USBのハンドリング :
IC service :
Container Manager :
ELISAメソッドを使ったQMアイソレーション in Kernel
とりあえず、リンク
カーネル(まだ荒い。。。)
https://makelinux.github.io/kernel/map/
ブロックデバイス
キャラクタデバイス
drm/kms(graphics関連)
=== Appendix 12/4の議事 ====
進捗の確認
IC EG Callの内容
関係者に資料は共有している
プロジェクトを開始する前にしなければいけないこと
インフラ
Contribution
UCBに入れるのはやりにくい。いらないもの、ビルド環境がIVI用に特化して構築されていて、修正しにくい構造になっている。
CESデモはUCB
リリースプロセス
プロジェクトの進め方のたたき台?
回せるものを作成して、進めていく
手を動かせる環境を整えないといけない
AGL UCBをスタートにすると、土台が大きすぎて難しい。仕切り直したい。
合流できるなら合流しましょうというスタンス、を伝える
CESからAMMの間に環境を整えたい
山口さんの環境はUCBを外している。ホストだけでよい
Cluster固有の作業は、Hostの環境構築とは分離