Analyseur d'arguments DOCA

Par où commencer : Cette skill suppose que DOCA est déjà installé et que l'utilisateur effectue un travail CLI pratique sur un exemple DOCA ou une nouvelle application utilisant DOCA. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur ce que peut exprimer l'Analyseur d'arguments dans cette version. Si l'utilisateur n'a pas encore installé DOCA, dirigez-le d'abord vers doca-setup. Si l'utilisateur s'apprête à réécrire le CLI d'un exemple avec getopt / argparse / une analyse personnalisée au lieu de réutiliser l'Analyseur d'arguments, lisez la règle fondamentale dans CAPABILITIES.md ## Capabilities and modes avant toute modification de code.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions sur l'Analyseur d'arguments que cette skill est construite pour répondre, chacune avec un exemple traité. L'agent doit traiter la classe comme l'élément fondamental — l'exemple traité est une seule instance.

« Comment ajouter un nouvel indicateur à un exemple DOCA sans casser le CLI standard ? » — exemple traité : « ajouter --my-flag à /opt/mellanox/doca/samples/doca_dma/dma_local_copy/ pour que l'exemple accepte toujours --device <PCI> et --sdk-log-level <level> de la même façon ». Répondu par la règle de réutilisation de l'Analyseur d'arguments dans CAPABILITIES.md ## Capabilities and modes + le workflow register-before-start dans TASKS.md ## modify.
*« Pourquoi `doca_argp_paramsetretourneBAD_STATEà mon deuxième appel ? »** — exemple traité : *« enregistrer un nouveau paramètre après quedoca_argp_startait déjà analysé argv »*. Répondu par l'ordre du cycle de vie dans [CAPABILITIES.md ## Capabilities and modes](CAPABILITIES.md#capabilities-and-modes) + la ligne de taxonomie des erreurs dans [CAPABILITIES.md ## Error taxonomy](CAPABILITIES.md#error-taxonomy) pourDOCA_ERROR_BAD_STATE`.
« Puis-je piloter un exemple à partir d'un fichier JSON au lieu d'une longue ligne de commande ? » — exemple traité : « pointer un exemple vers ./my-config.json pour que l'opérateur n'ait pas à taper dix indicateurs chaque fois ». Répondu par l'intégration --json <path> dans CAPABILITIES.md ## Capabilities and modes + le workflow de fichier de configuration JSON dans TASKS.md ## modify et TASKS.md ## run.
« Ma valeur --my-flag X est rejetée comme INVALID_VALUE — pourquoi ? » — exemple traité : « j'ai déclaré le paramètre comme int mais j'ai passé --my-flag 0x40 ». Répondu par le tableau des types de paramètres dans CAPABILITIES.md ## Capabilities and modes + la ligne de non-concordance de type dans CAPABILITIES.md ## Error taxonomy.
« Est-ce que doca-argp est même sur mon DOCA installé ? » — exemple traité : « un collègue mentionne doca-argp dans un exemple mais je veux confirmer avant d'en dépendre ». Répondu par la règle de détection de présence et version dans CAPABILITIES.md ## Version compatibility, qui renvoie vers la chaîne de détection canonique dans doca-version.
« Dois-je utiliser doca-argp ici, ou ce cas est-il vraiment en dehors de son champ d'application ? » — exemple traité : « écrire un outil CLI côté hôte qui n'appelle jamais un symbole `doca_»*. Répondu par la règle de sélection du chemin dans [CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes) Utilisez doca-argp quand … / N'utilisez pas doca-argp quand … puces.

Audience

Cette skill sert les développeurs externes construisant ou modifiant des applications utilisant DOCA — c'est-à-dire les utilisateurs dont le code appelle déjà doca_* (directement en C/C++, ou via FFI/bindings depuis un autre langage) et qui ont besoin de la surface CLI standard DOCA pour que les opérateurs du binaire résultant n'aient pas à réapprendre comment invoquer chaque exemple. Ce n'est pas pour les développeurs NVIDIA contribuant à la bibliothèque Analyseur d'arguments elle-même.

Champ de langue. L'Analyseur d'arguments DOCA est fourni en tant que bibliothèque C avec le nom de module pkg-config doca-argp. Les exemples fournis sont écrits en C. Les consommateurs C et C++ constituent le cas canonique ; les exemples traités dans TASKS.md supposent ce chemin. Les consommateurs en d'autres langues (Rust, Go, Python, …) consomment le même *.so via FFI ou des bindings spécifiques à la langue ; la contribution de la skill dans ce cas est de garder les conseils du cycle de vie, du type de paramètre, de la configuration JSON, de la surface des indicateurs standard, et de la taxonomie des erreurs indépendants du langage, et de router l'agent vers l'ABI C public en tant que surface faisant autorité que tout wrapper appellera finalement.

Quand charger cette skill

Chargez cette skill quand l'utilisateur effectue un travail pratique d'Analyseur d'arguments DOCA, dans n'importe quelle langue. Concrètement :

Ajouter, supprimer ou renommer un indicateur CLI sur un exemple DOCA fourni ou sur une nouvelle application qui souhaite partager la surface CLI standard DOCA (--device <PCI>, --representor <name>, --rep-list, --json <path>, --sdk-log-level <level>).
Câbler doca_argp_init / doca_argp_start / doca_argp_destroy dans une main(), y compris le cycle de vie register-before-start et le contrat cleanup-on-exit.
Enregistrer un doca_argp_param (nom court, nom long, rappel de valeur, description pour --help) avec un type de paramètre extrait du petit ensemble public (chaîne, entier, indicateur booléen, fichier de configuration JSON).
Lire des configurations complexes à partir d'un fichier JSON via l'indicateur partagé --json <path> au lieu d'étendre la ligne de commande.
Confirmer la version de l'Analyseur d'arguments côté compilation et runtime sur l'installation de l'utilisateur (pkg-config --exists doca-argp, pkg-config --modversion doca-argp) avant de dépendre de celui-ci.
Déboguer un DOCA_ERROR_* retourné par un appel doca_argp_* (violations du cycle de vie vs. non-concordance de type vs. clé JSON inconnue vs. fichier illisible).
Concevoir ou étendre des bindings non-C (Rust, Go, Python, …) qui enveloppent l'ABI C de l'Analyseur d'arguments — pour les règles du cycle de vie, du type de paramètre, de la configuration JSON, et des indicateurs standard que l'enveloppe doit respecter.

Ne chargez pas cette skill pour l'orientation générale de DOCA, l'installation de DOCA lui-même, ou les questions de bibliothèque non-Analyseur d'arguments. Pour cela, utilisez doca-public-knowledge-map.

Ce que cette skill fournit

Ceci est un chargeur léger. Le corps ne conserve que l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique à l'Analyseur d'arguments vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que l'Analyseur d'arguments peut exprimer dans cette version : le modèle d'enregistrement des paramètres, le petit ensemble des types de paramètres publics, la surface CLI standard DOCA que chaque exemple partage, l'intégration du fichier --json <path>, le cycle de vie register-before-start, la taxonomie des erreurs de l'Analyseur d'arguments (mappée sur l'ensemble DOCA_ERROR_* transversal), la surface d'observabilité (la sortie --help et le canal DOCA Log), et la politique de sécurité / sélection du chemin (quand réutiliser doca-argp est obligatoire ; quand un analyseur natif du langage est la bonne réponse).
TASKS.md — workflows étape par étape pour les six verbes Analyseur d'arguments en scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la bonne skill suivante.

La skill suppose un hôte ou BlueField où DOCA est déjà installé à l'emplacement standard. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup.

Ce que cette skill délibérément ne fournit pas

Cette skill est une orientation pour l'agent, pas un bundle d'exemples ou de modèles. Pour garder la frontière claire, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Code d'utilisation pré-écrit de l'Analyseur d'arguments DOCA, dans n'importe quelle langue. L'utilisation vérifiée de l'Analyseur d'arguments est le fichier *_main.c dans chaque exemple DOCA fourni à /opt/mellanox/doca/samples/<library>/<sample>/. Le travail de l'agent est de router l'utilisateur vers ce fichier et de prescrire une modification avec diff minimal sur celui-ci via le workflow universal modify-a-sample dans doca-programming-guide, stratifié avec les surcharges spécifiques à l'Analyseur d'arguments dans TASKS.md ## modify.
Manifestes de compilation autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) garés à l'intérieur de la skill. L'agent construit le manifeste de compilation dans le répertoire du projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-argp est la source de vérité.
Un sous-arbre samples/, bindings/, ou reference/ de quelque sorte. Un artefact factice ou incomplet dans l'arborescence de cette skill, même étiqueté « reference », est trompeur : les utilisateurs le liront comme compilable.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope.
Pour le modèle d'enregistrement des paramètres, les types de paramètres, la surface CLI standard DOCA, la règle --json <path>, le cycle de vie register-before-start, la taxonomie des erreurs, l'observabilité, et la politique de sélection du chemin / sécurité, consultez CAPABILITIES.md.
Pour les workflows étape par étape — configure, build, modify, run, test, debug — consultez TASKS.md.

Les deux fichiers compagnons se renvoient mutuellement, doca-version pour les règles canoniques de gestion des versions, et doca-public-knowledge-map chaque fois que la bonne réponse est « regardez dans la documentation publique ou la disposition du package installé » plutôt que « orientation spécifique à l'Analyseur d'arguments ».

Skills connexes

doca-public-knowledge-map — le tableau de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un package DOCA installé. L'URL de l'Analyseur d'arguments est https://docs.nvidia.com/doca/sdk/DOCA-Arg-Parser/index.html ; l'exemple d'utilisation canonique sur disque est le *_main.c de n'importe quel exemple sous /opt/mellanox/doca/samples/.
doca-setup — préparation de l'environnement, vérification de l'installation, et le chemin Je n'ai pas encore d'installation avec le container DOCA NGC public. Cette skill suppose que ses préconditions sont satisfaites.
doca-version — règles canoniques de gestion des versions DOCA. Le ## Version compatibility de cette skill renvoie vers la règle de concordance quadruple et ajoute la surcharge de vérification de présence spécifique à l'Analyseur d'arguments.
doca-structured-tools-contract — la règle de précédence structured-tools du bundle (détecter / préférer / se replier / signaler). L'appendice Command dans TASKS.md honore ce contrat.
doca-programming-guide — les motifs de programmation DOCA généraux partagés par chaque bibliothèque : le motif de compilation pkg-config + meson canonique, le workflow universel modify-a-shipped-sample first-app, le cycle de vie universel, la taxonomie DOCA_ERROR_* transversale, et l'ordre de débogage côté programme. Cette skill stratifie les spécificités de l'Analyseur d'arguments par-dessus.
doca-debug — l'échelle de débogage transversale (installation / version / compilation / liaison / runtime / programme / pilote). Le débogage spécifique à l'Analyseur d'arguments (violations du cycle de vie, non-concordance de type sur un paramètre enregistré, clé JSON inconnue) se stratifie par-dessus cette échelle.