Re: Réinventer la roue

Top Page

Reply to this message
Author: Olivier Allard-Jacquin
Date:  
To: ML Guilde
Old-Topics: Re: Réinventer la roue
Subject: Re: Réinventer la roue
    Bonjour,

Marc TERRIER a écrit :
> Et histoire d'en remettre une petite couche, je vous propose, côte à côte :
>
> 1) un extrait de l'article du Monde Informatique signalé par Hervé :
>
> « Pour Andy Tanenbaum, tout vient de l'instabilité du système d'exploitation.
> Windows, bien sûr, mais Linux n'est pas épargné, de par sa conception identique
> : des dizaines de pilotes logiciels - soit des bouts de code écrits par des
> centaines de développeurs - pour les périphériques sont chargés au sein du
> noyau, ce qui ouvre la porte à toutes sortes de problèmes. »
>
> 2) un extrait de l'appel à contributions visible sur www.minix3.org :
>
> « How Can I Help Develop MINIX 3 Further?
>
> Like Linux, FreeBSD, Apache, Firefox, GNU, and many other free software
> projects, MINIX 3 is a community effort. [...] The top four areas we need help
> in are:
>
>    1. More device drivers for common peripherals [...] »

>
> Donc, en résumé, Andrew TANENBAUM critique le modèle de développement
> communautaire de Linux, notamment pour ce qui est des drivers, et en même temps,
> il demande à des gens qu'il ne connait ni d'Eve ni d'Adam, de l'aider au
> développement de Minix en fournissant... des drivers.
>
> J'ai sûrement dû rater une étape dans le raisonnement...    ;-)


    De ce que j'ai lu, le fonctionnent d'un micro-noyau tel que MINIX fait
que les drivers sont considérés comme des process comme les autres (un
peu plus prioritaire que les process utilisateurs quand même).


    De ce fait, et **en théorie**, un plantage d'un driver ne peut pas
planter le micro-noyau. Contrairement à Linux, ou le plantage d'un
module peut entraîner le kernel avec lui. De plus, les modules sont
supposés être redémarrés "à chaud", en cas de plantage


    Donc j'imagine qu'il doit penser que ce mode de fonctionnement permet
de supporter des développeurs "externes", dont le code n'est pas
forcément très "stable" ou "propre". D'où son appel à contribution.


    Dans la théorie, son approche est exacte. Mais il n'empêche que, si
c'est le module de gestion de la mémoire virtuelle qui plante, ou celui
du disque dur ou du réseau, le système aura du mal à fonctionner quand
même...


    A noter que Windows (XP et supérieur, mais 2000 aussi il me semble) est
basé sur une techno similaire au micro-noyau. Lorsqu'on interroge les
devs MS à ce sujet, ils argumentent, bien sûr, que cette technique est
mieux que celle de Linux.    Cependant, lorsqu'on leur fait remarquer qu'il
y a quand même des "écrans bleu" sous Windows, la réponse est
généralement "C'est la faute d'un driver mal écrit, qui a planté le
noyau". Comme quoi, la séparation du micro-noyau avec ses drivers n'est
pas si "étanche" que cela.


    Cordialement,


                        Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!