Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for BootWave
BootWave is a Windows/Python host tool that turns one explicit service configuration into a QNX 8.0 BSP fragment, an SLM configuration and a small readiness helper. An embedded developer can keep early driver launches and the applications that depend on them in one source, inspect the required target files, and replay the generated dependencies before acquiring a target environment.
QNX already provides dependency-based launch and failure management through System Launch and Monitor, SLM. Its official documentation describes a DAG, readiness conditions and stopping or restarting dependent processes. BootWave uses that existing service. Its contribution is the implemented configuration conversion and the checks around the developer's chosen BSP-to-SLM boundary, rather than a new scheduler or a claim that SLM cannot launch those drivers.
The developer supplies absolute executable paths and separate argument lists, dependencies, a BSP or SLM phase, readiness conditions, timeouts and a first useful application. The supported BSP subset starts independent services only. Screen uses its documented self-daemonizing route without an ampersand. SLM-managed services must be declared to stay in the foreground. Raw command strings, environment prefixes and buildfile modifiers are rejected, including the previously problematic '[pri=10] screen' and 'FOO=bar screen' forms. A network readiness check must be an explicit exit-zero component such as if_up -p; an interface is not represented by a fictitious device path.
The emitted buildfile contains ordinary launch commands and the documented positional SLM configuration argument. It contains no shell conditionals. The separate shell helper calls the external waitfor utility and returns success only if waitfor succeeds and the path still exists. SLM waits for that helper to exit with code zero; downstream components depend on that gate. Native SLM handles managed launch failures and dependency repair. An initial BSP process is outside SLM's process monitoring, so its gate checks the declared path under the requirement that it is fresh, not ongoing process health.
The package declares its runtime requirements: slogger2 must already be running, and SLM, the shell, the external waitfor utility, the helper, XML configuration, service binaries and their libraries must be present at the reviewed target paths. The example paths and demo applications are synthetic placeholders. The converter does not discover hardware dependencies or decide which services a board permits to start concurrently.
The implementation now emits all four outputs and replays the actual BSP lines, XML prerequisites, exit conditions and helper contract. Verification covers 100 seeded dependency configurations, invalid command forms, altered output dependencies, missing readiness paths and failed commands. Missing storage readiness blocks its dependent logger while the independent splash path proceeds. A managed application's launch failure blocks its dependent client. An actual host POSIX shell also checked the generated helper's success and failure branches with a controlled waitfor substitute; no QNX utility was executed.
The five-service example's virtual-time output replay reaches the first useful application at 1.14 seconds and all declared resources at 1.52 seconds. A well-arranged manual order and a separately handwritten SLM configuration produce the same values. In the timing-reversal example, A takes four seconds while B is ready at 0.2 seconds and C needs one second after B. BootWave and the well-arranged manual order both reach C at 1.2 seconds and finish at four seconds; the former estimate-ordered blocking sequence finishes at five. These are synthetic model results, with no CPU, storage, polling or helper-launch overhead measurement, and do not establish faster QNX boot or better configuration usability.
The next target milestone is to review the BSP boundary and file inventory, build the same artifacts with mkifs, run them under QNX 8.0 SLM, inject readiness and command failures, and measure the first useful application and total readiness against the manual and handwritten SLM references.
