Aller au contenu
Table des matières

switch-wifi : Séparer les mesures réseau de l’interface

switch-wifi est un tableau de bord réseau pour Switch avec une interface Borealis. Il sépare les calculs portables de l’application console pour permettre de tester le cœur sans la chaîne de compilation Switch.

Matériel et infographie Docker
  • Mis à jour
  • C++ · 86.58%
  • MIT
Composants documentés
2Explorer les modules
Documents source
2Lire les instructions
Langages du dépôtC++ 86.58%3

Parts calculées à partir des octets GitHub Linguist.

C++86.58%
86.58%61 640 octets
CMake8.31%
8.31%5 914 octets
Python5.11%
5.11%3 639 octets
Langage%Octets
C++86.58%61 640
CMake8.31%5 914
Python5.11%3 639

1. Aperçu

1.1. Pourquoi il existe

Utilitaire C++ natif communiquant directement avec les services wlan de l'OS Switch.

1.2. Cas d’usage

Configuration réseau rapide pour console Switch sans interface complexe.

2. Cas d’utilisation

Application homebrew pour Nintendo Switch qui affiche l'état du Wi-Fi, mesure le lien HTTPS et lit l'état Bluetooth.

Diagramme de cas d’utilisation de switch-wifi : Vérifier le lien Wi-Fi; Mesurer la connexion; Voir les réseaux enregistrés; Inspecter le Bluetooth; Exporter un rapportswitch-wifiVérifier le lien Wi-FiMesurer la connexionVoir les réseaux enregistrésInspecter le BluetoothExporter un rapportJoueur sur Switch«système»Horizon NIFM / BTM«système»Serveur de débit HTTPS
Acteurs à gauche (personnes) et à droite (systèmes externes) ; chaque ovale est un cas d’utilisation appuyé par les fichiers cités ci-dessous.
Vérifier le lien Wi-Fi
Joueur sur SwitchHorizon NIFM / BTM

L'onglet Dashboard lit le type de lien, le SSID, l'IPv4, la passerelle, le DNS et les barres de signal 0 à 3 via NIFM (NetworkService) ; le RSSI vient de wlan:inf seulement si le micrologiciel l'expose.

Mesurer la connexion
Joueur sur SwitchServeur de débit HTTPS

SpeedTestEngine lance 8 sondes de latence HTTPS, puis un téléchargement de 25 Mio et un envoi de 10 Mio remplis de zéros avec libcurl vers speed.cloudflare.com par défaut, avec médiane, P95 et gigue.

Voir les réseaux enregistrés
Joueur sur SwitchHorizon NIFM / BTM

L'onglet Networks montre les métadonnées de base des profils enregistrés et les canaux autorisés par Horizon, avec le calcul de chevauchement de core/metrics ; les identifiants ne sont jamais affichés.

Inspecter le Bluetooth
Joueur sur SwitchHorizon NIFM / BTM

BluetoothService lit l'état radio BTM et le nombre d'appareils, puis lance un balayage BLE passif limité qui renvoie au plus dix adresses uniques.

Exporter un rapport
Joueur sur Switch

L'onglet About écrit sdmc:/switch-wifi-diagnostics.txt avec la version, la cible de compatibilité, les détails réseau et les compteurs Bluetooth, sans identifiants.

2.1. Scénario : Comparer deux canaux de routeur sur Switch

  1. Compiler build-switch/switch-wifi.nro dans le conteneur devkitpro/devkita64 et le vérifier avec python3 scripts/verify_nro.py.
  2. Copier le NRO sur la carte SD et le lancer depuis le menu homebrew.
  3. Ouvrir l'onglet Dashboard pour confirmer que la Switch est en Wi-Fi et noter les barres de signal.
  4. Lancer l'onglet Benchmark et lire la latence médiane, le P95, la gigue et les débits descendant et montant.
  5. Changer le canal du routeur, relancer la mesure et comparer les graphiques d'historique.
  6. Exporter sdmc:/switch-wifi-diagnostics.txt depuis l'onglet About pour garder le résultat.

Fichiers consultésREADME.mddocs/ARCHITECTURE.mddocs/BENCHMARKING.mdinclude/switch_wifi/network/speed_test.hppsrc/ui/main_tabs.cppscripts/verify_nro.py

3. Démarrage

Ces commandes viennent de la documentation du dépôt. Elles n’ont pas été exécutées pendant cette revue.

README.md · Recommended: official devkitPro container
git clone --recursive https://github.com/antoinebou12/switch-wifi.git
cd switch-wifi
README.md · Recommended: official devkitPro container
python3 scripts/verify_nro.py build-switch/switch-wifi.nro
README.md · Native devkitPro installation
cmake -S . -B build-switch -DPLATFORM_SWITCH=ON -DUSE_GLFW=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build-switch --target switch-wifi.nro --parallel
README.md · Recommended: official devkitPro container
docker run --rm \
  -v "$PWD:/work" -w /work \
  devkitpro/devkita64:latest \
  bash -lc 'cmake -S . -B build-switch \
    -DPLATFORM_SWITCH=ON \
    -DUSE_GLFW=ON \
    -DCMAKE_BUILD_TYPE=Release && \
    cmake --build build-switch --target switch-wifi.nro --parallel'

4. Références du dépôt

Extraits des guides du dépôt, dans leur langue d’origine. Les liens ouvrent la version du code consultée.

Prérequis et premier essai

4.1. Native devkitPro installation

README.md

The same CMake commands work from a configured devkitA64/devkitPro environment:
Lire les instructions complètes ↗
Configuration et utilisation

4.2. Wi-Fi environment

README.md

  • Basic saved-network metadata without requesting full saved credential profiles.
  • Authentication/encryption labels.
  • Horizon allowed-channel query on HOS 6.0.0+.
  • 2.4 GHz and 5 GHz channel/frequency helpers.
  • Tested channel-overlap and contention-proxy math.
  • Nearby AP scan kept behind a hardware-verification boundary until opaque Horizon AP records can be decoded safely across firmware versions.
  • RF noise floor and SNR shown as unavailable rather than inferred from unrelated values.
Lire les instructions complètes ↗
Développement et contributions

4.3. Unit tests

README.md

The platform-independent metric, history, channel and benchmark-statistics code is tested on the host. The suite is split into:

  • switch_wifi_metrics_tests;
  • switch_wifi_history_tests;
  • switch_wifi_benchmark_tests. Sanitizer build:
Lire les instructions complètes ↗

4.4. Development rules

CONTRIBUTING.md

  • Keep Horizon/libnx IPC out of the Borealis UI layer.
  • Add a host-side test for calculations and parsers whenever possible.
  • Gate firmware-dependent behavior explicitly.
  • Do not add code that retrieves Wi-Fi passphrases just to display profile information.
  • Do not call a derived AP-overlap value “noise floor”, “SNR”, or “channel utilization” unless the underlying metric is actually measured.
  • Keep Bluetooth diagnostics read-only.
Lire les instructions complètes ↗
Documentation source

2 documents lus parmi 2 candidats.

5. Fonctions et composants 2

Cœur de calcul portable
CMake construit switch_wifi_core depuis src/core/metrics.cpp. Les tests hôtes utilisent cette bibliothèque indépendamment de Borealis. Ils couvrent les métriques, l’historique et les benchmarks, avec des sanitizers optionnels.
Intégration console
La cible applicative rassemble les modules src et lie Borealis, les bibliothèques libnx et libcurl. Le réseau et l’interface dépendent donc de la plateforme, tandis que le cœur numérique peut rester indépendant.

6. Architecture

Ouvrez un composant pour suivre ses connexions, ou explorez le diagramme complet.

Composants du système Contexte
Mermaid Diagramme interactif

Vue générale des composants et des échanges vérifiés dans le dépôt.

Vue statique de l’architecture de switch-wifi
Aperçu statique. Le diagramme interactif le remplace après le chargement de Mermaid.
flowchart LR
  n0["Échantillons réseau"]
  n1["Cœur de métriques portable"]
  n2["Historique et résultats"]
  n3["Tableau de bord Borealis"]
  n4["Tests unitaires hôtes"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n4 --> n1
Version texte du diagramme
  • Échantillons réseau → Cœur de métriques portable
  • Cœur de métriques portable → Historique et résultats
  • Historique et résultats → Tableau de bord Borealis
  • Tests unitaires hôtes → Cœur de métriques portable
Suivre un parcours dans le code

Partez de la bibliothèque et de ses tests, puis examinez le module réseau qui fournit les mesures. Un débit HTTPS dépend du serveur et du trajet réseau; ce n’est pas une lecture directe de la capacité radio Wi-Fi.

7. Dossier technique

Établi à partir du code au commit 8ff883f (30 fichiers). Chaque élément vient d’une correspondance de motif dans le code: ouvrez le fichier lié avant de vous y fier.

7.1. Couches et modules

Les dossiers sont classés par couche selon leur nom, de l’interface utilisateur jusqu’à l’accès aux données. Comme le classement repose sur les noms seulement, le diagramme ne dit rien des appels entre couches.

Mermaid Vue en couches
flowchart TB
  subgraph L_presentation["Présentation"]
    direction TB
    presentation_0["switch_wifi/ui<br/>3 fichiers"]
    presentation_1["ui<br/>3 fichiers"]
  end
  subgraph L_interface["Points d’entrée et API"]
    direction TB
    interface_0["src<br/>1 fichier"]
  end
  subgraph L_application["Services applicatifs"]
    direction TB
    application_0["scripts<br/>3 fichiers"]
    application_1["bluetooth<br/>1 fichier"]
    application_2["switch_wifi/bluetooth<br/>1 fichier"]
  end
  subgraph L_domain["Domaine et règles métier"]
    direction TB
    domain_0["core<br/>1 fichier"]
    domain_1["switch_wifi/core<br/>1 fichier"]
  end
  subgraph L_infrastructure["Données et infrastructure"]
    direction TB
    infrastructure_0["network<br/>1 fichier"]
    infrastructure_1["switch_wifi/network<br/>1 fichier"]
  end
  subgraph L_core["Source principale"]
    direction TB
    core_0["switch_wifi<br/>1 fichier"]
  end
  subgraph L_tests["Tests"]
    direction TB
    tests_0["tests<br/>3 fichiers"]
    tests_1["network<br/>1 fichier"]
    tests_2["switch_wifi<br/>1 fichier"]
  end
  subgraph L_hosting["Build, CI et hébergement"]
    direction TB
    hosting_0[".github<br/>8 fichiers"]
    hosting_1["(root)<br/>1 fichier"]
    hosting_2["library<br/>1 fichier"]
  end
  L_presentation ~~~ L_interface
  L_interface ~~~ L_application
  L_application ~~~ L_domain
  L_domain ~~~ L_infrastructure
  L_infrastructure ~~~ L_core
  L_core ~~~ L_tests
  L_core ~~~ L_hosting
Modules et couche principale
ModuleCoucheFichiersTypesExtensions
scriptsServices applicatifs30.py
switch_wifi/uiPrésentation33.hpp
uiPrésentation36.cpp
bluetoothServices applicatifs10.cpp
coreDomaine et règles métier10.cpp
networkDonnées et infrastructure11.cpp
srcPoints d’entrée et API10.cpp
switch_wifiSource principale10.hpp
switch_wifi/bluetoothServices applicatifs11.hpp
switch_wifi/coreDomaine et règles métier110.hpp
switch_wifi/networkDonnées et infrastructure11.hpp

7.2. Modèle C4

Du contexte du système aux déclarations du code. Chaque niveau conserve les limites des sources disponibles.

UML 1 · Contexte du système
1 · Contexte du système

La vue C4 la plus large : qui utilise le projet et sur quels systèmes et stockages externes il s’appuie. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
System(SYS, "switch-wifi", "switch-wifi est un tableau de bord réseau pour Switch avec une interf…")
@enduml
UML 2 · Conteneurs
2 · Conteneurs

Un niveau plus près : les parties qui s’exécutent séparément dans le projet, leur langage principal et le chemin des appels entre elles. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
System_Boundary(SYS, "switch-wifi") {
  Container(APP, "switch-wifi", "C++")
}
@enduml
UML 3 · Composants et couches
3 · Composants et couches

Modules regroupés par couche du code. Les limites indiquent l’organisation, sans affirmer une isolation à l’exécution ni des appels. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "switch-wifi") {
Boundary(L0, "Présentation", "layer") {
Component(M0_0, "switch_wifi/ui", "C++", "3 fichiers")
Component(M0_1, "ui", "C++", "3 fichiers")
}
Boundary(L1, "Points d’entrée et API", "layer") {
Component(M1_0, "src", "C++", "1 fichiers")
}
Boundary(L2, "Services applicatifs", "layer") {
Component(M2_0, "scripts", "Python", "3 fichiers")
Component(M2_1, "bluetooth", "C++", "1 fichiers")
Component(M2_2, "switch_wifi/bluetooth", "C++", "1 fichiers")
}
Boundary(L3, "Domaine et règles métier", "layer") {
Component(M3_0, "core", "C++", "1 fichiers")
Component(M3_1, "switch_wifi/core", "C++", "1 fichiers")
}
Boundary(L4, "Données et infrastructure", "layer") {
Component(M4_0, "network", "C++", "1 fichiers")
Component(M4_1, "switch_wifi/network", "C++", "1 fichiers")
}
Boundary(L5, "Source principale", "layer") {
Component(M5_0, "switch_wifi", "C++", "1 fichiers")
}
Boundary(L6, "Tests", "layer") {
Component(M6_0, "tests", "C++", "3 fichiers")
Component(M6_1, "network", "C++", "1 fichiers")
Component(M6_2, "switch_wifi", "C++", "1 fichiers")
}
Boundary(L7, "Build, CI et hébergement", "layer") {
Component(M7_0, ".github", ".yml, .txt, .md", "8 fichiers")
Component(M7_1, "(root)", ".txt", "1 fichiers")
Component(M7_2, "library", ".txt", "1 fichiers")
}
}
@enduml
UML 4 · Code
4 · Code

Déclarations, champs et méthodes sélectionnés, regroupés par fichier source. Aucun héritage ni appel n’est déduit. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
top to bottom direction
hide empty members
package "switch-wifi" {
package "include/switch_wifi/core/metrics.hpp" as F0 {
class "RingHistory" as T0_0 {
  push()
  clear()
  size()
  capacity()
  empty()
  values()
}
class "ConnectionSnapshot" as T0_1 {
  std
  ip
}
class "IpConfig" as T0_2 {
  std
  ip
}
class "BluetoothDevice" as T0_3 {
  std
}
class "BluetoothScanResult" as T0_4 {
  std
}
class "BluetoothSnapshot" as T0_5 {
  std
}
class "LatencyStats" as T0_6 {
  std
}
class "NearbyWifiNetwork" as T0_7 {
  std
}
class "SavedNetwork" as T0_8 {
  std
}
class "SpeedSample" as T0_9 {
  std
}
}
package "src/network/network_service.cpp" as F1 {
class "NifmBasicProfileWire" as T1_0 {
  uuid
  networkName
  profileType
  connectionType
  ssidLen
  ssid
  authentication
  encryption
}
}
}
@enduml

7.3. Interface publique

Du code extérieur peut utiliser tout ce qui est listé ici. Le projet déclare aussi 22 types publics.

Points d’entrée

En-têtes publics 8

include/switch_wifi/bluetooth/bluetooth_service.hpp include/switch_wifi/core/metrics.hpp include/switch_wifi/network/network_service.hpp include/switch_wifi/network/speed_test.hpp include/switch_wifi/ui/main_tabs.hpp include/switch_wifi/ui/signal_shader.hpp include/switch_wifi/ui/sparkline.hpp include/switch_wifi/version.hpp

7.4. Interface privée

Ces noms sont internes selon les conventions du langage: tiret bas initial, private, static ou pub(crate).

Espace de noms anonyme
3

7.5. Services

7.6. Entités et modèle de données 10

Mermaid Diagramme de classes des entités
classDiagram
  direction LR
  class E0["NifmBasicProfileWire"] {
    +Uuid uuid
    +char networkName
    +u8 profileType
    +u8 connectionType
    +u8 ssidLen
    +char ssid
  }
  class E1["ConnectionSnapshot"] {
    +:string std
    +IpConfig ip
  }
  class E2["IpConfig"] {
    +:string std
    +IpConfig ip
  }
  class E3["BluetoothDevice"] {
    +:string std
  }
  class E4["BluetoothScanResult"] {
    +:string std
  }
  class E5["BluetoothSnapshot"] {
    +:string std
  }
  class E6["LatencyStats"] {
    +:vector std
  }
  class E7["NearbyWifiNetwork"] {
    +:string std
  }
  class E8["SavedNetwork"] {
    +:size_t std
  }
  class E9["SpeedSample"] {
    +:string std
  }
  E1 --> E2 : ip
  E6 --> E3 : std

Une flèche relie un champ à l’entité que son type nomme.

EntitéNaturePremiers champs
NifmBasicProfileWireStructure de donnéesuuid, networkName, profileType, connectionType, ssidLen, ssid, authentication, encryption
ConnectionSnapshotStructure de donnéesstd, ip
IpConfigStructure de donnéesstd, ip
BluetoothDeviceStructure de donnéesstd
BluetoothScanResultStructure de donnéesstd
BluetoothSnapshotStructure de donnéesstd
LatencyStatsStructure de donnéesstd
NearbyWifiNetworkStructure de donnéesstd
Afficher 2 entités de plus
SavedNetworkStructure de donnéesstd
SpeedSampleStructure de donnéesstd

7.7. Logique métier

Une fois écartés le code d’interface et les services et entités ci-dessus, ces classes ont le plus de méthodes.

RingHistory Domaine et règles métier, 6 méthodes
push, clear, size, capacity, empty, values

7.8. Intégrations externes

Clients HTTP

libcurl

7.9. Stack et dépendances

C/C++ (CMake) CMakeLists.txt 2 à l’exécution

C++17 CMake ≥ 3.16

Ouvrir le manifeste

Dépendances externes

2 paquets déclarés (2 à l’exécution, 0 pour le développement) dans CMakeLists.txt.

Tableau des paquets 2
Dépendances externes
PaquetVersionUsageRôleRegistre
Threads—exécution—C/C++ (CMake)
PkgConfig—exécution—C/C++ (CMake)

7.10. Pipeline CI/CD

3 workflows GitHub Actions, 8 tâches. Chaque boîte est une tâche ; les boîtes à double bord publient ou déploient, et les flèches suivent les dépendances needs.

Mermaid Déroulement du pipeline
flowchart LR
  subgraph wf0["CI"]
    direction LR
    wf0_host_tests["Host tests<br/>ubuntu-latest"]
    wf0_sanitizers["ASan + UBSan<br/>ubuntu-latest"]
    wf0_switch_nro["NRO<br/>ubuntu-latest"]
    wf0_switch_nro_libnx_master[["NRO (current libnx master)<br/>ubuntu-latest"]]
  end
  subgraph wf1["Publish dist NRO"]
    direction LR
    wf1_build_and_publish["Build and publish dist/switch-wifi.nro<br/>ubuntu-latest"]
  end
  subgraph wf2["Release"]
    direction LR
    wf2_validate[["Validate release<br/>ubuntu-latest"]]
    wf2_build_nro[["Build release NRO<br/>ubuntu-latest"]]
    wf2_publish[["Publish GitHub Release<br/>ubuntu-latest"]]
  end
  t0(["push · demande de fusion · lancement manuel"])
  t1(["push · lancement manuel"])
  d0[("Versions GitHub")]
  t0 --> wf0_host_tests
  t0 --> wf0_sanitizers
  t0 --> wf0_switch_nro
  t0 --> wf0_switch_nro_libnx_master
  t1 --> wf1_build_and_publish
  t1 --> wf2_validate
  wf2_validate --> wf2_build_nro
  wf2_validate --> wf2_publish
  wf2_build_nro --> wf2_publish
  wf2_publish -.-> d0
Workflows, déclencheurs, tâches et cibles
WorkflowDéclencheursTâchesPublie vers
CI
.github/workflows/ci.yml
push, demande de fusion, lancement manuel
  • Host tests ubuntu-latest
    actions/checkout · Configure · Build · Unit tests
  • ASan + UBSan ubuntu-latest
    actions/checkout · Configure sanitizers · Build · Unit tests
  • NRO ubuntu-latest
    stable-image · latest-image · Checkout with Borealis · Toolchain inventory · Configure Switch build · Build NRO
  • NRO (current libnx master) ubuntu-latest
    Checkout with Borealis · Build current libnx master · Configure Switch build · Build and verify NRO · Upload current-libnx NRO
—
Publish dist NRO
.github/workflows/publish-dist.yml
push, lancement manuel
  • Build and publish dist/switch-wifi.nro ubuntu-latest
    Checkout with Borealis · Configure Switch build · Build NRO · Verify NRO · Stage dist artifact · Commit dist artifact to main
—
Release
.github/workflows/release.yml
push, lancement manuel
  • Validate release ubuntu-latest
    Resolve ref · Checkout release ref · Resolve and validate version · Configure host tests · Build and test
  • Build release NRO ← validate ubuntu-latest
    Checkout release tag · Toolchain inventory · Configure Switch build · Build and verify NRO · Package release · Upload release bundle
  • Publish GitHub Release ← validate, build-nro ubuntu-latest
    Download release bundle · Publish release
Versions GitHub

7.11. Déploiement

Mermaid Schéma de déploiement
flowchart LR
  repo[("Dépôt GitHub")]
  ci[["GitHub Actions<br/>3 workflows"]]
  pub_GitHub_Releases[("Versions GitHub")]
  repo -->|"push ou demande de fusion"| ci
  ci -->|"publie"| pub_GitHub_Releases

Où il s’exécute

Publié vers

7.12. Sécurité

Chaîne d’approvisionnement

7.13. Tests automatisés

Fichiers de test
5
Fichiers source
17
Tests unitaires
4
Tests performance
1

Aucun rapport chiffré de couverture dans les sources analysées.

Où sont les tests

tests 3 include/switch_wifi/network 1 src/network 1

Intégration continue

CI
ctest
Release
ctest
UML Pipeline CI
Pipeline CI

Le workflow GitHub Actions principal suit ces étapes. Les tâches lancées en parallèle sont côte à côte. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
title CI
start
fork
  partition "Host tests" {
    :actions/checkout;
    :Configure;
    :Build;
    :Unit tests;
  }
fork again
  partition "ASan + UBSan" {
    :actions/checkout;
    :Configure sanitizers;
    :Build;
    :Unit tests;
  }
fork again
  partition "NRO" {
    :stable-image;
    :latest-image;
    :Checkout with Borealis;
    :Toolchain inventory;
    :Configure Switch build;
    :Build NRO;
    :Verify NRO structure;
    :Build checksum;
  }
fork again
  partition "NRO (current libnx master)" {
    :Checkout with Borealis;
    :Build current libnx master;
    :Configure Switch build;
    :Build and verify NRO;
    :Upload current-libnx NRO;
  }
end fork
stop
@enduml

Rien trouvé pour: Base de données, Supervision.

8. Déploiement et exploitation

Les ports, le stockage et les relations de démarrage ci-dessous viennent de la configuration du dépôt. depends_on indique l’ordre de démarrage, pas la disponibilité du service.

9. Types et structure des fichiers

27 types déclarés, dont 12 dans l’aperçu des relations de base.

Diagramme des types
classDiagram
direction TB
class tec54ffc64505["BluetoothService"] {
  snapshot()
  passiveScan()
}
class t17625c2744a3["IpConfig"] {
  <<struct>>
}
class t7988c53361f7["ConnectionSnapshot"] {
  <<struct>>
}
class t4a309fd00cd7["SavedNetwork"] {
  <<struct>>
}
class tc583422c7f0f["NearbyWifiNetwork"] {
  <<struct>>
}
class tff9ef4d0d29e["LatencyStats"] {
  <<struct>>
}
class t2488d1629c51["SpeedSample"] {
  <<struct>>
}
class t60189b23c9ad["BluetoothDevice"] {
  <<struct>>
}
class t28065228e336["BluetoothSnapshot"] {
  <<struct>>
}
class t6f2d7c0133a5["BluetoothScanResult"] {
  <<struct>>
}
class tcd996a2f6785["RingHistory"] {
  RingHistory()
  push()
  clear()
  size()
}
class tba04fe8b8282["NetworkService"] {
  initialize()
  shutdown()
  snapshot()
  savedNetworks()
}

Les bases non résolues restent identifiées; les signatures complètes ne sont pas reconstruites.

10. Référence

25 / 25 fichiers admissibles lus (51 dans l’arbre); 0 trop volumineux, 0 échec de lecture et 3 diagnostic de syntaxe.

Ce que couvre l’analyse

Les dossiers connus de dépendances et de compilation, les fichiers d’identifiants et les binaires sont exclus. La collecte couvre les README, les manifestes reconnus et les fichiers source pris en charge.

Les statistiques Linguist couvrent l’ensemble du dépôt et peuvent inclure d’autres langages.

12. Fichiers à lire 3

13. Glossaire

Dépôt

Les fichiers source, la configuration et l’historique versionné d’un projet.

README

Le document d’entrée du dépôt, qui présente généralement son rôle et son installation.

Dépendance

Une bibliothèque, un outil ou un service nécessaire à la compilation ou à l’exécution d’un composant.

HTTP

Un protocole de requête et réponse utilisé par les navigateurs et services web. Une requête comprend une méthode, un chemin, des en-têtes et parfois un corps.

Port publié

Un port de l’hôte associé au port d’un service dans un conteneur. Sa publication peut rendre le service accessible hors du réseau des conteneurs.

Compilation

Les étapes qui transforment les sources et dépendances en programme exécutable ou en livrable distribuable.

14. Références

  1. antoinebou12. (2026, 5 novembre). switch-wifi. [Software repository] github.com.
  2. antoinebou12. (2026, 5 novembre). switch-wifi: README. [Repository documentation] github.com.
  3. antoinebou12. (2026, 5 novembre). CMakeLists.txt. [Source file] github.com.
  4. antoinebou12. (2026, 5 novembre). src/core/metrics.cpp. [Source file] github.com.
  5. antoinebou12. (2026, 5 novembre). src/main.cpp. [Source file] github.com.
  6. Boucher, A. (2026, 23 octobre). switch-wifi : Séparer les mesures réseau de l’interface. [Project article] antoineboucher.info.

Les sources sans date de publication indiquent la date de leur dernière vérification, le 5 novembre 2026. Les liens des fichiers conservent la révision inspectée lorsqu’elle est disponible.