|
| 1 | +# Exploring possibilities for integrating StrictDoc with ELISA’s requirements template approach for the Linux kernel |
| 2 | + |
| 3 | +This demonstrates how to realize the tool-agnostic |
| 4 | +[ELISA Kernel Requirements Template](https://docs.google.com/document/d/1c7S7YAledHP2EEQ2nh26Ibegij-XPNuUFkrFLtJPlzs/edit?tab=t.0) |
| 5 | +proposal by using [StrictDoc](https://strictdoc.readthedocs.io) as requirements processing tool. The repository contains a filtered (for brevity) |
| 6 | +copy of the Linux kernel, with patches from Alessandro Carminat and Grabriele Paoloni ([^1], [^2]) applied to add a first |
| 7 | +round of requirements and tests to the code. ELISA's |
| 8 | +[`SPDX-*` tagging scheme]((https://docs.google.com/document/d/1c7S7YAledHP2EEQ2nh26Ibegij-XPNuUFkrFLtJPlzs/edit?tab=t.0#heading=h.9dudo2y6dlhf)) |
| 9 | +was [added](https://github.com/strictdoc-project/linux-strictdoc/commit/a876ef7671c4c17396b871643f46eb15c7afea73) along |
| 10 | +with a minimal StrictDoc project configuration. |
| 11 | + |
| 12 | +[^1]: https://lore.kernel.org/all/20250910170000.6475-1-gpaoloni@redhat.com/ |
| 13 | +[^2]: https://lore.kernel.org/linux-trace-kernel/20250814122206.109096-1-gpaoloni@redhat.com/#r |
| 14 | + |
| 15 | +Go to [rendered requirements](https://strictdoc-project.github.io/linux-strictdoc/). |
| 16 | + |
| 17 | +#### Demonstrated features |
| 18 | + |
| 19 | +- Use `strictdoc export .` to generate a nice |
| 20 | + [static HTML document tree](https://strictdoc-project.github.io/linux-strictdoc/linux-strictdoc/Documentation/requirements/charmisc.html) |
| 21 | + with visual representation of the traceability graph, statistics, validation results and full-text search. Other |
| 22 | + output formats as e.g. PDF are available. |
| 23 | +- Parses source code |
| 24 | + [SPDX-Req-* tags proposed by ELISA](https://docs.google.com/document/d/1c7S7YAledHP2EEQ2nh26Ibegij-XPNuUFkrFLtJPlzs/edit?tab=t.0#heading=h.9dudo2y6dlhf) |
| 25 | + and translates them to StrictDocs internal model. |
| 26 | +- Sidecar: Proposed by ELISA to hold additional requirement meta data outside source code. Realized as |
| 27 | + [separate sdoc file](https://github.com/strictdoc-project/linux-strictdoc/blob/strictdoc/Documentation/requirements/tracing.sdoc)s |
| 28 | + containing requirement stubs. Stubs are merged with source code tags by matching on `SPDX-Req-ID`. |
| 29 | +- Use `strictdoc manage auto-assign` to generate SPDX-Req-ID and SPDX-Req-HKey as suggested by Linux kernel |
| 30 | + requirements template. The hash generation method is `${PROJECT}${FILE_PATH}${INSTANCE}${CODE}" | sha256sum`. See |
| 31 | + [commit 6a2952e8](https://github.com/strictdoc-project/linux-strictdoc/commit/6a2952e8) |
| 32 | + for the auto-generated changes. |
| 33 | +- Tracing: Requirements, tests and functions become individual nodes in the traceability graph and are connected |
| 34 | + by their stable IDs. |
| 35 | +- Custom validations: Use plugin API to |
| 36 | + [provide a check](https://github.com/strictdoc-project/linux-strictdoc/blob/strictdoc/tools/requirements/validation_plugin.py#L28) |
| 37 | + to see if each requirement has at least one associated test, and each function expectations has at least one dedicated |
| 38 | + test. |
| 39 | +- Drift detection: As kernel development goes on, occasionally rerun `strictdoc manage auto-assign`. If `SPDX-Req-HKey` |
| 40 | + changes, this means that some semantic aspect of the requirement may have changed. |
| 41 | + |
| 42 | +For a thorough documentation of StrictDocs features see |
| 43 | +[StrictDoc User Guide ](https://strictdoc.readthedocs.io/en/stable/stable/docs/strictdoc_01_user_guide.html) |
| 44 | + |
| 45 | +#### Explanation of Content and Processing |
| 46 | + |
| 47 | +``` |
| 48 | +. |
| 49 | +├── Documentation |
| 50 | +│ └── requirements |
| 51 | +│ ├── charmisc.sdoc # side-car |
| 52 | +│ └── tracing.sdoc # side-car |
| 53 | +├── drivers |
| 54 | +│ └── char |
| 55 | +│ └── mem.c # Linux code with inlined LLRs |
| 56 | +├── kernel |
| 57 | +│ └── trace |
| 58 | +│ └── trace_events.c # Linux code with inlined LLRs |
| 59 | +├── strictdoc_config.py # StrictDoc project configuration |
| 60 | +└── tools |
| 61 | + ├── requirements |
| 62 | + │ └── validation_plugin.py # custom requirement validations |
| 63 | + └── testing |
| 64 | + └── selftests |
| 65 | + └── devmem |
| 66 | + └── tests.c # tests for /dev/mem LLRs |
| 67 | +``` |
| 68 | + |
| 69 | +StrictDoc performs the following notable process steps: |
| 70 | +- parse \*.sdoc files to create the initial traceability index (a DAG structure) |
| 71 | +- parse \*.c files using tree-sitter, read SPDX tags from it and merge it into the DAG |
| 72 | +- perform built-in validations and calculate built-in statistics |
| 73 | +- perform custom validations |
| 74 | + * check if all requirements have at least one related test |
| 75 | + * check if all function expectations are mentioned by one related test |
| 76 | +- render the DAG into a HTML document tree where all nodes are traceable, including |
| 77 | + requirements text, visual graph representation and source code view |
0 commit comments