News › linux
By The Linux Camp News, October 9, 2026
Boro brings model-assisted review, conflict repair and optional kernel testing into a developer's Git workflow. Its repair mode changes commits, while its quick VM tests have important coverage limits.
NVIDIA's Boro, an AI-assisted command-line tool for Linux kernel development, was the subject of an October 9, 2026 Phoronix report after several months of development. The project targets local kernel-development work rather than a change to the kernel itself. This is coverage of an existing development effort, not an established first-release date. 1
According to Phoronix, NVIDIA's Andrea Righi presented Boro at LPC 2026 in Prague. The repository documentation retrieved October 9 describes its intended users more precisely: developers preparing patches before public submission, and maintainers carrying downstream patch stacks. That includes distribution kernels, backports and security-fix integration, where the work may never pass through the normal mailing-list review process. 1 2
Boro's review design separates broad and specialist analysis from stronger validation and reporting. The documented intent is to spend less on exploratory passes while reserving a stronger model for checking and presenting findings. One suggested arrangement uses a local model for discovery and a remote model for validation. The operational inference is important: a local Git workflow does not imply local-only inference. Check the validator's endpoint as well as the main model's before treating a setup as local-only. 2
Backport repair goes beyond advisory comments. For unresolved cherry-pick conflicts, the main model proposes a resolution for each conflict hunk, meaning a conflicting section of a file. A validation model accepts or rejects it; rejection feeds another attempt, up to ten rounds per hunk. If all hunks pass, Boro rewrites and stages the files and continues the cherry-pick. Model acceptance therefore triggers an actual repository change, not merely a suggestion for a developer to copy. 2
Optional build and test modes add execution evidence to patch analysis. Build mode checks out each commit in a separate worktree and asks the model to triage its build log. Test mode also boots the kernel under virtme-ng and runs a model-selected quick test: a matching kernel self-test, a userspace probe or a kernel-log fallback. For downstream maintainers, the practical change is a connected per-commit build, boot and triage workflow, rather than review based only on source changes. 2
Check dependencies against the workflow being evaluated. Importing a posted series by message ID requires b4; building and testing requires virtme-ng. The optional lei tool enables upstream mailing-list retrieval. Without it, Boro still runs the other review stages and retains its Linux-master Fixes lookup, but skips that retrieval. A completed review should therefore not be read as evidence that mailing-list follow-ups were consulted unless that capability was available. 2
Series application is not all-or-nothing: Boro stops at the first failure and leaves earlier commits applied. The practical implication is to inspect the resulting patch stack after a failed run rather than assume it returned to its starting point. The documented dry-run option only lists the series; it is not a trial execution of conflict repair. 2
Test results need equally explicit boundaries. Boro's plan mode generates instructions without building or booting a kernel, even when those instructions describe hardware-dependent or long-running tests. Executed virtme-ng tests also trade configuration breadth for speed: its kernels deliberately omit many features. The resulting inference is that a successful quick VM test cannot establish coverage of every production configuration or hardware-dependent path; those checks remain separate work. 2 3