Skip to content

Commit bc01cf9

Browse files
haxtibalTobias Deiminger
authored andcommitted
Add README
Signed-off-by: Tobias Deiminger <tobias.deiminger@linutronix.de>
1 parent 022bbae commit bc01cf9

1 file changed

Lines changed: 94 additions & 0 deletions

File tree

README.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
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 requirements and tests from Alessandro Carminat and Gabriele Paoloni ([^1], [^2]) applied on top. ELISA's
7+
[`SPDX-*` tagging scheme]((https://docs.google.com/document/d/1c7S7YAledHP2EEQ2nh26Ibegij-XPNuUFkrFLtJPlzs/edit?tab=t.0#heading=h.9dudo2y6dlhf))
8+
was [added](https://github.com/strictdoc-project/linux-strictdoc/commit/a876ef7671c4c17396b871643f46eb15c7afea73) along
9+
with a minimal StrictDoc project configuration.
10+
11+
[^1]: https://lore.kernel.org/all/20250910170000.6475-1-gpaoloni@redhat.com/
12+
[^2]: https://lore.kernel.org/linux-trace-kernel/20250814122206.109096-1-gpaoloni@redhat.com/#r
13+
14+
Go to [rendered requirements](https://strictdoc-project.github.io/linux-strictdoc/).
15+
16+
#### Demonstrated features
17+
18+
- Use `strictdoc export .` to generate a nice
19+
[static HTML document tree](https://strictdoc-project.github.io/linux-strictdoc/linux-strictdoc/Documentation/requirements/charmisc.html)
20+
with visual representation of the traceability graph, statistics, validation results and full-text search. Other
21+
output formats as e.g. PDF are available.
22+
- Do it in
23+
[in CI](https://github.com/strictdoc-project/linux-strictdoc/blob/strictdoc/.github/workflows/ci.yaml).
24+
- Parses source code
25+
[SPDX-Req-* tags proposed by ELISA](https://docs.google.com/document/d/1c7S7YAledHP2EEQ2nh26Ibegij-XPNuUFkrFLtJPlzs/edit?tab=t.0#heading=h.9dudo2y6dlhf)
26+
and translates them to StrictDocs internal model.
27+
- Sidecar: Proposed by ELISA to hold additional requirement meta data outside source code. Realized as
28+
[separate sdoc file](https://github.com/strictdoc-project/linux-strictdoc/blob/strictdoc/Documentation/requirements/tracing.sdoc)s
29+
containing requirement stubs. Stubs are merged with source code tags by matching on `SPDX-Req-ID`.
30+
- Use `strictdoc manage auto-assign` to generate SPDX-Req-ID and SPDX-Req-HKey as suggested by Linux kernel
31+
requirements template. The hash generation method is `echo -nE "${PROJECT}${FILE_PATH}${INSTANCE}${CODE}" | sha256sum`.
32+
See [commit 2214a368](https://github.com/strictdoc-project/linux-strictdoc/commit/2214a368)
33+
for the auto-generated changes.
34+
- Tracing: Requirements, tests and functions become individual nodes in the traceability graph and are connected
35+
by their stable IDs.
36+
- Custom validations: Use plugin API to
37+
[provide a check](https://github.com/strictdoc-project/linux-strictdoc/blob/strictdoc/tools/requirements/validation_plugin.py#L28)
38+
to see if each requirement has at least one associated test, and each function expectations has at least one dedicated
39+
test.
40+
- Drift detection: As kernel development goes on, occasionally rerun `strictdoc manage auto-assign`. If `SPDX-Req-HKey`
41+
changes, this means that some semantic aspect of the requirement may have changed.
42+
43+
For a thorough documentation of StrictDocs features see
44+
[StrictDoc User Guide ](https://strictdoc.readthedocs.io/en/stable/stable/docs/strictdoc_01_user_guide.html)
45+
46+
#### Usage
47+
48+
```sh
49+
pipx install git+https://github.com/haxtibal/strictdoc.git@linux-strictdoc/integration
50+
git clone https://github.com/strictdoc-project/linux-strictdoc
51+
cd linux-strictdoc
52+
strictdoc export . # validate and render to HTML
53+
strictdoc manage auto-uid . # regenerate hashes for drift detection
54+
```
55+
56+
Note: Changes under development are planned to be released with strictdoc 0.16.0. Once published
57+
```sh
58+
pipx install strictdoc
59+
```
60+
will be enough to install.
61+
62+
#### Explanation of Content and Processing
63+
64+
```
65+
.
66+
├── Documentation
67+
│ └── requirements
68+
│ ├── charmisc.sdoc # side-car
69+
│ └── tracing.sdoc # side-car
70+
├── drivers
71+
│ └── char
72+
│ └── mem.c # Linux code with inlined LLRs
73+
├── kernel
74+
│ └── trace
75+
│ └── trace_events.c # Linux code with inlined LLRs
76+
├── strictdoc_config.py # StrictDoc project configuration
77+
└── tools
78+
├── requirements
79+
│ └── validation_plugin.py # custom requirement validations
80+
└── testing
81+
└── selftests
82+
└── devmem
83+
└── tests.c # tests for /dev/mem LLRs
84+
```
85+
86+
StrictDoc performs the following notable process steps:
87+
- parse \*.sdoc files to create the initial traceability index (a DAG structure)
88+
- parse \*.c files using tree-sitter, read SPDX tags from it and merge it into the DAG
89+
- perform built-in validations and calculate built-in statistics
90+
- perform custom validations
91+
* check if all requirements have at least one related test
92+
* check if all function expectations are mentioned by one related test
93+
- render the DAG into a HTML document tree where all nodes are traceable, including
94+
requirements text, visual graph representation and source code view

0 commit comments

Comments
 (0)