hwlib 0.11.1

Tool for checking Ubuntu hardware certification status
Documentation
# Test Data Directory

This example data serves two purposes:

- provides a comprehensive set of example data against which unit
  and/or component tests can be run

- serve as a means of demonstrating to interested parties exactly what
  data the library collects and is transmitted to the hardware API
  server. All fields should be non-uniquely indentifiable to ensure
  that they tracking or tracing of machines interacting with service
  is possible

Currently, the project uses test data of the following machines:

- NVIDIA DGX-Station:
  [ubuntu.com/certified/201711-25989]https://ubuntu.com/certified/201711-25989
- Lenovo ThinkStation P620:
  [ubuntu.com/certified/202203-30052]https://ubuntu.com/certified/202203-30052
- Dell XPS 13 9340:
  [ubuntu.com/certified/202405-34051]https://ubuntu.com/certified/202405-34051
- Raspberry Pi 4 Model B 8 GB:
  [ubuntu.com/certified/202004-27865]https://ubuntu.com/certified/202004-27865

## Structure Overview

The `test_data` directory has the following structure:

```
├── <arch>
│   ├── <device_model>
│   │   ├── <hardware_related_data>
│   │   └── request.json
```

Key Files:

- `cpuinfo_max_freq` — Contains maximum CPU frequency data. Can be
  fetched from `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq`
- `DMI` — DMI table data, can be retrieved from the
  `/sys/firmware/dmi/tables/` directory.
- `smbios_entry_point` — SMBIOS entry point details. Is located in the
  `/sys/firmware/dmi/tables/` directory.
- `version` — Kernel version file (`/proc/version`).
- `request.json` — Expected request body that should be constructed.
- `cpuinfo` — CPU information, see `/proc/cpuinfo`. If used only for
  non-amd64 machine.
- `device-tree/` (dir) — arm64 specific directory with system
  information. See `/proc/device-tree`.

## Adding New Test Cases

1. Create a new directory under `amd64/` or `generic/` based on your
   test requirements.
2. Populate it with the necessary files (`cpuinfo_max_freq`, `DMI`,
   etc.). **Make sure you replace all the sensitive data like serial
   numbers with zeroes.** You can use the
   [`sed`]https://man7.org/linux/man-pages/man1/sed.1.html tool for
   it.
3. Add `request.json` with anticipated values to validate against.
   Replace the values that you want to use variable with placeholders, for example:
   ```
   "os": {
    "codename": "$CODENAME",
    "distributor": "Ubuntu",
    "kernel": {
      "loaded_modules": $KERNEL_MODULES,
      "name": "Linux",
      "signature": null,
      "version": "$KERNEL_VERSION"
    },
    "version": "$RELEASE"
   }
   ```

   In this example, we replace values in the quotes with strings
   defined in the test cases, and `$KERNEL_MODULES` gets replaced
   with a dict. This is how the test case is defined (see tests in the
   [models/request_validators.rs]../src/models/request_validators.rs for
   more):

   ```rust
   #[test_case(
       "amd64/thinkstation_p620",  // dir name
       "focal",  // Ubuntu release codename
       "20.04",  // The release itself
       "5.15.0-125-generic",  // kernel version from the {dir_name}/version file
       &["xt_tcpudp", "nft_chain_nat"];  // kernel modules
       "focal_thinkstation"  // test case name
   )]
   ```

4. If you're adding a test case for a certified machine, update this
   document to include link to the machine on
   [ubuntu.com/certified]https://ubuntu.com/certified.