Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Note — Checklist Target Tier Policy (Tier 3) annotée pour *-linux-air

Statut : note de planification, NON normative. Jauge l’écart entre notre cible {x86_64,aarch64}-unknown-linux-air et les exigences Tier 3 de la Target Tier Policy de Rust (RFC 2803 / rustc-dev-guide). À rouvrir à la clôture de la vague 1 (air-sshd), quand la publication amont devient un chantier actif. Prolonge etude-rfc-trait-backend-std-fr.md (l’RFC « backend-trait », prérequis dur) et la checklist de nommage.

Cadre : Tier 3, pas Tier 2

Tier 3 = la cible existe in-tree, compile, sans garantie CI ni binaire rustup. C’est le premier échelon réaliste. Tier 2 (std distribuée via rustup, bâtie dans la CI de Rust) supposerait que leur CI construise notre std — incompatible avec un backend hors-arbre ; objectif très lointain, hors périmètre de cette note.

Légende : ✅ satisfait · ⚠ à trancher / point sensible · 🔸 action mécanique · ❌ blocage.

A. Gouvernance & maintenance

  • A1 — Mainteneur·s de cible nommé·s (CCé·s sur les issues ; zéro mainteneur = refus). ⚠ À formaliser dans triagebot.toml/platform-support.md : personne physique (BDFL), idéalement un binôme (bus factor).
  • A2 — Acceptation de la politique (dont : Tier 3 peut casser sans préavis). ✅ Aligné avec notre doctrine (couche 0 instable, « suit le kernel »).

B. Nommage

  • B1 — Nom cohérent arch-vendor-os[-env], sans ambiguïté injustifiée. ⚠ Point le plus discuté : os = air au-dessus du kernel Linux est inhabituel. Rationale dédié : rationale-nommage-linux-air-fr.md (précédent linux-android).
  • B2 — Ajout à platform-support.md. 🔸 Fichier à fournir dans la PR d’ajout.

C. Légal & licences — point critique

  • C1 — Code entrant dans rust-lang/rust sous licence Rust (MIT OR Apache-2.0). ❌→⚠ Notre code est MPL-2.0. L’empreinte in-tree doit se limiter à la spec de cible (petit fichier de config), relicenciable MIT/Apache trivialement ; le backend PAL reste hors-arbre en MPL via le Track A (-Z build-std-platform). ⇒ gérable ssi l’empreinte in-tree reste minimale. Raison n°1 pour laquelle le Track A est un prérequis dur, pas un confort.
  • C2 — Pas de nouvelle dépendance non-permissive pour les autres cibles. ✅ Cible additive, gatée cfg(target_os="air").
  • C3 — Pas de composant propriétaire pour bâtir la cible dans rustc. ✅ 100 % Rust + syscalls Linux ouverts.

D. Support core / alloc / std

  • D1 — Implémenter autant que possible de core/alloc/std ; manques documentés. ✅ std fonctionnellement bouclée sur PAL safe, 2 arches (jalon migration-std-linux-air). Replis unsupported résiduels documentés (chantier complétion PAL). Au-dessus du seuil Tier 3 (qui tolère un std partiel).
  • D2 — unsafe conforme (SAFETY…). ✅ Résidus cantonnés à la frontière (doctrine « unsafe couche 0 seulement »).

E. Construction & intégration

  • E1 — Spec in-tree (rustc_target/src/spec), pas un JSON --target externe. 🔸 Aujourd’hui : JSON hors-arbre + build-std (rt/). Portage in-tree simple une fois le Track A en place (sinon std ne bâtit pas in-tree pour os="air").
  • E2 — Bâtit via le bootstrap standard. 🔸 Dépend d’E1 + Track A.
  • E3 — Produit de l’assembleur depuis n’importe quel hôte via un backend rustc. ✅ LLVM, x86_64 et aarch64 prouvés.

F. Non-régression & absence de charge

  • F1 — Aucune charge pour les devs Rust non concernés ; code gaté. ✅ Tout derrière cfg(target_os="air").
  • F2 — Ne casse aucune cible Tier 1/2 (ni Tier 3 sans accord). ✅ Ajout additif.
  • F3 — Qualité de code, revue habituelle. ✅ Nos standards (100 % couverture, clippy deny, fuzz) dépassent l’attendu.

G. Processus de revue

  • G1 — Approbation d’un membre de l’équipe compiler. 🔸 Étape de process de la PR d’ajout ; à préparer avec le rationale B1.
  • G2 — Aucune garantie de compat/stabilité (assumé). ✅ Conforme à notre doctrine.

Verdict & séquence

On coche l’essentiel sur le fond (std, qualité, non-régression, absence de propriétaire, arches). 3 items à trancher/agir avant soumission :

  1. ⚠ C1 — Licence : garantir empreinte in-tree = spec seule (MIT/Apache), backend hors-arbre MPL (⇒ Track A prérequis dur).
  2. ⚠ B1 — Nommage : voir le rationale dédié.
  3. ⚠ A1 — Mainteneur : désigner formellement.

Les 🔸 E1/E2/G1 sont mécaniques et débloqués par le Track A.

Chemin réel : (1) finir la vague 1 (air-sshd = démonstrateur), (2) formaliser + socialiser l’RFC backend-trait (Track A) en pré-RFC, (3) soumission Tier 3 quasi-mécanique (Track B). Le vrai goulot est l’RFC amont, pas la cible elle-même.