Pour les tests de pilotes sous Linux embarqué, au-delà des solutions comme v4l2-loopback pour les caméras virtuelles, une variété d'appareils virtuels et de méthodologies de test existent pour découpler le développement du matériel physique. Ces approches peuvent être globalement catégorisées en quatre domaines principaux : pilotes de périphériques virtuels, simulateurs/virtualisation, frameworks de test du noyau et outils en espace utilisateur.

I. Pilotes de Périphériques Virtuels (Modules du Noyau)

Ces éléments sont implémentés directement dans le noyau pour fournir des interfaces matérielles simulées, facilitant ainsi les tests de pilotes :

Exemple : Tester un pilote d'entrée avec uinput

# Charger le module uinput
sudo modprobe uinput

# Créer un périphérique d'entrée virtuel (via un script ou un programme)
# Supposons que vous ayez un exécutable create_virtual_mouse
sudo ./create_virtual_mouse

# Tester les événements d'entrée
# Remplacez eventX par le numéro de périphérique approprié
evtest /dev/input/eventX

II. Simulateurs et Outils de Virtualisation

1. QEMU - Le Simulateur de Système Complet le Plus Courant

# Simuler une carte de développement ARM exécutant Linux
qemu-system-arm -machine virt -cpu cortex-a53 \
    -kernel zImage -dtb virt.dtb \
    -append "console=ttyAMA0" \
    -drive file=rootfs.ext4,format=raw \
    -netdev user,id=net0 -device virtio-net-device,netdev=net0

• Avantages : Simule entièrement le CPU, la mémoire et les périphériques, permettant le débogage du noyau et des pilotes.
• Périphériques simulés pris en charge : Périphériques VirtIO (réseau, bloc, GPU, etc.), UART PL011, ARM GIC, etc.

2. Renode - Un Simulateur Spécifique pour les Systèmes IoT et Embarqués

• Prend en charge la simulation de réseaux multi-nœuds.
• Peut simuler des MCU des séries Cortex-M/R/A.
• Offre une bibliothèque complète de modèles de périphériques.

3. Fast Models (ARM) et Simics (Intel)

• Simulateurs commerciaux à précision cyclique.
• Utilisés pour le développement et la validation précoces des pilotes.

III. Frameworks de Test du Noyau

1. KUnit - Framework de Tests Unitaires du Noyau

// Exemple : Tester un pilote GPIO
#include <kunit/test.h>

static void gpio_driver_test_basic(struct kunit *test)
{
    // Supposons que create_virtual_gpio() retourne un pointeur vers une structure gpio_chip simulée
    struct gpio_chip *chip = create_virtual_gpio();
    KUNIT_ASSERT_NOT_ERR_OR_NULL(test, chip);
    // Vérifie si le nombre de GPIO dans le chipset simulé est correct
    KUNIT_EXPECT_EQ(test, chip->ngpio, 16);
}

static struct kunit_case gpio_test_cases[] = {
    KUNIT_CASE(gpio_driver_test_basic),
    // Marqueur de fin de tableau
    {}
};

static struct kunit_suite gpio_test_suite = {
    .name = "gpio-driver-test",
    .test_cases = gpio_test_cases,
};
// Macro pour enregistrer la suite de tests KUnit
kunit_test_suite(gpio_test_suite);

2. kselftest - Suite d'Auto-Tests du Noyau

# Exécuter les auto-tests du noyau
cd linux/tools/testing/selftests
make -C gpio run_tests
make -C net run_tests

3. LTP (Linux Test Project)

# Exécuter des tests de système de fichiers
./runltp -f fs
# Exécuter des tests d'ordonnanceur I/O
./runltp -f io

IV. Outils de Test en Espace Utilisateur et Bibliothèques de Simulation

1. Libfaketime - Simulation de l'Écoulement du Temps

# Tester la gestion des timeouts dans un pilote
LD_PRELOAD=./libfaketime.so FAKETIME="@2024-01-01 00:00:00" ./driver_test_executable

2. Bibliothèques d'Interception LD_PRELOAD

// Interception personnalisée de malloc/free pour tester la gestion de la mémoire
void *malloc(size_t size) {
    if (should_inject_failure()) {
        // Simuler une allocation mémoire échouée
        return NULL;
    }
    // Appel à l'implémentation réelle de malloc
    return real_malloc(size);
}

3. FUSE (Filesystem in Userspace)

• Permet de simuler divers comportements de systèmes de fichiers.
• Utile pour tester l'interface VFS et les opérations sur les fichiers.

4. Netem - Simulation Réseau

# Simuler latence réseau et perte de paquets pour tester un pilote réseau
tc qdisc add dev eth0 root netem delay 100ms loss 5%

V. Solutions de Test Spécifiques à l'Embarqué

1. Test Hardware-in-the-Loop (HIL)

Le microcontrôleur réel fonctionne avec des périphériques virtuels simulés via FPGA ou interfaces virtuelles. Le pilote s'exécute sur le matériel réel tandis que les périphériques sont émulés par le système de test.

2. QEMU avec Couverture d'Arbre de Périphériques (Device Tree)

// Utilisation d'un Device Tree dédié pour les tests, ajoutant des nœuds pour les périphériques virtuels
virtual_device {
    compatible = "test,virtual-device";
    reg = <0x10000000 0x1000>; // Adresse et taille mémoire simulées
    interrupts = <0 100 4>;     // Interruptions simulées
    test-mode = "inject-errors"; // Paramètre pour le mode de test spécifique
};

3. KernelCI - Plateforme de Test Automatisé du Noyau

• Intégration continue ciblant les plateformes embarquées.
• Automatise la construction, le déploiement et le test des noyaux et des pilotes.

VI. Recommandations Stratégiques de Test

Pyramide des Tests à Plusieurs Niveaux (pour les Pilotes Embarqués)

graph TD
    A[Tests Système<br></br>(Hardware-in-the-Loop, QEMU Full System)] --> B(Tests d'Intégration<br></br>(Pilotes Virtuels + Noyau Réel));
    B --> C(Tests Unitaires<br></br>(KUnit + Hardware Simulé));
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#ccf,stroke:#333,stroke-width:2px
    style C fill:#cfc,stroke:#333,stroke-width:2px

Processus de Mise en Œuvre Détaillé

1. Niveau des Tests Unitaires : Utiliser KUnit avec des interfaces matérielles virtuelles (ex. gpio-mockup).
2. Niveau des Tests d'Intégration : Charger le pilote réel avec des périphériques virtuels (ex. tun/tap pour tester un pilote réseau).
3. Niveau des Tests Système : Simulation complète du système avec QEMU et des scripts de test automatisés.
4. Niveau des Tests Matériels : Utiliser le matériel réel avec des charges programmables ou des injections de fautes.

VII. Cas Pratique : Test d'un Pilote I2C

# 1. Créer un périphérique I2C virtuel avec i2c-stub
echo "dummy 0x50" > /sys/bus/i2c/devices/i2c-0/new_device

# 2. Écrire un script pour simuler les réponses du périphérique esclave
#!/bin/bash
# Simuler un capteur de température
while true; do
    # Lire une "valeur de température" simulée
    echo $((20 + RANDOM % 10)) > /sys/bus/i2c/devices/0-0050/temp
    sleep 1
done

# 3. Charger le pilote I2C réel pour le test
insmod real_i2c_driver.ko

# 4. Exécuter un programme de test en espace utilisateur
./read_temperature # Devrait lire des "températures" entre 20 et 30°C

Conclusion

Les tests de pilotes sous Linux embarqué ont évolué vers un ensemble complet de méthodologies :

• Les pilotes de périphériques virtuels simulent les interfaces matérielles.
• Les simulateurs comme QEMU fournissent des environnements système complets.
• Les frameworks de test du noyau garantissent la qualité du code.
• Les outils en espace utilisateur permettent l'injection de fautes et les tests aux limites.

Conseil clé : Pour le développement de nouveaux pilotes, adoptez une stratégie de test progressive : KUnit (Tests Unitaires) → Périphériques Virtuels (Tests d'Intégration) → QEMU (Tests Système) → Matériel Réel (Tests d'Acceptation). Cette approche maximise l'efficacité du développement tout en assurant une couverture de test étendue.