Les pilotes de cartes réseau sont en général assez simple et peu buggués...
Qu'est-ce qui te fais dire cela ? J'aurais tendance à penser qu'ils deviennent de plus en plus complexes à l'instar des cartes: tcp/ip offloading, queue multiples, wifi-n, ...
[...] le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau.
J'imagine que l'intérêt de la démonstration était justement que wget n'en sache rien, c.-à-d. que sa connexion tcp/ip n'a pas été coupée*. En ce qui concerne la gestion des coupures réseaux, c'est clairement une fonction de la pile tcp/ip qui, pour le noyau linux, ne se trouve pas dans l'"userspace" ! Tu peux débrancer-rebrancher ton cable réseau sans que tes connections tcp/ip ne se coupent mais cela ne marchera pas au point de faire un rmmod-insmod.
Le test que tu propose avec le pilote hdd suit aussi la même logique et ne devrait donc pas poser de problèmes majeurs. Le micro-serveur qui s'occuppe du FS n'a qu'a attendre que le pilote se recharge** avant de soumettre la suite de ses ordres. L'idée est justement de séparer les sous-système dépendants en serveur différents et, je suppose que, minix3 gère cette résillience de manière +/- générique pour n'importe quel pilote.
Même si dans l'hypothèse fort improbable que Linus décide d'implementer la possibilité de recharger un pilote sans déstabiliser les couches logicielles qui en dépendent, tu n'obtiendra jamais le niveau de résillience d'un micro-noyau parce qu'il n'y a pas de séparation d'espace mémoire entre les différents pilotes/sous-systèmes et que donc un bug dans un driver peut modifier le comportement d'une autre partie du noyau (dans le pire cas), voir le crasher (dans le meilleur, car je n'aimerais pas avoir mon fs détruit à cause d'un mauvais pilote résaux ou une carte réseaux détruite à cause d'un Xorg foireux ;-)).
*:Effectivement, wget s'en sort plustôt bien quand la connection est _coupée_ en essayant de reprendre le téléchargement. Il y a dans ce cas une nouvelle connection tcp/ip effectuée et la restauration de l'état précédant la coupure est effectué par _l' application_. C'est de très loin un comportement minoritaire parmis toutes les applications réseaux existantes et qui n'est permis que parce que le protocol http/ftp permet cet usage. Rien à voir avec l'exemple qui nous occupe où la connection n'est tout simplement pas coupée...
**:En admettant qu'il ne faille pas dépendre de ce pilote pour recharger le serveur/pilote. Je ne sais pas comment minix3 gère ce cas mais en théorie cela est tout à fait possible, il suffirait d'avoir un serveur "chargeur" qui garderait en mémoire les pilotes à recharger.
[^] # Re: Petite question: noyau monolithique?
Posté par benja . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 4.
Qu'est-ce qui te fais dire cela ? J'aurais tendance à penser qu'ils deviennent de plus en plus complexes à l'instar des cartes: tcp/ip offloading, queue multiples, wifi-n, ...
[...] le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau.
J'imagine que l'intérêt de la démonstration était justement que wget n'en sache rien, c.-à-d. que sa connexion tcp/ip n'a pas été coupée*. En ce qui concerne la gestion des coupures réseaux, c'est clairement une fonction de la pile tcp/ip qui, pour le noyau linux, ne se trouve pas dans l'"userspace" ! Tu peux débrancer-rebrancher ton cable réseau sans que tes connections tcp/ip ne se coupent mais cela ne marchera pas au point de faire un rmmod-insmod.
Le test que tu propose avec le pilote hdd suit aussi la même logique et ne devrait donc pas poser de problèmes majeurs. Le micro-serveur qui s'occuppe du FS n'a qu'a attendre que le pilote se recharge** avant de soumettre la suite de ses ordres. L'idée est justement de séparer les sous-système dépendants en serveur différents et, je suppose que, minix3 gère cette résillience de manière +/- générique pour n'importe quel pilote.
Même si dans l'hypothèse fort improbable que Linus décide d'implementer la possibilité de recharger un pilote sans déstabiliser les couches logicielles qui en dépendent, tu n'obtiendra jamais le niveau de résillience d'un micro-noyau parce qu'il n'y a pas de séparation d'espace mémoire entre les différents pilotes/sous-systèmes et que donc un bug dans un driver peut modifier le comportement d'une autre partie du noyau (dans le pire cas), voir le crasher (dans le meilleur, car je n'aimerais pas avoir mon fs détruit à cause d'un mauvais pilote résaux ou une carte réseaux détruite à cause d'un Xorg foireux ;-)).
*:Effectivement, wget s'en sort plustôt bien quand la connection est _coupée_ en essayant de reprendre le téléchargement. Il y a dans ce cas une nouvelle connection tcp/ip effectuée et la restauration de l'état précédant la coupure est effectué par _l' application_. C'est de très loin un comportement minoritaire parmis toutes les applications réseaux existantes et qui n'est permis que parce que le protocol http/ftp permet cet usage. Rien à voir avec l'exemple qui nous occupe où la connection n'est tout simplement pas coupée...
**:En admettant qu'il ne faille pas dépendre de ce pilote pour recharger le serveur/pilote. Je ne sais pas comment minix3 gère ce cas mais en théorie cela est tout à fait possible, il suffirait d'avoir un serveur "chargeur" qui garderait en mémoire les pilotes à recharger.