Differences

This shows you the differences between two versions of the page.

--- eg-app-fw:meetings [2020/12/16 23:48]
khosokawa
+++ eg-app-fw:meetings [2021/01/13 14:27]
waltminer
@@ Line 17: / Line 17: @@
 ------
+==== January 13, 2021  ====
+Attendees: Walt, Jan-Simon, Tanikawa, Scott, Marius, Hosokawa,
+   * RBA
+   * 12/2
+     * Anusha asked a question on the [[https://lists.automotivelinux.org/g/agl-dev-community/topic/fw_related_to_agl_compositor/78625117?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,78625117 | mail list]]. Discussed the responses to this.
+     * Marius will look at dynamic loading of the policy engine at run time so that policies can be dynamic. An alternative solution that would not require dynamic loading of the policy is to incorporate RBA into the compositor itself.  Hosokawa-san will was whether that is ok for Denso.  It would avoid a lot of unnecessary complexity since there is probably no use case for having the policy dynamically loaded.  Will continue the discussion on the mail list.
+   * 12/16
+     * RBA successfully connected to AGL compositor using M3 and QEMU and can run the demo apps. Code will be pushed by Hosokawa-san.
+     * Discussed whether RBA will be enabled by default in the demo image. Plan will be to enable RBA by default.  Need documentation on how to update the policies and create new policies in order to make this the default. Hosokawa said that there is no plan to create such documentation.  If the documentation is created the proposal would be to have RBA be enabled by default with a mechanism to disable it and replace with a different policy engine.
+   * 1/13
+     * RBA now merged as a build time option and will run the existing AGL demo when enabled. Some open issues remain. RBA is not enabled in CI or in any build images as an option.
+     * Documentation and example are in progress.
+     * Walt suggested that Hosokawa submit a talk for AMM that shows the demo running with RBA enabled.
+   * Waltham - Discussed SPEC-3647. Waltham currently requires a private fork that is not maintained to be usable. ADIT currently has no customer or budget to continue the Waltham work. Need to decide the long-term future of Waltham with the Steering Committee.  Do we work to upstream this and have AGL maintain it or go with what is it there and potentially let it bit rot over the next few years?
+[[:agl-roadmap|AGL Roadmap]]
+   * Product readiness effort
+     * No one from Toyota dialed in, Need to discuss the future of the app framework with respect to the PR effort.
+     * Tanikawa: Current app framework is targeting a modern mobile environment for app installation and management. PR effort is thinking more along the lines of a re-using an older vision of app framework.
+       * Need to separate app management functions from a common platform service implementation.
+     * Scott: Would like a definition of what Toyota says they will drop to AGL for a new application framework after 2021.
+       * Current state of PR effort effectively freezes the project while people wait for Toyota to make decisions.
+     * Jan-Simon: There are impacts to other parts of the project.
+     * All: Toyota's Base System attempts to replace systemd. This takes the project in a very different and not open source friendly direction.  Need to understand what Toyota's intentions are with respect to their Base System and whether they think systemd will be used long-term. EG does not think the Base System is sustainable.
+       * Suggestion is that we let Toyota own and do the work for the "trial version" and only provide advice and training since this seems to be throw-away long term and have the EG develop the long-term solution.
+       * Tanikawa:  Need to investigate replacing SMACK with SELinux (or something else). SMACK does not seem to be up to the needs of a production system.
+Topics for EG for PR
+   * Continued use of systemd
+   * Linux Security Module for AGL (SMACK, SELinux, AppArmor, or none). None implies leaving the LSM to the product developer.  Choosing one effectively locks in the Product developer to a solution.
+   * Package management and deployment solution
+   * API mechanism. Continue to use OpenAPI or change to a different mechanism for platform services. Ideally we have an IDL that autogenerates the API code. (grpc, OpenAPI, or another)
+   * Long-term use of Qt
+   * IPC should be defined and selected.
+   * Current status
+     * Window Manager and Compositor are functionally equivalent to CES 2020 demo for Qt Apps.
+     * WAM implementation is being worked on by Igalia and should be ready for JJ RC3
+     * Marius has a number of Jira tickets to resolve but will quickly run out of work if new requirements are not defined and agreed upon by the IVI Product Readiness effort.
+     *
+  * New topics:
 ==== December 16, 2020  ====

Automotive Linux Wiki

User Tools

Site Tools

Differences

Page Tools