...
- Bernhard Rill
- Peter Schreitl
- Adam Lackorzynski
- Dmitry Sepp
- Matti Möll
- Gunnar
Apologies
- Artem (conflicting meeting)
Minutes
- Peter: Defining the platform better. The Arm specification on secure partitioning can also be useful to look at.
- This also includes use-cases, to better define...
- Bernhard: Yes, and a few other specifications might be useful also. Others are not so applicable. I can look at this.
- Peter: Starting with VM scheduling, for example.
- Matti: We can only define the interface... what other "surfaces" might be described?
- Peter: Just thinking that going from the top we realise VMs need to be scheduled.... Example - Android + RTOS, how is switching done and what does it lead to?
- Gunnar: This goes into a kind of system design. If you are speaking about cores etc.
- Bernhard: Two prominent examples of interfaces...
- Matti: Define what is a platform in general, and is it focused on components or interfaces?
- A platform allows things to be built on top of it. It cannot be too hard to implement, because then it will not be implemented to the degree that it becomes really usable.
- Think about the right level. Not too complicated. Not narrowing the solution space too much. And not too broad so that portability is not achieved.
- Peter: We are quite well defined here. Starting from defining a... hypervisor based platform
- Matti: If it is an automatic (preemptive) scheduler, it cannot be defined using interfaces.
- Gunnar: You can set priorities. Not from the VM, but when configuring the platform. (Therefore the AVPS could set requirements on it).
- Peter: We can still write requirements for this. The behavior can be defined.
- Peter: Variants of the platform advanced/basic could be an example.
- Matti: Currently covered in AVPS by "If the platform includes feature X, then it must..."
Short review (on overtime) of the AVPS v2 ticket priorities.
March 24
Whitepaper work and AVPS prioritization
...