The Kernel Development Process WG will be working on a predefined list of tasks agreed by the group.
The task list will be updated from time to time, as tsaks are completed or rejected, when relevant.
The initial task list agreed by the WG is outlined below.
For each task there is a dedicated owner. Owner responsibilities include:
- Initial scoping
- Track status and provide leadership
- Handover / park the task if they can no longer spare the time to own
For each task we define:
- Goals and scope of the topic
- "Definition of Done" for that task - e.g., create a skeleton of the document for review with one section fully populated.
- Milestones
-
Architectural analysis of on an example Linux kernel sub-system
- Owner: Elana Copperman
- In coordination with the Safety Architecture, Automotive and Medical Devices WGs, choose a key Kernel subsystem and work through the “What we can do in ELISA?” proposals identified in the Testing Process Gap Analysis.
- It was proposed that the Watchdog sub-component is both relevant for current work in the Architecture and Automotive WGs, and also not overly complex, so that the WG could completely work through a number of the proposals.
- The Memory Management subsystem was also proposed; this is more complex, but more widely applicable.
-
"Big picture" for Tools subgroup.
- Owner: Lukas Bulwahn
- Engage with the Tools subgroup to define the “big picture” for their work on static analysis and MISRA checkers.
– Analyze how the results for specific examples can be built up to a methodology which justifies why a patchset for a new feature should be added:
- Compliance with requirements
- Compliance between source code and specs (is this relevant for Linux? Where are the specs?)
- Compliance with HSI spec (see intro to WD analysis above, we need to define such a spec for Linux so that we can analyze the hardware software interface).
- Absence of unintended functionality
- Implementation of safety measures derived from the safety analysis.
-
Kernel configurations
- Owner: Elana Copperman
- Continued low key (mostly offline) work on kernel configuration database https://docs.google.com/spreadsheets/d/15wbukSZ5lSR-YhzED8ojfFh2FAyAog1o3Hh84-JyRHA/edit#gid=1513725300
- Elana to work offline, based on workshop feedback. Present to WG for feedback and alignment in ~6 weeks (tentatively on April 22) and plan an extended (~1 hour) session at the next workshop.
- Identify safety kernel configurations which can be defined for specific use cases. Stretch goal, pending preliminary results from work on safe kernel configuration database.
-
Improve documentation
- Owner: Paul Albertella
- Improve documentation of APIs in Linux kernel, as well as documentation of kernel interfaces (to user, hardware, between components) and behavior.
- Following model of (1) above, start with a specific agreed area to focus.
- Following model of (4) above, work offline and periodically align with the WG.
-
Publish results
- Owner: Paul Albertella.
- Finalize and publish report on test frameworks; needs review and editing. Details TBD following next TSC meeting and clarifications from Kate (+ consensus with TSC). How, when to publish; pitfalls to avoid.
- Publish the Reference Process, to provide information on safety standard expectations for those who do not have access to the safety standards documents. Issue to resolve: does the Reference Process infringe the copyright for the source standards that it indexes / references?
-
Further process assessment
- Owner: Peter Brink. Contributors: Kent Nelson (co-owner), Kate Stewart (existing document from Jochen), Roberto Paccapeli (ERP)
- Extend the analysis applied to the Testing Process Assessment to cover other aspects of the Reference Process / standards. e.g. Tasks related to section 8 of ISO26262 (from line 48 in the testing process assessment spreadsheet).
- Revisit and see if there is anything relevant for follow up.
- How do we extend to other (no-automotive) standards?