Centralize out-of-tree drivers SRPMs (including alt), their sources and documentation.#14
Merged
Conversation
a86efbb to
f3f6117
Compare
7327026 to
860ec3e
Compare
tescande
reviewed
Apr 24, 2026
tescande
left a comment
There was a problem hiding this comment.
LGTM beside a few nitpicking here and there. I'm not really familiar with github workflows but I didn't notice anything bad.
In order to support adding new drivers without regenerating the whole kabi.locked_list file (and rebuilding all drivers), support incremental mode. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
…list. This is so that we don't need to manually remember to update the list present on the (now deprecated) wiki at: https://github.com/xcp-ng/xcp/wiki/Drivers We can then either directly include this generated list into the public documentation or add a link to it at a later step. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Sometimes the more recent driver is the main one, sometimes it is the alt one. Those versions are rather hard to parse by a human, so add a visual marker ↑ to the most recent one. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Mainly: - XS base version - XS early access version - Driver is not default installed Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
…8.3 branches. This workflow runs daily and verifies if any sub-module have been updated upstream. If there are any, it will open a PR to update the corresponding git sub-module as well as regenerate the driver list in drivers/README.md. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
In order not to put the burden of updating the source sub-modules onto the developpers, this workflow will verify that for each driver srpm sub-module, a corresponding driver source sub-module exists and is matching the currently checked out revision of the srpm sub-module. If the source sub-module is missing, it will be automatically added. If the source sub-module exists but is not matching its corresponding srpm repository, then it will be refreshed and a PR automatically created. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
…sk exist. Before this commit, this information was only available by looking inside the driver-disks repository and inferring it from the config files created. Make it more user friendly by gathering this information ourself and adding it to the generated driver listing. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
…s now included. Regenerate all the Modules.kabi-* files with these newly tracked symbols. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
…ners.
The github runners might use a kernel version that make `rpmspec` un-happy:
runner@runnervmeorf1:~/work/hypervisor-dev/hypervisor-dev/drivers/8.3/srpm/qlogic-netxtreme2-alt$ rpmspec --query --qf '%{Version}-%{Release}\n' SPECS/*.spec
error: line 30: Invalid version (double separator '-'): 6.17.0-1010-azure: Requires: kernel-uname-r = 6.17.0-1010-azure
error: query of specfile SPECS/qlogic-netxtreme2-alt.spec failed, can't parse
Because we don't really care about actually building against a kernel and
are just trying to infer the version-release tuple, let's fix it to avoid
the errors altogether.
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@vates.tech>
a3d4f73 to
ff00d02
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We need a way to gather all the dom0 kernel symbols that our out-of-tree drivers rely on, so that we can know when we make a breaking kABI change to our dom0. The alt drivers were not previously part of the tracked symbols, so this PR adds them.
Because all the drivers are now centralized, it now becomes easy to generate a list of them as well as extra information about them (i.e. replacing the manually maintained https://github.com/xcp-ng/xcp/wiki/Drivers), you can see the result here: https://github.com/xcp-ng/hypervisor-dev/tree/quentin-wip-drivers/drivers
Instructions are added to the main
READMEto explain the process of adding a new driver.Because all those drivers are added as sub-modules, a branch update in their respective repository would not automatically propagate to this repository, so a new github workflow is added that will run daily and will automatically open a PR with a sub-module update when this happens.
As part of this change, for each driver srpm repository tracked, a corresponding source sub-module is added, with the result of the
rpmbuild -bpstep, so that our driver sources can now be analyzed/modified easily shall the need arise. As part of this, the workflow monitoring changes to the driver srpm repositories will automatically also update the corresponding source sub-module revision to match the driver srpm repository head.tl;dr:
drivers/8.3/srpm/: contains one sub-module per driver sRPM repository, checked out to the currently released versiondrivers/8.3/source/: contains a corresponding sub-module with the drivers source checked out, so that they can be reviewed/audited/modified easilydrivers/8.3/README.md: contains the auto-generated list of drivers that are released and maintained as part of XCP-ng 8.3.