Bonjour,
Je m'interse depuis paut au noyau mais en me documentan je suis tober sur
des textes un peut trop complexe a mon gout.
Je souhaiterai connaitre le difference ent re un micro-noyau et un noyau
monolithique(cf la discution historique en linus Torvalds et tanenbaum).
Je souhaite comprendre le fonctionement de mon noyau auriez vous un livre ou
une doc a me conseiller.
cordialement
ps: Je fait ce post sous window car j'ai literalement bousiller mon noyau :p
Le mar, 23 sep 2003 at 21:15 GMT, à propos de Re: Micro-noyau et noyau monolithique, Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
Là n'est pas le débat. Et de toute façon, il n'y a pas de quoi se relever la nuit.
On peut faire un système viable sur un micro noyau, mais seulement en limitant la sauvegarde des registres lors du changement de contexte.
Tu me feras toujours autant rire, bozo, merci à toi.
C'est déjà ça. Sache que chez Sun, ils y ont pensé, au moins pour ce qui tourne en userland sur les sun4c (changement de contexte particulièrement pourri). Bon, le résultat n'était pas probant (certainement plus à cause du compilo que du concept).
JKB
Le mar, 23 sep 2003 at 21:15 GMT, à propos de
Re: Micro-noyau et noyau monolithique,
Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
Là n'est pas le débat. Et de toute façon, il n'y a pas de quoi se
relever la nuit.
On peut faire un système viable sur un micro noyau, mais
seulement en limitant la sauvegarde des registres lors du
changement de contexte.
Tu me feras toujours autant rire, bozo, merci à toi.
C'est déjà ça. Sache que chez Sun, ils y ont pensé, au moins pour
ce qui tourne en userland sur les sun4c (changement de contexte
particulièrement pourri). Bon, le résultat n'était pas probant
(certainement plus à cause du compilo que du concept).
Le mar, 23 sep 2003 at 21:15 GMT, à propos de Re: Micro-noyau et noyau monolithique, Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
Là n'est pas le débat. Et de toute façon, il n'y a pas de quoi se relever la nuit.
On peut faire un système viable sur un micro noyau, mais seulement en limitant la sauvegarde des registres lors du changement de contexte.
Tu me feras toujours autant rire, bozo, merci à toi.
C'est déjà ça. Sache que chez Sun, ils y ont pensé, au moins pour ce qui tourne en userland sur les sun4c (changement de contexte particulièrement pourri). Bon, le résultat n'était pas probant (certainement plus à cause du compilo que du concept).
JKB
JKB
Le mar, 23 sep 2003 at 17:05 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
On peut faire un système viable sur un micro noyau, mais seulement en limitant la sauvegarde des registres lors du changement de contexte. Sur un processeur Sparc, ça doit être assez performant (rotation des registres), mais sur un Intel, je doute un peu. J'ai essayé Mach sur un ppc (avec un linux par dessus), et le résultat était calamiteux (même pour faire un TX). Je pense que pour avoir un bon système à micronoyau, il _faut_ intégrer certain type de processeur pour gérer de façon transparente les changements de contexte.
Oui, j'ai aussi essayé mklinux, et c'était absolument calamiteux. Mais ça ne prouve pas grand chose, sinon que Mach est mauvais.
Je ne serai pas aussi affirmatif quant à la nullité de Mach, j'ai essayé la bête sur un Mac 7100, le premier processeur ppc, et je pense aussi que ce processeur n'était pas une foudre de guerre ;-)
Maintenant, ton histoire de registres, je ne crois pas que ce soit relevant du tout. D'abord les x86 ont peu de registres, donc le temps de les sauvegarder c'est peanuts.
Exact pour les Intel (et pan sur le bec, je pense toujours à des vraies architectures ;-) ).
Par contre, invalider le cache, etc. ce sont des opérations bien plus longues.
D'accord, sauf que pour moi, un cache se démerde seul. Sa gestion est câblée, donc lors d'un changement de contexte, on va perdre le bénéfice de la mémoire cache, mais le système n'a pas à le gérer (du moins directement). De toute façon, avec un simple changement de tâche dans un séquenceur normal, on en est aussi là, non ?
En fait je ne crois pas que la rotation des fenêtres dans le Sparc apporte un bénéfice mesurable. C'est encore une fausse bonne idée.
Là, je ne suis pas sûr. Ca dépend assez fortement de la façon dont est écrit le code.
J'ai connu un autocommutateur qui tournait grace à un micronoyau sur du motorola 68000 quelque chose, et qui arrivait bien à commuter des centaines de taches à toute vitesse.
Mauvais exemple ! ;-) Tous les 680x0 peuvent tourner sans mémoire cache en faisant un accès mémoire sur un seul cycle d'horloge. Donc il se prête assez bien à ce genre de sport.
Toutes ces taches communiquaient avec le noyau par passage de messages, et il fallait tenir le rythme en temps réél. Donc avec le matos actuel, je ne doute pas qu'il soit possible de commuter de milliers de threads avec ce genre d'architecture sans effondrer la machine.
Justement, je ne suis pas sûr qu'on gagne énormément sur un changement de contexte entre un 68060/75 (par exemple) et un gros processeur plus actuel, vu que la limitation est donnée par l'accès mémoire. On va peut-être sur certain systèmes switcher avec le cache, mais comme certaines données vont bien être récupérées dans la mémoire centrale, le gain de l'opération doit être minime à moins d'avoir un cache assez imposant (style les 8Mo de mon alpha...).
Cordialement,
JKB
Le mar, 23 sep 2003 at 17:05 GMT, à propos de
Re: Micro-noyau et noyau monolithique,
Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB <bertrand@chezmoi.com> wrote:
On peut faire un système viable sur un micro noyau, mais seulement
en limitant la sauvegarde des registres lors du changement de
contexte. Sur un processeur Sparc, ça doit être assez performant
(rotation des registres), mais sur un Intel, je doute un peu. J'ai
essayé Mach sur un ppc (avec un linux par dessus), et le résultat
était calamiteux (même pour faire un TX). Je pense que pour avoir un
bon système à micronoyau, il _faut_ intégrer certain type de
processeur pour gérer de façon transparente les changements de
contexte.
Oui, j'ai aussi essayé mklinux, et c'était absolument calamiteux. Mais
ça ne prouve pas grand chose, sinon que Mach est mauvais.
Je ne serai pas aussi affirmatif quant à la nullité de Mach,
j'ai essayé la bête sur un Mac 7100, le premier processeur ppc,
et je pense aussi que ce processeur n'était pas une foudre
de guerre ;-)
Maintenant, ton histoire de registres, je ne crois pas que ce soit
relevant du tout. D'abord les x86 ont peu de registres, donc le temps de
les sauvegarder c'est peanuts.
Exact pour les Intel (et pan sur le bec, je pense toujours à des
vraies architectures ;-) ).
Par contre, invalider le cache, etc. ce
sont des opérations bien plus longues.
D'accord, sauf que pour moi, un cache se démerde seul. Sa gestion
est câblée, donc lors d'un changement de contexte, on va perdre le
bénéfice de la mémoire cache, mais le système n'a pas à le gérer (du
moins directement). De toute façon, avec un simple changement de
tâche dans un séquenceur normal, on en est aussi là, non ?
En fait je ne crois pas que la
rotation des fenêtres dans le Sparc apporte un bénéfice mesurable. C'est
encore une fausse bonne idée.
Là, je ne suis pas sûr. Ca dépend assez fortement de la façon dont
est écrit le code.
J'ai connu un autocommutateur qui tournait
grace à un micronoyau sur du motorola 68000 quelque chose, et qui
arrivait bien à commuter des centaines de taches à toute vitesse.
Mauvais exemple ! ;-)
Tous les 680x0 peuvent tourner sans mémoire cache en faisant un
accès mémoire sur un seul cycle d'horloge. Donc il se prête assez
bien à ce genre de sport.
Toutes
ces taches communiquaient avec le noyau par passage de messages, et il
fallait tenir le rythme en temps réél. Donc avec le matos actuel, je ne
doute pas qu'il soit possible de commuter de milliers de threads avec
ce genre d'architecture sans effondrer la machine.
Justement, je ne suis pas sûr qu'on gagne énormément sur un
changement de contexte entre un 68060/75 (par exemple) et un gros
processeur plus actuel, vu que la limitation est donnée par l'accès
mémoire. On va peut-être sur certain systèmes switcher avec le
cache, mais comme certaines données vont bien être récupérées dans la
mémoire centrale, le gain de l'opération doit être minime à moins
d'avoir un cache assez imposant (style les 8Mo de mon alpha...).
Le mar, 23 sep 2003 at 17:05 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel Talon écrivait dans fr.comp.os.linux.debats :
JKB wrote:
On peut faire un système viable sur un micro noyau, mais seulement en limitant la sauvegarde des registres lors du changement de contexte. Sur un processeur Sparc, ça doit être assez performant (rotation des registres), mais sur un Intel, je doute un peu. J'ai essayé Mach sur un ppc (avec un linux par dessus), et le résultat était calamiteux (même pour faire un TX). Je pense que pour avoir un bon système à micronoyau, il _faut_ intégrer certain type de processeur pour gérer de façon transparente les changements de contexte.
Oui, j'ai aussi essayé mklinux, et c'était absolument calamiteux. Mais ça ne prouve pas grand chose, sinon que Mach est mauvais.
Je ne serai pas aussi affirmatif quant à la nullité de Mach, j'ai essayé la bête sur un Mac 7100, le premier processeur ppc, et je pense aussi que ce processeur n'était pas une foudre de guerre ;-)
Maintenant, ton histoire de registres, je ne crois pas que ce soit relevant du tout. D'abord les x86 ont peu de registres, donc le temps de les sauvegarder c'est peanuts.
Exact pour les Intel (et pan sur le bec, je pense toujours à des vraies architectures ;-) ).
Par contre, invalider le cache, etc. ce sont des opérations bien plus longues.
D'accord, sauf que pour moi, un cache se démerde seul. Sa gestion est câblée, donc lors d'un changement de contexte, on va perdre le bénéfice de la mémoire cache, mais le système n'a pas à le gérer (du moins directement). De toute façon, avec un simple changement de tâche dans un séquenceur normal, on en est aussi là, non ?
En fait je ne crois pas que la rotation des fenêtres dans le Sparc apporte un bénéfice mesurable. C'est encore une fausse bonne idée.
Là, je ne suis pas sûr. Ca dépend assez fortement de la façon dont est écrit le code.
J'ai connu un autocommutateur qui tournait grace à un micronoyau sur du motorola 68000 quelque chose, et qui arrivait bien à commuter des centaines de taches à toute vitesse.
Mauvais exemple ! ;-) Tous les 680x0 peuvent tourner sans mémoire cache en faisant un accès mémoire sur un seul cycle d'horloge. Donc il se prête assez bien à ce genre de sport.
Toutes ces taches communiquaient avec le noyau par passage de messages, et il fallait tenir le rythme en temps réél. Donc avec le matos actuel, je ne doute pas qu'il soit possible de commuter de milliers de threads avec ce genre d'architecture sans effondrer la machine.
Justement, je ne suis pas sûr qu'on gagne énormément sur un changement de contexte entre un 68060/75 (par exemple) et un gros processeur plus actuel, vu que la limitation est donnée par l'accès mémoire. On va peut-être sur certain systèmes switcher avec le cache, mais comme certaines données vont bien être récupérées dans la mémoire centrale, le gain de l'opération doit être minime à moins d'avoir un cache assez imposant (style les 8Mo de mon alpha...).
Cordialement,
JKB
JKB
Le mer, 24 sep 2003 at 08:07 GMT, à propos de Re: Micro-noyau et noyau monolithique, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Dans article , disait...
Je te signale que j'ai bossé il y a quelques années avec un compilo de Sun (sur SunOS 4.x et Solaris 2.5) qui faisait exactement ça.
Mon dieu, alors Sun n'a pas seulement inventé Java, ils ont inventé le compilateur qui optimise en optimisant pas... :°D
Oui, personne n'est parfait ;-) Mais bon, sur les sun4c, il fallait mieux optimiser un peu... Ce qui est assez pénible, c'est que jamais dans la doc du compilo ne figurait cette feature... En fait, je suis tombé dessus parce qu'une routine plantait lamentablement (un paramètre d'entrée passait à la trappe lors de l'appel).
JKB, qui aime bien gcc finalement...
Le mer, 24 sep 2003 at 08:07 GMT, à propos de
Re: Micro-noyau et noyau monolithique,
Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Dans article <slrnbn2i6o.que.bertrand@zebigbos.makalis.fr>,
bertrand@chezmoi.com disait...
Je te signale que j'ai bossé il y a quelques années avec un compilo
de Sun (sur SunOS 4.x et Solaris 2.5) qui faisait exactement ça.
Mon dieu, alors Sun n'a pas seulement inventé Java, ils ont inventé le
compilateur qui optimise en optimisant pas... :°D
Oui, personne n'est parfait ;-) Mais bon, sur les sun4c, il fallait
mieux optimiser un peu... Ce qui est assez pénible, c'est que jamais
dans la doc du compilo ne figurait cette feature... En fait, je suis
tombé dessus parce qu'une routine plantait lamentablement (un
paramètre d'entrée passait à la trappe lors de l'appel).
Le mer, 24 sep 2003 at 08:07 GMT, à propos de Re: Micro-noyau et noyau monolithique, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Dans article , disait...
Je te signale que j'ai bossé il y a quelques années avec un compilo de Sun (sur SunOS 4.x et Solaris 2.5) qui faisait exactement ça.
Mon dieu, alors Sun n'a pas seulement inventé Java, ils ont inventé le compilateur qui optimise en optimisant pas... :°D
Oui, personne n'est parfait ;-) Mais bon, sur les sun4c, il fallait mieux optimiser un peu... Ce qui est assez pénible, c'est que jamais dans la doc du compilo ne figurait cette feature... En fait, je suis tombé dessus parce qu'une routine plantait lamentablement (un paramètre d'entrée passait à la trappe lors de l'appel).
JKB, qui aime bien gcc finalement...
Naibed
Gwenaelle wrote in news:3f6ffd40$0$24187$:
Naibed wrote:
Richard Delorme wrote in news:3f6e2a35$0$20950$:
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
tu oublies windows NT (XP, 2003, ...) qui est un micro-kernel monolithique qui fonctionne mal.
Exact, je l'avais oublié, celui-là ... :-))
J'y crois pas... elle est là AUSSI ! argh !
Qu'est-ce que tu viens faire dans ma tanière ? Et t'avises pas d'essayer de me tirer les moustaches !! Grrrr....
news:
N -- -+---------------+-----------------+-----------------+- Rien n'est plus beau ...(refrain connu)
Gwenaelle <selune@mytilene.org> wrote in
news:3f6ffd40$0$24187$ba620e4c@reader0.news.skynet.be:
Naibed wrote:
Richard Delorme <abulmo@nospam.fr> wrote in
news:3f6e2a35$0$20950$7a628cd7@news.club-internet.fr:
La différence, c'est qu'il y a des noyaux monolithiques qui
fonctionnent bien (p.e. linux) et d'autres mal (windows).
Alors que pour les micro-noyaux, c'est l'inverse: il y a
des noyaux qui fonctionnent mal (p.e. hurd) et d'autres
qui fonctionnent bien (mach)
tu oublies windows NT (XP, 2003, ...) qui est un micro-kernel
monolithique qui fonctionne mal.
Exact, je l'avais oublié, celui-là ... :-))
J'y crois pas... elle est là AUSSI !
argh !
Qu'est-ce que tu viens faire dans ma tanière ? Et t'avises pas
d'essayer de me tirer les moustaches !! Grrrr....
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
tu oublies windows NT (XP, 2003, ...) qui est un micro-kernel monolithique qui fonctionne mal.
Exact, je l'avais oublié, celui-là ... :-))
J'y crois pas... elle est là AUSSI ! argh !
Qu'est-ce que tu viens faire dans ma tanière ? Et t'avises pas d'essayer de me tirer les moustaches !! Grrrr....
news:
N -- -+---------------+-----------------+-----------------+- Rien n'est plus beau ...(refrain connu)
Michel BILLAUD
JKB writes:
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce satané bouquin régulièrement sous les yeux ;-)
C'était pas plutôt K2R, le truc pour les tâches ?
MB -- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
JKB <bertrand@chezmoi.com> writes:
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il
y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce
satané bouquin régulièrement sous les yeux ;-)
C'était pas plutôt K2R, le truc pour les tâches ?
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792
351, cours de la Liberation http://www.labri.fr/~billaud
33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce satané bouquin régulièrement sous les yeux ;-)
C'était pas plutôt K2R, le truc pour les tâches ?
MB -- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
JKB
Le jeu, 25 sep 2003 at 21:06 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel BILLAUD écrivait dans fr.comp.os.linux.debats :
JKB writes:
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce satané bouquin régulièrement sous les yeux ;-)
C'était pas plutôt K2R, le truc pour les tâches ?
;-)
Le jeu, 25 sep 2003 at 21:06 GMT, à propos de
Re: Micro-noyau et noyau monolithique,
Michel BILLAUD écrivait dans fr.comp.os.linux.debats :
JKB <bertrand@chezmoi.com> writes:
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il
y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce
satané bouquin régulièrement sous les yeux ;-)
Le jeu, 25 sep 2003 at 21:06 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel BILLAUD écrivait dans fr.comp.os.linux.debats :
JKB writes:
Zut, m'ai gouré sur le nom. En tout cas, dans la doc IBM d'OS/2, il y a écrit quelque part nouyau K&R. Ca doit être le fait d'avoir ce satané bouquin régulièrement sous les yeux ;-)
C'était pas plutôt K2R, le truc pour les tâches ?
;-)
Nicolas Centa
Naibed writes:
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben .. qui fonctionne bien est un peu exagere :-)
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs.
Naibed <Naibed@hotmail.com> writes:
La différence, c'est qu'il y a des noyaux monolithiques qui
fonctionnent bien (p.e. linux) et d'autres mal (windows).
Alors que pour les micro-noyaux, c'est l'inverse: il y a
des noyaux qui fonctionnent mal (p.e. hurd) et d'autres
qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement
de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben ..
qui fonctionne bien est un peu exagere :-)
On peut donc dire que certaines implementations de mach fonctionnent, et
encore, uniquement dans des contextes monoserveurs.
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben .. qui fonctionne bien est un peu exagere :-)
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs.
Nicolas Centa
(Michel Talon) writes:
JKB wrote:
Le dim, 21 sep 2003 at 22:09 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel Talon écrivait dans fr.comp.os.linux.debats :
mieux gérer le multiprocessing, et de fait aussi bien Solaris que WindowsNT ont été conçus à partir d'un micronoyau.
Pour NT, on va ergoter. Les vieux (jusques au 4) étaient basés sur un fork du noyau d'OS/2 qui est un K&R (et donc pas un micro noyau). Quant aux versions plus récentes, plein de trucs tournent en kernelland (en particulier les pilotes graphiques pour des gains de temps [sic. Microsoft], ce qui fait qu'un pilote écrit avec un pied gauche emmanché dans un moufle peut planter le système et ne s'en prive pas !). Donc il y a peut-être un micro noyau, mais histoire alors de dire qu'il y a un micro noyau, parce qu'on a tous les emm*rdements des micro noyaux sans en avoir les avantages...
Oui je me garderais bien de dire ce qu'il y a concrètement dans WindowsNT ou Solaris. Ils ont été conçus avec l'idée de faire un système basé sur un micronoyau, et puis pour des raisons de performances, ils ont mis de plus en plus de choses en kernelland, si bien que maintenant, rien n'est clair. Mais enfin il *semble* qu'on puisse faire un système performant sur un micronoyau strict, tel que le port de Linux sur L4 ou QNX (mais qu'en est-il exactement de QNX?).
Ce sont des monoserveurs, c'est-a-dire des 'kernels' monolithiques au dessus de microkernels, leur enlevant tous leurs avantages.
talon@lpthe.jussieu.fr (Michel Talon) writes:
JKB <bertrand@chezmoi.com> wrote:
Le dim, 21 sep 2003 at 22:09 GMT, à propos de
Re: Micro-noyau et noyau monolithique,
Michel Talon écrivait dans fr.comp.os.linux.debats :
mieux gérer le multiprocessing, et de fait aussi bien Solaris que
WindowsNT ont été conçus à partir d'un micronoyau.
Pour NT, on va ergoter. Les vieux (jusques au 4) étaient basés sur
un fork du noyau d'OS/2 qui est un K&R (et donc pas un micro noyau).
Quant aux versions plus récentes, plein de trucs tournent en
kernelland (en particulier les pilotes graphiques pour des gains de
temps [sic. Microsoft], ce qui fait qu'un pilote écrit avec un pied
gauche emmanché dans un moufle peut planter le système et ne s'en
prive pas !). Donc il y a peut-être un micro noyau, mais histoire
alors de dire qu'il y a un micro noyau, parce qu'on a tous les
emm*rdements des micro noyaux sans en avoir les avantages...
Oui je me garderais bien de dire ce qu'il y a concrètement dans
WindowsNT ou Solaris. Ils ont été conçus avec l'idée de faire un système
basé sur un micronoyau, et puis pour des raisons de performances, ils
ont mis de plus en plus de choses en kernelland, si bien que maintenant,
rien n'est clair. Mais enfin il *semble* qu'on puisse faire un système
performant sur un micronoyau strict, tel que le port de Linux sur L4 ou
QNX (mais qu'en est-il exactement de QNX?).
Ce sont des monoserveurs, c'est-a-dire des 'kernels' monolithiques au dessus
de microkernels, leur enlevant tous leurs avantages.
Le dim, 21 sep 2003 at 22:09 GMT, à propos de Re: Micro-noyau et noyau monolithique, Michel Talon écrivait dans fr.comp.os.linux.debats :
mieux gérer le multiprocessing, et de fait aussi bien Solaris que WindowsNT ont été conçus à partir d'un micronoyau.
Pour NT, on va ergoter. Les vieux (jusques au 4) étaient basés sur un fork du noyau d'OS/2 qui est un K&R (et donc pas un micro noyau). Quant aux versions plus récentes, plein de trucs tournent en kernelland (en particulier les pilotes graphiques pour des gains de temps [sic. Microsoft], ce qui fait qu'un pilote écrit avec un pied gauche emmanché dans un moufle peut planter le système et ne s'en prive pas !). Donc il y a peut-être un micro noyau, mais histoire alors de dire qu'il y a un micro noyau, parce qu'on a tous les emm*rdements des micro noyaux sans en avoir les avantages...
Oui je me garderais bien de dire ce qu'il y a concrètement dans WindowsNT ou Solaris. Ils ont été conçus avec l'idée de faire un système basé sur un micronoyau, et puis pour des raisons de performances, ils ont mis de plus en plus de choses en kernelland, si bien que maintenant, rien n'est clair. Mais enfin il *semble* qu'on puisse faire un système performant sur un micronoyau strict, tel que le port de Linux sur L4 ou QNX (mais qu'en est-il exactement de QNX?).
Ce sont des monoserveurs, c'est-a-dire des 'kernels' monolithiques au dessus de microkernels, leur enlevant tous leurs avantages.
Naibed
Nicolas Centa wrote in news::
Naibed writes:
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben .. qui fonctionne bien est un peu exagere :-)
Oui, oui ..je savais cela: Hurd n'est pas un noyau, mais un système de serveurs au dessus de mach ......mais il me fallait bien un peu forcer les faits pour terminer ma boutade... ;-)
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs.
Développements ? et quid pour Mac OS X / Darwin, que je ne connais absolument pas, mais qui tourne aussi, sur un noyau mach (le Mach 3.0 de la Carnegie Mellon University). ?
BTW, je viens d'acheter (parution en Belgique avec qqes semaines de retard) le "HS16 Kernel, Voyage au centre du noyau": parcouru en (triple) vitesse. M'a vraiment l'air bien fait. Je le lirai ce WE.
N -- -+---------------+-----------------+-----------------+- Rien n'est plus beau ...(refrain connu)
Nicolas Centa <nicolas@NicoComputer.LocalNet> wrote in
news:874qyyogfv.fsf@Thor.Galaxy.sg:
Naibed <Naibed@hotmail.com> writes:
La différence, c'est qu'il y a des noyaux monolithiques qui
fonctionnent bien (p.e. linux) et d'autres mal (windows).
Alors que pour les micro-noyaux, c'est l'inverse: il y a
des noyaux qui fonctionnent mal (p.e. hurd) et d'autres
qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement
de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben ..
qui fonctionne bien est un peu exagere :-)
Oui, oui ..je savais cela: Hurd n'est pas un noyau, mais un système de
serveurs au dessus de mach ......mais il me fallait bien un peu forcer
les faits pour terminer ma boutade... ;-)
On peut donc dire que certaines implementations de mach fonctionnent, et
encore, uniquement dans des contextes monoserveurs.
Développements ? et quid pour Mac OS X / Darwin, que je ne connais
absolument pas, mais qui tourne aussi, sur un noyau mach
(le Mach 3.0 de la Carnegie Mellon University). ?
BTW, je viens d'acheter (parution en Belgique avec qqes semaines de retard)
le "HS16 Kernel, Voyage au centre du noyau": parcouru en (triple) vitesse.
M'a vraiment l'air bien fait. Je le lirai ce WE.
N
--
-+---------------+-----------------+-----------------+-
Rien n'est plus beau ...(refrain connu)
La différence, c'est qu'il y a des noyaux monolithiques qui fonctionnent bien (p.e. linux) et d'autres mal (windows). Alors que pour les micro-noyaux, c'est l'inverse: il y a des noyaux qui fonctionnent mal (p.e. hurd) et d'autres qui fonctionnent bien (mach)
Laissez-moi vous rappeller que jusqu'a un on l'espere prochain achevement de L4/Hurd, le Hurd actuel tourne bel et bien sur mach, et que .. ben .. qui fonctionne bien est un peu exagere :-)
Oui, oui ..je savais cela: Hurd n'est pas un noyau, mais un système de serveurs au dessus de mach ......mais il me fallait bien un peu forcer les faits pour terminer ma boutade... ;-)
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs.
Développements ? et quid pour Mac OS X / Darwin, que je ne connais absolument pas, mais qui tourne aussi, sur un noyau mach (le Mach 3.0 de la Carnegie Mellon University). ?
BTW, je viens d'acheter (parution en Belgique avec qqes semaines de retard) le "HS16 Kernel, Voyage au centre du noyau": parcouru en (triple) vitesse. M'a vraiment l'air bien fait. Je le lirai ce WE.
N -- -+---------------+-----------------+-----------------+- Rien n'est plus beau ...(refrain connu)
gutkneco+news
Naibed wrote:
Nicolas Centa wrote in news::
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs. Développements ? et quid pour Mac OS X / Darwin, que je ne connais
absolument pas, mais qui tourne aussi, sur un noyau mach (le Mach 3.0 de la Carnegie Mellon University). ?
Mach 3 assez modifié, mais qui ne tourne -pas- en mk + monoserveur. Le noyau bsd est colocalisé avec le Mach. La séparation est architecturale plutôt qu'à l'exécution.
Ol. -- Olivier Gutknecht
Naibed <Naibed@hotmail.com> wrote:
Nicolas Centa <nicolas@NicoComputer.LocalNet> wrote in
news:874qyyogfv.fsf@Thor.Galaxy.sg:
On peut donc dire que certaines implementations de mach fonctionnent, et
encore, uniquement dans des contextes monoserveurs.
Développements ? et quid pour Mac OS X / Darwin, que je ne connais
absolument pas, mais qui tourne aussi, sur un noyau mach
(le Mach 3.0 de la Carnegie Mellon University). ?
Mach 3 assez modifié, mais qui ne tourne -pas- en mk + monoserveur. Le
noyau bsd est colocalisé avec le Mach. La séparation est architecturale
plutôt qu'à l'exécution.
On peut donc dire que certaines implementations de mach fonctionnent, et encore, uniquement dans des contextes monoserveurs. Développements ? et quid pour Mac OS X / Darwin, que je ne connais
absolument pas, mais qui tourne aussi, sur un noyau mach (le Mach 3.0 de la Carnegie Mellon University). ?
Mach 3 assez modifié, mais qui ne tourne -pas- en mk + monoserveur. Le noyau bsd est colocalisé avec le Mach. La séparation est architecturale plutôt qu'à l'exécution.
