Difference between revisions of "FuSa SIG/Status"
From Xen
(→Scope Definition) |
|||
Line 1: | Line 1: | ||
= Scope Definition = |
= Scope Definition = |
||
* Hardware |
* Hardware |
||
− | ** Only platform core |
+ | ** Only platform core components (no platform drivers) |
*** timer, mmu, iommu, 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 |
||
Line 15: | Line 15: | ||
** 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 |
||
+ | ** Challenge: all changes required within 1 release cycle. ACTION: plan out the activities with the committers. |
||
− | 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 |
||
+ | * MISRA C |
||
− | * Unclear coding style |
||
+ | ** MISRA C working group is evaluating MISRA C rules and accepting them into the Xen coding style. |
||
− | Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl. |
||
+ | ** [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst|MISRA C rules accepted in Xen] |
||
− | It needs to have a checker. |
||
+ | ** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html* |
||
− | It should be a well done well maintained project and coding style. |
||
+ | ** In progress: violations reduction |
||
− | 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 |
||
+ | * static system definition |
||
− | * Misra requirement classification |
||
+ | ** static memory allocation |
||
− | Marketing. Why the standards are there and why they can be useful. Code quality, testability, security. |
||
+ | ** static heap allocation |
||
− | Agree on process: step by step starting from the non-controversial. |
||
+ | ** cpupools |
||
− | ACTION: prepare a webminar 1-2 months (option to use LF webinar) |
||
− | + | ** status: upstraming in progress |
|
− | 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 and interference reduction |
||
Line 52: | Line 33: | ||
*** interrupt forward response time |
*** interrupt forward response time |
||
** cache coloring |
** cache coloring |
||
+ | ** status: upstreaming in progress |
||
* commit review tracing |
* commit review tracing |
||
** get info from mailing list archive |
** get info from mailing list archive |
||
+ | ** script available to retrieve all mailing list discussions from a commit id |
||
− | * static system definition |
||
− | ** static memory allocation |
||
− | ** static heap allocation |
||
− | ** cpupools |
||
[[Category:Safety Certification/FuSa SIG]] |
[[Category:Safety Certification/FuSa SIG]] |
Revision as of 22:13, 11 August 2022
Scope Definition
- Hardware
- Only platform core components (no platform drivers)
- timer, mmu, iommu, irq controller
- board/platform specific code to be done by user
- Only platform core components (no platform drivers)
- 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
- Challenge: all changes required within 1 release cycle. ACTION: plan out the activities with the committers.
- MISRA C
- MISRA C working group is evaluating MISRA C rules and accepting them into the Xen coding style.
- C rules accepted in Xen
- cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*
- In progress: violations reduction
- static system definition
- static memory allocation
- static heap allocation
- cpupools
- status: upstraming in progress
- Real-time and interference reduction
- real time analysis of Xen
- interrupt forward response time
- cache coloring
- status: upstreaming in progress
- real time analysis of Xen
- commit review tracing
- get info from mailing list archive
- script available to retrieve all mailing list discussions from a commit id