Boro est une interface en ligne de commande (CLI) assistée par IA que NVIDIA développe pour aider les contributeurs à travailler sur le noyau Linux dans leur propre arbre Git. Elle couvre plusieurs étapes du cycle d’un correctif : revue, compilation, tests ciblés et application de commits. Andrea Righi a présenté le projet pendant la Linux Plumbers Conference 2026, organisée à Prague du 5 au 7 octobre.

Boro, un outil pour le travail local sur le noyau

Le noyau est la partie centrale de Linux, celle qui fait le lien entre le matériel et les logiciels. Boro s’insère dans le travail d’un développeur sur une copie Git du noyau, avant l’envoi public d’un correctif ou pour la maintenance de versions adaptées à une distribution. Ce travail peut notamment porter sur des rétroportages — l’adaptation d’un correctif à une version plus ancienne — ou sur l’intégration de correctifs de sécurité.

Le dépôt de NVIDIA décrit Boro comme un outil pour examiner et tester des correctifs. Il ne prend pas la place du processus de décision du projet Linux : ses fonctions assistent le travail sur une copie locale, elles ne fusionnent pas automatiquement les changements dans le noyau.

Revue, compilation, tests et application de correctifs

La commande boro review COMMIT_RANGE examine une plage de commits au moyen d’un processus en plusieurs étapes. Le dépôt énumère les étapes de 0 à 12 : elles passent par l’identification des consignes propres au sous-système concerné, l’analyse du code et la consolidation des résultats. La commande produit un compte rendu narratif dans un style proche des messages de la liste de diffusion du noyau Linux.

Pour vérifier la compilation, boro build COMMIT_RANGE place les commits dans des arbres de travail séparés, puis lance leur compilation. Un modèle analyse ensuite les journaux de compilation afin d’aider à trier les erreurs.

La commande boro test COMMIT_RANGE peut démarrer un noyau dans une machine virtuelle avec virtme-ng, puis exécuter un test ciblé choisi par un modèle. Les tests peuvent inclure des kselftests correspondants ou des sondes en espace utilisateur sur les chemins de code modifiés ; dmesg, le journal des messages du noyau, peut servir de solution de repli. Les tests longs ou dépendants du matériel peuvent aussi être décrits dans un plan sans être exécutés.

Enfin, boro apply permet d’appliquer des commits ou une série récupérée depuis une liste de diffusion. En cas de conflit lors d’un cherry-pick — l’application d’un commit sur une autre branche — Boro peut proposer une résolution, qu’un modèle de validation examine. Une proposition de résolution reste une étape de travail, pas une intégration automatique au noyau.

Modèles et utilitaires nécessaires

Boro accepte la configuration de services compatibles avec l’API d’OpenAI. Le dépôt décrit également des backends d’agents pour Claude, OpenCode et Codex : il s’agit d’options à configurer, pas de modèles fournis avec Boro.

Les dépendances varient selon la tâche. virtme-ng est nécessaire aux fonctions de compilation et de test. b4 est requis pour appliquer une série identifiée par un message de liste de diffusion, tandis que lei, facultatif, permet de récupérer des échanges publiés sur lore.kernel.org.

Une éventuelle passerelle vers Sashiko

La description de la présentation à la Linux Plumbers Conference indique qu’Andrea Righi a proposé de discuter de la possibilité d’intégrer certaines fonctions de Boro à Sashiko, un outil de revue de correctifs assisté par IA. Cette piste était un sujet de discussion, et non une intégration annoncée comme réalisée.

Le dépôt de Boro place le projet sous licence Apache 2.0.