On line 5 of a QNX 8.0 startup script, a recorder starts before the script waits for its console. BootWeave pinpointed the two lines to swap. One edit later, both device paths passed the same check on the development host.

Why line 5 matters

Consider an x86-64 lab controller with a program that records console input. Its startup script puts the console driver on line 4 and the recorder on line 5. The ampersand on the driver line launches it in the background, so the script can reach the recorder while the driver is still setting up the console. The line that waits for the console is one line further down.

BootWeave makes that detail easy to review on the development host. Give it the QNX 8.0 image buildfile fragment and a small JSON contract. The contract says which service provides each device path and which applications need it. Here, devc-con provides /dev/con1 and the sample application console-recorder reads it. BootWeave follows those names through the [+script] block and shows the startup order with source line numbers.

One edit, two paths to check

Move waitfor /dev/con1 5 above the recorder and run BootWeave again. Read the three lines in their new order. Line 4 launches the driver. Line 5 gives the console path up to five seconds to appear. Line 6 starts the recorder. The second check follows a separate path, /dev/random, through its provider, wait and example consumer. The original run reports LATE-BARRIER for the console and ORDERED for the random device. The revised run reports ORDERED for both.

From the lab example to a published QNX buildfile

BootWeave also analyzed the flash filesystem buildfile published in the QNX SDP 8.0 guide. On the host, it traced two declared dependencies of the shell, esh. For /dev/con1, it found the console driver on line 8 and the reopen on line 9. For /fs0p0, it found the flash driver on line 10 and the waitfor on line 11. Both paths lead to the same shell launch on line 12. Run python3 tests/check_reference.py to fetch the published buildfile and reproduce the two checks. QNX flash filesystem example

Try the review

Run these commands from the repository root. Compare the console finding, then follow the line numbers back to the two buildfiles. The contract stays the same for both runs.

python3 src/bootweave.py examples/before.build --contracts examples/contracts.json
python3 src/bootweave.py examples/after.build --contracts examples/contracts.json

The next code review

A reviewer can read the original and revised source lines side by side in an interactive report, then select another device to check what else changed. A build job can read the findings with --json and use the exit status to flag a change. Both use the same contract, so the decision about who needs the console travels with the image source.

How the project was developed

I set the goal for BootWeave and directed how the project was reviewed and presented. I explore the concept, design and implement the checker, run the tests, and prepare the article and demo with the help form Codex

Built With

Share this project:

Updates

Submission history