Re: Réinventer la roue

Top Page

Reply to this message
Author: Xavier Bestel
Date:  
To: Olivier Allard-Jacquin
CC: ML Guilde
Subject: Re: Réinventer la roue

On Wed, 2009-04-29 at 19:00 +0200, Olivier Allard-Jacquin wrote:
>     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.


Le doute m'habite.
Déjà le nombre de drivers "indispensables" est assez énorme (même celui
de la carte graphique ou du clavier est dur à éviter pour un utilisateur
lambda). De plus, le moindre driver qui plante le bus PCI (et c'est
assez facile apparemment) va stopper net l'ordinateur.
Donc pour moi, se protéger des drivers c'est un peu illusoire.

    Xav