Difference between revisions of "FuSa SIG/Status"

From Xen
(Scope Definition)
Line 1: Line 1:
 
= Scope Definition =
 
= Scope Definition =
 
* Hardware
 
* Hardware
** Only platform core code (no driver)
+
** 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)
 
ACTION: write emails status updates once a quarter
+
** 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
  • 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
  • commit review tracing
    • get info from mailing list archive
    • script available to retrieve all mailing list discussions from a commit id