Difference between revisions of "FuSa SIG/Status"

From Xen
(Created page with "= Ongoing Efforts = * Requirements format (doxygen) * Misra requirement classification ** table of requirements followed/to be followed/not applicable ** doorstop (links req...")
 
(Ongoing Efforts)
(One intermediate revision by the same user not shown)
Line 1: Line 1:
  +
= 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)
  +
  +
* System configuration
  +
** dom0less
  +
** Mixed criticality (a certifiable VM and a non-certifiable VM)
  +
 
= Ongoing Efforts =
 
= Ongoing Efforts =
   
 
* Requirements format (doxygen)
 
* 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
 
* Misra requirement classification
  +
Marketing. Why the standards are there and why they can be useful. Code quality, testability, security.
** table of requirements followed/to be followed/not applicable
 
  +
Agree on process: step by step starting from the non-controversial.
** doorstop (links requirements to code)
 
  +
ACTION: prepare a webminar 1-2 months (option to use LF webinar)
** Zephyr solution (originally by Intel) based on doxygen
 
  +
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)
** goal: Misra code compliance
+
** goal: Misra code compliance
   
 
* Real-time and interference reduction
 
* Real-time and interference reduction
** real time analysis of Xen
+
** real time analysis of Xen
*** interrupt forward response time
+
*** interrupt forward response time
** cache coloring
+
** cache coloring
   
 
* commit review tracing
 
* commit review tracing
** get info from mailing list archive
+
** get info from mailing list archive
   
 
* static system definition
 
* static system definition
** static memory allocation
+
** static memory allocation
** static heap allocation
+
** static heap allocation
** cpupools
+
** cpupools
   
 
[[Category:Safety Certification/FuSa SIG]]
 
[[Category:Safety Certification/FuSa SIG]]

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)
  • 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
  • commit review tracing
    • get info from mailing list archive
  • static system definition
    • static memory allocation
    • static heap allocation
    • cpupools