Difference between revisions of "FuSa SIG/Status"
From Xen
(→Scope Definition) |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
= Scope Definition = |
= Scope Definition = |
||
* Hardware |
* Hardware |
||
+ | ** Platform core components (no platform drivers): timer, mmu, iommu, irq controller |
||
− | ** Only platform core code (no driver) |
||
− | *** timer, mmu, iommu, irq controller |
||
− | ** board/platform specific code to be done by user |
||
* System configuration |
* System configuration |
||
** Dom0less |
** Dom0less |
||
− | ** Mixed criticality |
+ | ** Mixed criticality: a certifiable VM and a non-certifiable VM |
= Ongoing Efforts = |
= Ongoing Efforts = |
||
− | * Requirements |
+ | * Requirements and documentation |
+ | ** Doxygen for documentation of internal and external interfaces |
||
− | ** table of requirements followed/to be followed/not applicable |
||
− | ** |
+ | ** Doorstop to link documentation and requirements to code |
− | ** Zephyr solution (originally by Intel) based on |
+ | ** Zephyr solution (originally by Intel) based on Doxygen |
+ | ** In Progress: conversion of hypercalls docs to Doxygen format |
||
− | 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 established |
||
− | Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl. |
||
+ | ** MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style. |
||
− | It needs to have a checker. |
||
+ | ** [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst|MISRA C rules officially accepted in Xen] |
||
− | It should be a well done well maintained project and coding style. |
||
+ | ** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html* |
||
− | Can we find a coding style similar to Xen coding style? |
||
+ | ** In Progress: violations reduction and MISRA C rules acceptance |
||
− | 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. |
||
+ | ** Static cpupools |
||
− | ACTION: prepare a webminar 1-2 months (option to use LF webinar) |
||
+ | ** Done: cpupools |
||
− | ACTION: write emails status updates once a quarter |
||
+ | ** In Progress: memory and heap allocation |
||
− | ACTION: keynote at XenSummit |
||
+ | * Determinism and interference reduction |
||
− | * First status update: |
||
+ | ** Interrupt latency analysis in Xen |
||
− | Misra rules already covered |
||
+ | ** Cache Coloring |
||
− | cppcheck that we want to add to Xen |
||
+ | ** In Progress: Cache Coloring upstreaming |
||
− | how much is already covered, burn down on what we want to do |
||
− | publish real-time capabilities analysis |
||
+ | * Traceability |
||
− | * Define actionable work packages for any contributors and maintainers |
||
+ | ** Trace review comments and patch versions all the way to a commit |
||
+ | ** Status: script prototype available to retrieve all mailing list discussions from a commit id |
||
− | * 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 |
||
− | |||
− | * commit review tracing |
||
− | ** get info from mailing list archive |
||
− | |||
− | * static system definition |
||
− | ** static memory allocation |
||
− | ** static heap allocation |
||
− | ** cpupools |
||
[[Category:Safety Certification/FuSa SIG]] |
[[Category:Safety Certification/FuSa SIG]] |
Latest revision as of 22:21, 11 August 2022
Scope Definition
- Hardware
- Platform core components (no platform drivers): timer, mmu, iommu, irq controller
- System configuration
- Dom0less
- Mixed criticality: a certifiable VM and a non-certifiable VM
Ongoing Efforts
- Requirements and documentation
- Doxygen for documentation of internal and external interfaces
- Doorstop to link documentation and requirements to code
- Zephyr solution (originally by Intel) based on Doxygen
- In Progress: conversion of hypercalls docs to Doxygen format
- MISRA C
- MISRA C Working Group established
- MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style.
- C rules officially accepted in Xen
- cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*
- In Progress: violations reduction and MISRA C rules acceptance
- Static System Definition
- Static memory allocation
- Static heap allocation
- Static cpupools
- Done: cpupools
- In Progress: memory and heap allocation
- Determinism and interference reduction
- Interrupt latency analysis in Xen
- Cache Coloring
- In Progress: Cache Coloring upstreaming
- Traceability
- Trace review comments and patch versions all the way to a commit
- Status: script prototype available to retrieve all mailing list discussions from a commit id