FuSa SIG/Status: Difference between revisions
From Xen
Jump to navigationJump to search
Line 2: | Line 2: | ||
* Hardware |
* Hardware |
||
** Only platform core code (no driver) |
** Only platform core code (no driver) |
||
*** timer, mmu, irq controller |
*** timer, mmu, iommu, irq controller |
||
** board/platform specific code to be done by user |
** board/platform specific code to be done by user |
||
** PCI passthrough out of scope (for now) |
|||
* System configuration |
* System configuration |
||
** |
** Dom0less |
||
** Mixed criticality (a certifiable VM and a non-certifiable VM) |
** Mixed criticality (a certifiable VM and a non-certifiable VM) |
||
Revision as of 21:50, 11 August 2022
Scope Definition
- Hardware
- Only platform core code (no driver)
- timer, mmu, iommu, irq controller
- board/platform specific code to be done by user
- Only platform core code (no driver)
- System configuration
- Dom0less
- Mixed criticality (a certifiable VM and a non-certifiable VM)
Ongoing Efforts
- Requirements format (doxygen)
- table of requirements followed/to be followed/not applicable
- doorstop (links requirements to code)
- Zephyr solution (originally by Intel) based on doxygen
A bunch of work was done but more work is required. Request to change all the existing docs into doxygen. Issue is we only have 1 release cycle to switch to doxygen. What is the agreement / process to make progress on this? We don't want an 80 patches patch series. ACTION: bring the topic of the *process* up with the REST
- Unclear coding style
Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl. It needs to have a checker. It should be a well done well maintained project and coding style. Can we find a coding style similar to Xen coding style? It should work with standard editors. Can we agree on 2-3 parameters we can use to evaluate coding style? Are there FuSa friendly factors to consider? ACTION: bring up adoption of existing coding style
- Misra requirement classification
Marketing. Why the standards are there and why they can be useful. Code quality, testability, security. Agree on process: step by step starting from the non-controversial. ACTION: prepare a webminar 1-2 months (option to use LF webinar) ACTION: write emails status updates once a quarter ACTION: keynote at XenSummit
- First status update:
Misra rules already covered cppcheck that we want to add to Xen how much is already covered, burn down on what we want to do publish real-time capabilities analysis
- Define actionable work packages for any contributors and maintainers
- static code analysis (cppcheck, Coverity, Eclair)
- goal: Misra code compliance
- Real-time and interference reduction
- real time analysis of Xen
- interrupt forward response time
- cache coloring
- real time analysis of Xen
- commit review tracing
- get info from mailing list archive
- static system definition
- static memory allocation
- static heap allocation
- cpupools