08 - Open Questions for Review

This is the historical owner-decision ledger. Answered entries remain for provenance; unanswered recommendations are working defaults, not evidence of implementation or a request to reapprove accepted work. ADR-039 records the 2026-10-14 documentation revision; STATUS.md and the roadmap describe current scope. The remaining operational input is the physical HIL inventory. Q16 is now decided by the documentation tooling setup.

Decided on 2026-10-06: Q2 (licence), Q9 (hardware description), Q10 (first Cortex-M target). See ADR-004, ADR-024, ADR-025. The remaining questions keep their recommendations as the working default until answered.

A. Identity and governance

Q1. Public API prefix. Keep emb_ (recommended, ADR-002) or adopt a distinctive short prefix such as elk_? Recommendation: keep emb_; reserve embk_ for kernel internals. Never use embos.

Q2. Licence. Apache-2.0 (recommended), MIT, or something else? Is a commercial licensing option anticipated? Decided: Apache-2.0 with the Developer Certificate of Origin; outside contributions accepted; no contributor licence agreement, so dual licensing is not planned (ADR-024).

Q3. Is EmbLinkRTOS open source from the first commit, or developed privately until 1.0? Recommendation: public from the start; architecture discussion in the open attracts reviewers and board contributors. Note: the decision to accept outside contributions implies public development; confirm if you intend otherwise.

B. Kernel semantics

Q4. Default wait ordering. Priority-then-FIFO (recommended) or pure FIFO by default? Recommendation: priority-then-FIFO; pure FIFO as a per-object option. R-001 §4.1: seven of nine kernels default to priority-then-FIFO; ThreadX’s FIFO default is a documented source of inversion. Confirmed.

Q5. Mutex owner termination. Fault (recommended default) or release with EMB_EOWNERDEAD? Recommendation: fault in checked builds, configurable EOWNERDEAD for release builds that need it. R-001 §5: only ThreadX, NuttX, and uC/OS-III handle owner death at all, and none informs the next owner. Confirmed; algorithm in ADR-028. Answered 2026-10-07 (SPEC-005 §3.6, KRN-SYNC-025): CONFIG_EMB_MUTEX_OWNER_DEATH = FAULT (default) or RELEASE with EMB_EOWNERDEAD to the next owner; the inconsistent mark is cleared by the recovering owner’s unlock.

Q6. Thread cancellation in 1.0. Cooperative cancellation (recommended) or none until later? Recommendation: include it; it is small once the wait protocol has wake results. Answered 2026-10-07 (SPEC-008 §7, KRN-THR-021): cooperative cancellation with a per-thread disable count is in 1.0; there is no asynchronous terminate.

Q7. Notification width. 32 bits everywhere, or 8 bits on tiny? Recommendation: configurable, default 32, tiny profile may select 8 or 16. R-003 ADR-027: binding objects to notification bits needs spare bits; base keeps 32 with at least 16 for the application, tiny may select 8 with at least 4 (KRN-NOTIF-006). Confirmed.

Q8. Time slicing per priority level (KRN-SCH-037). Worth the configuration surface? Recommendation (revised by R-003 §3.1): no per-level table; one quantum and one threshold priority at or below which slicing applies (Zephyr TIMESLICE_PRIORITY). KRN-SCH-037 revised accordingly. Answered.

C. Platform

Q9. Hardware description: own YAML schema with importers (recommended, ADR-004) or DeviceTree source directly? This is the highest-impact platform decision. Own schema costs generator work up front; DeviceTree costs authoring pain forever and a dependency on its toolchain. Decided: own YAML schema with CMSIS-SVD and DeviceTree importers, borrowing compatible strings, bus hierarchy, named references, status flags, layered inheritance, and fixed partitions from DeviceTree; a DeviceTree exporter if interop ever requires it (ADR-004).

Q10. First Cortex-M SoC family for M3. STM32F4 (ubiquitous, Discovery boards cheap), STM32L4/U5 (low power plus Armv8-M for isolation), nRF52/nRF53 (BLE later, nRF53 is dual-core Armv8-M), RP2350 (Armv8-M plus RISC-V on one chip, cheap, ideal for AMP and for proving two ports on one board)? Decided: STM32F4 (STM32F407 Discovery or NUCLEO-F446RE) for the port, with the RP2350 (Pico 2) acquired at the same time for Armv8-M isolation in M3, RISC-V in M5, and SMP and AMP in M6; an STM32U5 or H5 class part as the second family in M4 (ADR-025).

Q11. Image format. MCUboot-compatible (recommended, ADR-008) or project-specific?

Q12. Trace format. CTF (recommended, ADR-021), or a simpler project format with an EmbDebug-only viewer?

Q13. Logging. Deferred-format as the default in base and above (recommended, ADR-009), or opt-in?

D. Engineering process

Q14. Configuration. Kconfig semantics (recommended, ADR-005) or a project-specific typed configuration language designed for EmbStudio? Note: a typed schema can be layered on Kconfig output later; starting with a custom language delays M1.

Q15. Reference model language. Python (fast to write, readable to non-C reviewers) or C on the host (closer to kernel, reusable in differential tests without a bridge)? Recommendation: Python for the model and TLA+ or exhaustive Python exploration for the wake race; the differential test bridge is a small JSON protocol. Answered 2026-10-07 (SPEC-004 §16.6): Python 3 with exhaustive section-granularity exploration in tools/model/ and hypothesis for randomized runs; the bridge is a trace replay.

Q16. Documentation toolchain. Sphinx with a requirements extension (mature traceability tooling) or MkDocs plus project scripts (simpler)? Decided 2026-10-14: Sphinx with MyST Markdown, Doxygen/Breathe for current C API, Sphinx Needs for the design catalog, and Furo for presentation. tools/docs/ builds the site and independent metadata exports; the executed requirement/test evidence matrix remains an M2 deliverable (ADR-040).

Q17. CI hardware. Which boards will be physically available for HIL in M1 to M3? This determines the HIL runner’s first targets.