Hello,
le kernel possèdent il des tests d'intégration automatisés ?
La question me semble un peu stupide, mais le père linus ne peut s’arrêter de radoter à ces followers de tester à chaque rc.
Du coup je me demande…………………………….. FONT ILS CA A LA MAIN ?????
Et puis je me demande à quoi ressemble l'état de l'art du testing sur le kernel, comment toutes ces questions de fixtures, mock ect ont pu être résolues dans cet environnement si proche des composants physique ?
# Non, mais...
Posté par Renault (site web personnel) . Évalué à 6.
Tester un noyau ne se fait pas de la même manière qu'un logiciel "classique".
Déjà parce que cela dépend du matériel en dessous et le noyau ayant le plus gros du code en commun pour des machines fortes différentes et non disponibles partout, des bogues peuvent s'introduire par mégarde sans le détecter avant.
En plus le noyau interagit avec les logiciels au dessus de lui et les gèrent. Gérer un noyau est un peu empirique au niveau des paramètres pour concilier performance et fluidité des tâches et il y a des situations où ça peut merder. Car ces situations sont souvent imprévisibles.
Sans oublier qu'il y a chaque jour des ajouts de fonctionnalités ou de pilotes souvent testés par le mainteneur et le développeur seul dans sa configuration. Il ne peut prévoir toutes les configurations possibles en terme de modules noyau activés, matériels et logiciels utilisés et le contexte de tout ceci…
Je ne sais pas si tu as vu mais de nombreux problèmes ne se rencontrent que dans des cas tordus que tu ne peux pas faire chez toi à moins de disposer d'un matériel de plusieurs dizaines de milliers de dollars ou encore pour un usage très spécifique (donc pas un ordinateur familial).
[^] # Re: Non, mais...
Posté par maboiteaspam . Évalué à -1.
Je ne remets pas du tout la qualité du noyau en cause. Je m'interrogeait sévèrement, vos réponses m'ayant depuis éclairé.
Au regard de ton argumentaire, j'ai envie de dire que c'est d'autant plus crucial de pouvoir faire tourner des tests d'intégration pour rejouer, voir inventer (fuzzer), des jeux de données sur lesquels s'appuyer.
Et que oui, étant donné le nombre de variable possible, se serait tellement bien de pouvoir /simuler/ finement tout cela histoire de ne pas avoir à déployer le système qui va bien (et dont on peut douter de sa capacité à jamais pouvoir reproduire fidèlement la réalité du paysage hétérogène PC passé présent et à venir O_o ).
Maintenant, en regardant ce test http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/io/direct_io/diotest1.c?view=markup
je vois que la notion de mock n'existe pas.
A regarder cet autre test
http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/io/direct_io/diotest1.c?view=markup
J'en comprends que ce sont peut être des tests de non-régression auquel j'ai à faire.
Bref, maintenant je me pose la question suivante.
La QA à t'elle un jour jamais fait partie du scope fondateur des décisions conceptuel du noyau ?
Pas que je connaisse linus, mais au départ c'était bien une bidouille nés
du génie?de la passion et de l’opiniâtreté d'un bidouilleur.A t'il jamais pensé sa conception au regard des besoin de la QA, ou bien est ce que c'est le besoin et la réponse qui prime en tout temps.
[^] # Re: Non, mais...
Posté par netsurfeur . Évalué à 2.
Celle là, je la note (sans les fautes de français) pour un prochain business loto ;)
# Complément
Posté par lolop (site web personnel) . Évalué à 6.
http://stackoverflow.com/questions/3177338/how-is-linux-kernel-tested
En tests automatiques:
Mais comme indiqué par Renault, la diversité du matériel à tester ne permettra jamais d'être exhaustif, et l'appel aux followers permet de réaliser des tests dans des configs / cas particuliers. Un OS reste un logiciel extrêmement compliqué, dépendant de l'électronique, de timings d'interruptions, devant éventuellement contourner des pb hardware, etc.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# virt
Posté par Krunch (site web personnel) . Évalué à 7.
Il existe plusieurs organisations qui effectuent des tests automatisés sur le noyau Linux. Le plus simple est d'utiliser des machines virtuelles. Évidemment cela ne permet pas de tout tester mais même pour les drivers de matériel, il suffit que l'hyperviseur sous-jacent supporte le {USB,PCI,VGA,…} passthrough pour que ça marche.
Après, automatiser les tests sur du baremetal, ça se fait aussi (je me suis occupé un moment d'une ferme d'une vingtaine de machines qui ne faisaient que ça, même si ce qu'on testait était plutôt un système complet incluant le noyau) mais je doute qu'il y ait une seule organisation qui s'occupe de tester tous les drivers.
Après, tu peux faire tous les tests automatisés que tu veux, ça vaut quand même la peine de faire des tests manuels en plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.