Adding or Customizing a Distribution
I don't know anything about QNX, but I presume it has POSIX compatibility. As far as I know, this would represent the first use of Fuego with a non-Linux OS. Although Fuego has abstractions for non-Linux operation, I don't think these have been exercised in practice.
This is particularly interesting to me right now, as I am getting ready to try to add a NuttX-based board to my lab and test it with Fuego as well.
To add your QNX toolchain, you will need to install it into the fuego docker container. Please see Adding a toolchain for instructions to do this.
You will also need to add a board file for your board, to indicate the IP address, SSH parameters, and login information. See Adding a board for that.
Since you plan to test a non-Linux OS, you will likely need to customize the "distribution" overlay for your board. Unfortunately, this is not currently documented. But I am happy to walk you through the steps needed for this (and maybe we can document this along the way). Inside the board file, there is a variable you can define that indicates the distribution on the target board. It is called "DISTRIB", and is used to select the distribution overlay file used with your board.
The "distribution" functions are defined in the file: fuego-core/overlays/base/base-distrib.fuegoclass These include functions for doing certain operations on your board, including:
You can define your own "distribution" for QNX by defining a new ".dist" file in fuego-core/overlays/distribs. (e.g. QNX.dist) Basically, you inherit functions from base-distrib.fuegoclass, and write override functions in QNX.dist to perform those operations the way they need to be done on QNX.
You can look up what each override function should do by reading the fuegoclass code, or looking at the function documentation at: Test Script APIs
The inheritance mechanism and syntax for Fuego overlay files is described at: Overlay Generation
The goal of the distribution abstraction layer in Fuego is to allow you to customize Fuego operations to match what is available on your target board. For example, the default (base class) ov_rootfs_logread() function assumes that the target board has the command "/sbin/logread" that can be used to read the system log. If QNX does not have "/sbin/logread", or indeed if there is no system log, then you would need to override ov_rootfs_logread() to do something appropriate for QNX.
Similarly, ov_rootfs_kill() uses the /proc filesystem, /proc/$pid/status, and the cat, grep, kill and sleep commands on the target board to do its work. If QNX is missing any of these, then you would need to override ov_rootfs_kill() with a function that did the appropriate thing on QNX.
There is a test you can run to see if the minimal command set required by Fuego is supported on your board. It does not require a toolchain, since it only runs shell script code on the board. The test is Functional.fuego_board_check.
A good first set of steps for supporting QNX would be:
- set up your board file
- create a custom QNX.dist (stubbing out or replacing base class functions as needed)
- add DISTRIB="QNX.dist" to your board file
- run the Functional.fuego_board_check test (using ftc, or adding the node and job to Jenkins and building the job using the Jenkins interface), and
- examine the console log to see what issues surface