...
Minute takers according to this page
Participation planning:
...
July 12, 2021
Participants:
- Stephen (Renesas)
- Adam (Kernkonzept)
- Matti (Opensynergy)
- Gunnar (GENIVI)
- Oleksandr (EPAM)
- Kai (EB)
Minutes
- Gunnar: I met with Arm (Bernhard) and Francois Ozog (active in Linaro). We discussed virtual platform specification, if there are additional automotive-specific hardware that need VIRTIO support (e.g. do we have a proposal for FM tuner? (No, not currently))
Discussion on the usage of virtual platforms as a hardware-portability solution:
- Gunnar: We see this trend. I'd like to analyze this idea further, compared to for example just making stable user-space APIs and creating new kernel drivers for new hardware.
- => Is this not just shifting portability work "somewhere else".
- Let's analyze how "virtual platform API is stable" is different from "user-space API is stable" (i.e. just port drivers to new hardware..)
- Adam: BSPs that add a lot of patches to Linux get stuck on older versions. Not using mainline. Updating to new kernel drivers difficult (N.B. officially no APIs are stable inside Linux kernel)
- Matti: Linux kernel in particular, is an operating system kernel and a hardware-abstraction at the same time, which is challenging.
- Future challenges: Value-add for SoCs could be difficult if the [hardware abstraction] API is limiting.
- The virtual platform / VIRTIO / Trout and others. It seems the "new" distinction is a clear focus on a hardware-abstraction layer?
- (partly agreed, discussed the existence of firmware as one abstraction already used, and on PC side the hardware it self was standardized, etc. Overall, a complex reality)
- Summary:
- Kernel updates are driven by fast development, security issues, etc.
- Fast changes, no internal API stability guarantee etc. = updating drivers is a major issue.
- It seems this situation can't be avoided, and the industry is looking for a solution to the challenge.
- The theory seems to be that keeping API stable and efficiently port to new hardware, could be more feasible to do in the virtual platform.
- Discussion turned to evaluating the effort (that the industry is also considering) to create new kernel(s) instead, as a Linux alternative (for safety, and development concerns as shown above).
E.g. if they have a POSIX API, is that "enough". => No... could still be a large effort to port existing functionality.- Gunnar: As an example, consider systemd which early on used Linux-only APIs. And then a lot of functionality built on systemd. Such examples makes porting software a challenge.
- Also discussed how large part of Linux' functionality is actually used in practice in the industry?
- Matti: (Explicit example that shows the current situation)
io_uring recently added to Linux. It accelerates applications a lot. A hardware vendor that is able to use these latest features could have an advantage (hardware itself not faster, but the software runs faster).
- => With a virtual platform abstraction, updating to a new kernel with the new features should be feasible.
June 2021
- Regular meetings held every week. No specific meeting minutes written. Results in AVPS and topic planning (link below)
- AVPS v2.0 release.
- Working on deep-dive topic planning
December 14 2020 → May 2021
- Regular meetings held every week and results tracked in AVPS document and JIRA tickets.
December 7
- Participants: Stephen, Gunnar, Dmitry, Adam, Peter
- GPIO - clarified misunderstanding that referenced SCMI even though SCMI does not cover GPIO. Closed open issues and finalized requirements. Chapter will be done, after final polishing.
- Initial discussion on the structure of final GPU chapter (bringing together all input from previous hardware studies)
- We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements. Also consider how to handle a non-Linux OS, if that is included in the scenario.
Most other requirements will lean on hardware virtualization support, but the group did not want to lose the idea of support simpler hardware too.
- We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements. Also consider how to handle a non-Linux OS, if that is included in the scenario.
- Dmitry has done some updates on Camera/Media – postpone discussion to next time.
November 30
FOCUS : GPU virtualization – Features of the PowerVR/Imagination GPUs (used in Renesas R-Car SoCs).
- Presentation from Thomas Bruss, Renesas.
- Discussing the opportunity for a common "model" of modern GPUs that can be the basis for shared requirements in the virtual platform standard.
November 16 - 23
Discussions captured in JIRA tickets and in the document.
November 9
Minutes pending
...
Participation planning:
...
- October 19 - GPU focus? Discussion of new Mali features?
Bernhard + Arm colleagues, wants to present Mali GPU
Adam
Dmitry still vacation
Dmitry still vacation
Oleksandr - vacation?
Oleksandr
Daniel Stone? Emailed last week. Send calendar invite also.
Eugen ?- Emailed
Stephen likely interested
Ozgur
Ozgur - Emailed
Peter
Peter
October 26No meeting (AMM week)- November 2
Adam
Oleksandr
Dmitry
Peter ...
- November 9
Adam
Oleksandr
Dmitry
Peter ...
- November 16
Adam
Oleksandr
Dmitry
Peter ...
- November 23
Adam
Oleksandr
Dmitry
Peter ...
October 12
Dmitry vacation,
Adam has a conflict this week only
Oleksandr
Stephen join if possible (ad-hoc)
Peter
October 5
Participants: Adam
Stephen
Dmitry busy
Peter busy
Oleksandr busy
Bernhard tried joining (missed by Gunnar)
...
- Lots of topics (5 presentations), lots of discussion
- Little time for Q&A on each - basically every topic needs deeper investigation and discussions
- See presentations
May 14 - cancelled due to AMM
...