Note — Rationale de nommage de la cible *-unknown-linux-air

Statut : note de planification, NON normative. Argumentaire destiné à la soumission Target Tier 3 (item B1 de la checklist) : justifier le nom de cible et le choix target_os = "air". C’est le point que les reviewers de l’équipe compiler sonderont en premier. Prolonge ADR-088 et ADR-050.

Noms proposés

• x86_64-unknown-linux-air
• aarch64-unknown-linux-air

(les variantes *-linux-air-musl sont des cibles de transition/compat et non l’objet de la soumission Tier 3, qui porte sur le PAL safe natif.)

Forme : arch - vendor - sys - env, soit x86_64 / unknown / linux / air. La forme du triple est délibérément familière — elle calque x86_64-unknown-linux-gnu et x86_64-unknown-linux-musl : dernier champ = le runtime/ABI userland au-dessus du kernel Linux (gnu = glibc, musl = musl, air = le PAL safe d’Air).

La question centrale : target_os = "air", pas target_env = "air"

Un reviewer objectera : « la forme dit env (linux-air, comme linux-gnu) ; pourquoi alors exposer target_os = "air" et non target_env = "air" en gardant target_os = "linux" ? »

Réponse — c’est le cœur du design (ADR-088). Les variantes d’environnement de Linux (gnu, musl) partagent toutes target_os = "linux" et target_family = "unix", ce qui présuppose une libc C et la sémantique POSIX (errno in-band, unix-family std). Air rejette cette présupposition par construction : aucune libc C, un PAL safe sur nos Managers couche 1, une ABI propre. Or :

• La sélection du backend std::sys unix est piloté par target_family = "unix" / target_os = "linux". Rester os = linux forcerait le backend unix (libc) — l’exact opposé de ce qu’Air fournit.
• Il n’existe pas de mécanisme pour dire « Linux, mais hors unix-family, sans libc » via un simple target_env. La seule façon d’obtenir un backend distinct, non-unix est un target_os distinct — d’où os = "air".

Autrement dit : le triple garde la forme d’un env Linux (lisibilité, familiarité), mais la sémantique cfg est celle d’un OS distinct, parce que c’est le seul point de bascule qui donne à Air son propre backend sans traîner l’hypothèse libc.

Précédent : *-linux-android

Le précédent direct est Android : triple aarch64-linux-android, tournant sur le kernel Linux, et pourtant exposé comme target_os = "android" (backend std dédié, distinct du bras gnu/musl). Rust a déjà entériné qu’« un target_os ≠ le kernel » : os désigne la plateforme/ABI userland, pas le noyau. Air suit exactement ce motif — la différence étant qu’Android reste unix-family (bionic = libc), tandis qu’Air est le cas nouveau : un target_os sur kernel Linux délibérément hors unix-family.

Objections anticipées & réponses

• « air est vague / marketing. » air est l’identité publique du projet (Air Desktop), concise, sans collision avec un target_os existant, et cohérente avec la famille de crates air-*. On peut documenter que « air » nomme le PAL (Platform Abstraction Layer) safe, pas une marque.
• « Pourquoi pas un target_os générique (rust, safe, none) ? » none = pas d’OS (bare-metal) — faux, on a un kernel Linux et un userland riche. Un nom générique masquerait qu’on est spécifiquement sur Linux (io_uring, Landlock, seccomp, clone3… — nos choix assumés, ADR-004). air porte cette spécificité.
• « Maintenance du bras os = air dans ~15 dispatchs cfg_select!. » C’est précisément ce que résout l’RFC backend-trait (Track A) : un point d’extension unique + backend hors-arbre. Le nommage et l’RFC sont complémentaires.
• « vendor = unknown ? » Conventionnel (cf. *-unknown-linux-gnu). Aucun vendor spécifique ne s’applique.

Conclusion

{arch}-unknown-linux-air + target_os = "air" est cohérent avec les conventions Rust (forme calquée sur linux-gnu/linux-musl), précédé par linux-android (os ≠ kernel), et justifié par la seule contrainte technique dure : obtenir un backend std::sys non-unix, sans libc, ce qu’un target_env ne permet pas. Le seul aspect réellement nouveau — un target_os sur kernel Linux hors unix-family — est assumé et documenté ; c’est la raison d’être d’Air.