Tu sais que ton driver de FS, le truc qui ecrit directement sur ton disque sans barriere de securite, a plante.
Ben non, le "driver de FS" n'écrit pas sur le disque dur, mais bien le driver (micro-serveur) "disque dur". Avec une architecture traditionnelle, quand ton pilote controleur disque dur plante, il entraîne ton pilote FS avec. Avec une architecture telle que minix3 ce n'est pas forcément vrai. Comme on dit, 90% des écrans de la morts sont dûs à de mauvais pilotes; j'ai la faiblesse de penser que les autres couches sont plus robustes.
Tu as vraiment envie de le redemarrer et effectuer a nouveau l'operation X qui a de bonnes chances de l'avoir fait planter elle-meme au risque qu'il detruise ta partition ?
Quand ton pilote FS s'est craché, redemarrage (de la machine) ou pas, je ne ferais pas trop confiance quant à la cohérence de ce qui reste sur ton disque dur...
Le FS c'est hyper-sensible, que le code qui le gere soit en user-mode ou kernel-mode n'y change pas grand chose, et un probleme la dedans est le plus souvent fatal.
Toutafé, mais nous discuttions de problèmes dûs aux pilotes et tu nous parles de problème de sous-systèmes indépendants du matériel. Au risque de me répéter, ton bug qui apparaît quelque part dans ton noyau peut impacter une toute autre partie de celui-ci (le temps qu'"il se rende compte que qq chose ne va pas"), entraînant des dégats collatéraux non déterminés/ables; ce qui n'arrive pas avec un micro noyau.
Tu peux voir un peu la meme chose sous Unix avec X11 [...] qui tourne en user-mode
Il tourne en user-mode mais le noyau lui permet de dialoguer directement avec le matos, le plaçant donc au niveau des autres pilotes. C'est à cause de cette dichotomie kernel/user mode qu'on se retrouve avec des trucs goret comme cela.
[^] # Re: Petite question: noyau monolithique?
Posté par benja . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 3.
Ben non, le "driver de FS" n'écrit pas sur le disque dur, mais bien le driver (micro-serveur) "disque dur". Avec une architecture traditionnelle, quand ton pilote controleur disque dur plante, il entraîne ton pilote FS avec. Avec une architecture telle que minix3 ce n'est pas forcément vrai. Comme on dit, 90% des écrans de la morts sont dûs à de mauvais pilotes; j'ai la faiblesse de penser que les autres couches sont plus robustes.
Tu as vraiment envie de le redemarrer et effectuer a nouveau l'operation X qui a de bonnes chances de l'avoir fait planter elle-meme au risque qu'il detruise ta partition ?
Quand ton pilote FS s'est craché, redemarrage (de la machine) ou pas, je ne ferais pas trop confiance quant à la cohérence de ce qui reste sur ton disque dur...
Le FS c'est hyper-sensible, que le code qui le gere soit en user-mode ou kernel-mode n'y change pas grand chose, et un probleme la dedans est le plus souvent fatal.
Toutafé, mais nous discuttions de problèmes dûs aux pilotes et tu nous parles de problème de sous-systèmes indépendants du matériel. Au risque de me répéter, ton bug qui apparaît quelque part dans ton noyau peut impacter une toute autre partie de celui-ci (le temps qu'"il se rende compte que qq chose ne va pas"), entraînant des dégats collatéraux non déterminés/ables; ce qui n'arrive pas avec un micro noyau.
Tu peux voir un peu la meme chose sous Unix avec X11 [...] qui tourne en user-mode
Il tourne en user-mode mais le noyau lui permet de dialoguer directement avec le matos, le plaçant donc au niveau des autres pilotes. C'est à cause de cette dichotomie kernel/user mode qu'on se retrouve avec des trucs goret comme cela.