si c'est bien organisé, je ne vois pas ou est le problème.
Justement c'est cette organisation qui fait défaut. Je ne parle pas ici de découpage en fichier (ou classe, ou module, ou sous-système, ou ce que tu veux) mais bien de compartimentisation du code (binaire, exécutable) en micro serveur. Il faut savoir que dans un micro noyau, les différentes tâche du noyau (pagination, allocation de mémoire, driver, pile réseau, authentification, système de fichier,...) sont réparties dans de "processus différents" (les micros-serveur) qui communiquent entre eux par messages (communication gérer par le micro-noyau proprement dit). Si tu veux, c'est le même genre de séparation kernel/userland d'un noyau monolithique mais entre chaque serveur, en ce sens qu'il y une protection de la mémoire au niveau de chaque serveur. Si un serveur essaye de faire un accès illégal et/ou qu'il se crache et bien il n'emène pas le reste du système avec lui. Dans linux, ces x millions de lignes de code ont toute le même potentiel de destruction vu qu'elles sont dans le même espace d'addressage.
On a souvent dit que cette compartimentalisation entraînait une perte de performance (flagrant pour mach cf le commentaire à propos d'OSX plus haût et pourquoi OSX n'a plus rien à voir avec un micro noyau pour palier à ces problèmes justement) mais la recherche sur L4 (avec ses fast-ipc) montre que les performances n'ont plus à rougir du tout (cf L4Linux où la perte de performance est très faible http://l4linux.org/ alors que linux n'a pas du tout été prévu pour fonctionner de cette façon).
Pour en revenir à mes lignes de codes, bah c'est très simple: il suffit de considérer que le taux de bug est proportionnel au nombre de lignes de codes.
Il faut aussi se rendre compte que les périphériques deviennent de plus en plus complexes (et donc buggés mais c'est un autre débat) et corrolairement les drivers le sont aussi de plus en plus. La complexité augmente, les code-paths s'imbriquent plus profondément (au nom de la performance justement), le débuggage est bien plus ardus qu'à l'époque de linux 1.0. Pour essayer de t'en convaincre, je t'invite à lire la saga sur kerneltrap à propos de la corruption. Oui, ils y sont arrivés mais après quels efforts ? Après combien de supputation ? Aurait-ils découvert ce bug, qui apparemment date d'un bon bout de temps (ou alors c'est un autre qui court toujours, on ne sait pas) sans le patch des pages clustering ? Enfin bref, qu'est-ce que ce sera quand le noyau serat 4x plus grand, ou 10x, voir plus ? Parce qu'il ne fera qu'augmenter en taille, c'est indéniable (à moins de balancer la moitié des drivers à la poubelle).
Je suis loin d'être un spécialiste du domaine (avec un peu de chance, mmenal passera dans le coin nous éclairer de sa lanterne ;-) ) mais voila j'espère que tu comprendras mieux mon commentaire maintenant.
je ne suis pas sur que le micro kernel "by design" garantisse forcement moins de ligne de code...
Au contraire, à fonctionnalités égales (et à language égale), il en contiendra plus vu qu'il faut coder les interfaces des micro-serveurs.
coincé du derrière ou pas,
C'était pour couper court au troll sur le chinois menfin passons...
je ne vois pas en quoi le nombre de ligne a avoir là dedans,
[^] # Re: Argument fallacieux, sophisme et cie...
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 5.
Justement c'est cette organisation qui fait défaut. Je ne parle pas ici de découpage en fichier (ou classe, ou module, ou sous-système, ou ce que tu veux) mais bien de compartimentisation du code (binaire, exécutable) en micro serveur. Il faut savoir que dans un micro noyau, les différentes tâche du noyau (pagination, allocation de mémoire, driver, pile réseau, authentification, système de fichier,...) sont réparties dans de "processus différents" (les micros-serveur) qui communiquent entre eux par messages (communication gérer par le micro-noyau proprement dit). Si tu veux, c'est le même genre de séparation kernel/userland d'un noyau monolithique mais entre chaque serveur, en ce sens qu'il y une protection de la mémoire au niveau de chaque serveur. Si un serveur essaye de faire un accès illégal et/ou qu'il se crache et bien il n'emène pas le reste du système avec lui. Dans linux, ces x millions de lignes de code ont toute le même potentiel de destruction vu qu'elles sont dans le même espace d'addressage.
On a souvent dit que cette compartimentalisation entraînait une perte de performance (flagrant pour mach cf le commentaire à propos d'OSX plus haût et pourquoi OSX n'a plus rien à voir avec un micro noyau pour palier à ces problèmes justement) mais la recherche sur L4 (avec ses fast-ipc) montre que les performances n'ont plus à rougir du tout (cf L4Linux où la perte de performance est très faible http://l4linux.org/ alors que linux n'a pas du tout été prévu pour fonctionner de cette façon).
Pour en revenir à mes lignes de codes, bah c'est très simple: il suffit de considérer que le taux de bug est proportionnel au nombre de lignes de codes.
Il faut aussi se rendre compte que les périphériques deviennent de plus en plus complexes (et donc buggés mais c'est un autre débat) et corrolairement les drivers le sont aussi de plus en plus. La complexité augmente, les code-paths s'imbriquent plus profondément (au nom de la performance justement), le débuggage est bien plus ardus qu'à l'époque de linux 1.0. Pour essayer de t'en convaincre, je t'invite à lire la saga sur kerneltrap à propos de la corruption. Oui, ils y sont arrivés mais après quels efforts ? Après combien de supputation ? Aurait-ils découvert ce bug, qui apparemment date d'un bon bout de temps (ou alors c'est un autre qui court toujours, on ne sait pas) sans le patch des pages clustering ? Enfin bref, qu'est-ce que ce sera quand le noyau serat 4x plus grand, ou 10x, voir plus ? Parce qu'il ne fera qu'augmenter en taille, c'est indéniable (à moins de balancer la moitié des drivers à la poubelle).
Je suis loin d'être un spécialiste du domaine (avec un peu de chance, mmenal passera dans le coin nous éclairer de sa lanterne ;-) ) mais voila j'espère que tu comprendras mieux mon commentaire maintenant.
Au contraire, à fonctionnalités égales (et à language égale), il en contiendra plus vu qu'il faut coder les interfaces des micro-serveurs.
C'était pour couper court au troll sur le chinois menfin passons...
Et maintenant ?