Sparse est effectivement un analyseur statique de code (backend). Mais kmemcheck et kmemleak sont dynamiques (font des vérifications pendant que le noyau tourne).
Le noyau est en fait truffé d'analyseur dynamiques.
Liste non-exhaustive:
Outils "j'me tourne les pouces et j'attends qu'on me detecte un problème":
- Lockdep: vérifie les dépendances des verroux, prévient des possibilités de deadlocks.
- Hung Task: Vérifie périodiquement les tâches qui sont bloquées en mode non-interruptible pendant trop longtemps
- Soft-lockup: Vérifie que la tache courrante a été changée durant les dix dernières secondes
- Nmi watchdog: Vérifie les hard lockups (coincé dans une interruption, ou code avec interruptions désactivées, ou deadlock de spinlock)
- Kmemcheck: Detecte usage de memoire non initializée (lecture avant toute écriture)
- Kmemleack: Detecte fuites de mémoires
- Poisons: D'une manière générale, les poisons sont des codes répétitifs qu'on insère dans un zone de mémoire libérée, comme par exemple une répétition de 0x66666
Lorsqu'on alloue une page mémoire et qu'elle a été modifiée (une partie des 666 a été modifiée), on le signale. Comme ça detecte les usages de pages libérées
- Fault injection: Provoque beaucoup d'échecs d'allocations mémoire pour voir comment le kernel s'en sort avec peu de mémoire.
Outils "ah zut faut encore que j'analyse les résultats":
- Ftrace
- Perf events
- Plein de trucs
Certains mainteneurs testent les patchs qu'on leur soumet, parfois 24h/24h comme Ingo Molnar qui teste des démarrages de configs de noyaux aléatoires automatiquement sur les arbres de developpement qu'il maintient.
Ceci étant, avant qu'un patch soit commité dans l'arbre d'un mainteneur, avant même qu'il ne soit testé, il est d'abord passé en revue, par un quidam lambda qui passe par là (et qui peut délivrer un tag Reviewed-by:), et/ou par un mainteneur.
C'est d'ailleurs souvent la chasse aux tags "Acked-by". Un diminutif pour acknowleged (inteprété ici comme "jugé acceptable par:"). Il s'agit d'un tag que donnent les mainteneurs d'un sous-système ou par simplement quelqu'un qui connait bien le code en question.
Lorsqu'il y a un patch un peu sensible à soumettre, parce qu'il modifie des fonctionnalités clés, les Acked-by sont souvent le passeport pour que ce patch puisse passer.
Et si personne ne se donne la peine de relire, commenter, "commiter" le patch en question, c'est Andrew Morton qui s'y colle :p
Donc voilà, en règle générale, il faut envoyer son patch avec:
- LKML et/ou la liste de diffusion du sous-système visé
- Les mainteneurs, ou n'importe quelle personne qui connait un peu le code en question (on peut regarder dans l'historique des fichiers modifiés avec git-log). Sinon il suffit simplement de lancer le script suivant: "scripts/get_maintainer.pl patch_a_soumettre"
Et ce sans compter les petites règles de base (Documentation/SendingPatches) et les règles moins de base (Documentation/DevelopmentProcess/) qui font qu'un patch est plus acceptable qu'un autre.
[^] # Re: Tests automatiques ?
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 10.
Le noyau est en fait truffé d'analyseur dynamiques.
Liste non-exhaustive:
Outils "j'me tourne les pouces et j'attends qu'on me detecte un problème":
- Lockdep: vérifie les dépendances des verroux, prévient des possibilités de deadlocks.
- Hung Task: Vérifie périodiquement les tâches qui sont bloquées en mode non-interruptible pendant trop longtemps
- Soft-lockup: Vérifie que la tache courrante a été changée durant les dix dernières secondes
- Nmi watchdog: Vérifie les hard lockups (coincé dans une interruption, ou code avec interruptions désactivées, ou deadlock de spinlock)
- Kmemcheck: Detecte usage de memoire non initializée (lecture avant toute écriture)
- Kmemleack: Detecte fuites de mémoires
- Poisons: D'une manière générale, les poisons sont des codes répétitifs qu'on insère dans un zone de mémoire libérée, comme par exemple une répétition de 0x66666
Lorsqu'on alloue une page mémoire et qu'elle a été modifiée (une partie des 666 a été modifiée), on le signale. Comme ça detecte les usages de pages libérées
- Fault injection: Provoque beaucoup d'échecs d'allocations mémoire pour voir comment le kernel s'en sort avec peu de mémoire.
Outils "ah zut faut encore que j'analyse les résultats":
- Ftrace
- Perf events
- Plein de trucs
Certains mainteneurs testent les patchs qu'on leur soumet, parfois 24h/24h comme Ingo Molnar qui teste des démarrages de configs de noyaux aléatoires automatiquement sur les arbres de developpement qu'il maintient.
Ceci étant, avant qu'un patch soit commité dans l'arbre d'un mainteneur, avant même qu'il ne soit testé, il est d'abord passé en revue, par un quidam lambda qui passe par là (et qui peut délivrer un tag Reviewed-by:), et/ou par un mainteneur.
C'est d'ailleurs souvent la chasse aux tags "Acked-by". Un diminutif pour acknowleged (inteprété ici comme "jugé acceptable par:"). Il s'agit d'un tag que donnent les mainteneurs d'un sous-système ou par simplement quelqu'un qui connait bien le code en question.
Lorsqu'il y a un patch un peu sensible à soumettre, parce qu'il modifie des fonctionnalités clés, les Acked-by sont souvent le passeport pour que ce patch puisse passer.
Et si personne ne se donne la peine de relire, commenter, "commiter" le patch en question, c'est Andrew Morton qui s'y colle :p
Donc voilà, en règle générale, il faut envoyer son patch avec:
- LKML et/ou la liste de diffusion du sous-système visé
- Les mainteneurs, ou n'importe quelle personne qui connait un peu le code en question (on peut regarder dans l'historique des fichiers modifiés avec git-log). Sinon il suffit simplement de lancer le script suivant: "scripts/get_maintainer.pl patch_a_soumettre"
Et ce sans compter les petites règles de base (Documentation/SendingPatches) et les règles moins de base (Documentation/DevelopmentProcess/) qui font qu'un patch est plus acceptable qu'un autre.