Trace existing mutex and semaphore tests to KRN-SYNC-012, -013, -023, -025, -026, -028

Offen
  • Stimmt etwas nicht?
#115 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
c
Bereich
testing

Rechercherichtung

Read the Statement and Verification lines for the six requirements in docs/requirements/KRN-SYNC.md, then inspect tests/conformance/test_mutex.c and the existing semaphore cases for their EMB_TEST_REQ citations. Trace each behavior to its case and add requirement IDs only where the case verifies the statement; identify any uncovered behavior in the PR. Build and run native-gcc, collect evidence with tools/evidence/collect.py, and verify the matrix with tools/evidence/matrix.py.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

good first issue

Goal

Several mutex and semaphore requirements show no executed test in the requirement matrix, although tests for those behaviours exist. The tests cite other requirement IDs. Find which existing cases check each requirement, cite it, and add a case where none does.

This is a good way to learn how the project ties requirements to tests.

The requirements

From docs/requirements/KRN-SYNC.md:

  • KRN-SYNC-012 ceiling protocol on the same object type
  • KRN-SYNC-013 recursive locking is an option
  • KRN-SYNC-023 recursion and self-relock
  • KRN-SYNC-025 owner death policies
  • KRN-SYNC-026 ceiling rules
  • KRN-SYNC-028 semaphore semantics

For example, mutex_recursive_counts in tests/conformance/test_mutex.c checks recursion but cites only KRN-SYNC-004. mutex_owner_death_policy cites KRN-SYNC-011, not -025.

How a case cites a requirement

Inside a case, EMB_TEST_REQ("KRN-SYNC-004", ...). A run prints one CASE ... req=... line per case, and tools/evidence/matrix.py builds the matrix from them (case evidence).

Steps

  1. For each requirement, read its Statement and Verification lines.

  2. Find the cases that check what the statement says, and add the ID to their EMB_TEST_REQ. Cite only what the case really checks.

  3. Where no case checks part of a statement, write the case, or list what is missing in the PR.

  4. Build and run native-gcc (see the README's quick start). Then collect the run's evidence and build the matrix:

    python3 -I tools/evidence/collect.py --build build/native-gcc --preset native-gcc --out native-gcc.json
python3 -I tools/evidence/matrix.py native-gcc.json --baseline tools/evidence/baseline.json

Done when

  • The PR names, for each of the six requirements, the cases that now cite it, or why none can yet.
  • CI's evidence job passes. It will report the newly evidenced pairs.
Vorherrschende Sprache
C
Sterne
1
Forks
1
Ø Merge
14 Std. 21 Min.
Gemergte PRs (30 T.)
125

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus EmbLinkOs/EmbLinkRTOS

Alle Issues in EmbLinkOs/EmbLinkRTOS

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.