FuSa SIG/Status: Difference between revisions
From Xen
Jump to navigationJump to search
No edit summary |
|||
Line 13: | Line 13: | ||
* Requirements format (doxygen) |
* Requirements format (doxygen) |
||
⚫ | |||
** table of requirements followed/to be followed/not applicable |
** table of requirements followed/to be followed/not applicable |
||
** doorstop (links requirements to code) |
** doorstop (links requirements to code) |
||
** Zephyr solution (originally by Intel) based on doxygen |
** 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 |
|||
⚫ | |||
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) |
* static code analysis (cppcheck, Coverity, Eclair) |
Revision as of 17:01, 21 March 2022
Scope Definition
- Hardware
- Only platform core code (no driver)
- timer, mmu, irq controller
- board/platform specific code to be done by user of Xen at this stage
- PCI passthrough out of scope (for now)
- 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