Un article de Wikipédia, l'encyclopédie libre.

	Noyau de système d'exploitation fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser.
AdQ	Cet article a été classé comme d'Avancement AdQ selon le Tableau d'évaluation du projet. (Voir les statistiques)
Élevée	Cet article a été classé comme d'Importance élevée selon le Tableau d'évaluation du projet. (Contester?)

La version actuelle de Noyau de système d'exploitation a été sélectionnée par le comité de sélection du projet Wikipédia 1.0. En discuter...

Noyau de système d'exploitation est apparu sur la page d'accueil de Wikipédia en tant qu'article mis en lumière le 13 et 14 avril 2006.

	Tâches à accomplir pour Noyau de système d'exploitation	aide
	Augmenter le nombre de références

---

Il y a tellement de noyaux qu'il est préférable d'être clair pour éviter les pépins. Meszigues 11 jun 2003 ・16:38 (CEST)

C'est quoi cette histoire de copyright en bas de la page?? Med 11 jun 2003 ・17:11 (CEST)

meme question Maston28 11 jun 2003 ・17:15 (CEST)

sur le log, il y a : "(Cette page est tirée de <http://www.freenix.fr/unix/linux/HOWTO/Kernel-HOWTO-2.html>. Copyright permettant la reproduction si mention, dont acte (?))"

il faudrait réécrire l'article, on ne peut pas utiliser ce genre de contenu il me semble... !Maston28 11 jun 2003 ・17:19 (CEST)

C'est moi qui ai inclus le copyright, puisque, après avoir découvert que la page était tirée du site que j'ai mentionné, j'ai aussi constaté que la reproduction était possible tant que l'on indique le copyright. Cela dit, je trouve cette mention un peu choquante dans Wikipédia, et ne serais pas opposé à une refonte complète ou une suppression. Vincent Ramos 11 jun 2003 ・21:11 (CEST)

surtout que le texte n'est pas particulièrement impressionnant... Koxinga

N'y a-t-il aucun unixien dans la salle qui puisse pondre un truc un peu plus étoffé (en évitant les « vos », « votre », assez étranges quand on ne connaît rien à Unix...) ? Sinon, on élimine ? Vincent Ramos 11 jun 2003 ・23:01 (CEST)

Le droit de reproduction ne suffit pas. Il faut aussi le droit de modification. Mais en plus, les textes de wikipedia doivent etres explicitement publiees par leurs auteurs sous les termes de la GFDL. On peu demander a l'auteur -- ou on peut repondre ca nous-meme! -- Tarquin 12 jun 2003 ・00:06 (CEST)

---

En fait je me demandais. Pourquoi "noyau Unix" comme titre. Ce qui est marqué ressemble à la définition de n'importe quel noyau d'OS, que ce soit un Unix ou pas. Un avis éclairé sur la question? Med 11 jun 2003 ・20:55 (CEST)

noyau (informatique) ou noyau (OS) alors? -- Tarquin 11 jun 2003 ・23:56 (CEST)

Personnellement je verrai bien la première solution. D'autres avis? Med 11 jun 2003 ・23:59 (CEST)

Je ne suis pas d'accord, ce n'est pas libéral, votre manière de faire ;D Bon, nous sommes tpus quatre d'accord. Je renomme en noyau (informatique), il n'y aura pas beaucoup de toto (système d'exploitation, àmho Alvaro 12 jun 2003 ・00:12 (CEST)

Sage décision, j'ai déplacé la page car le titre "noyau" était trop général et donc pouvait préter à confusion. Je suis allé au plus vite, le contenu parlait d'Unix d'où le choix pour "noyau Unix". Ensuite, je me suis occupé à créer la page "noyau" d'homonymie et à essayer de faire pointer tous les liens "noyau" vers le bon noyau (ainsi je suis tomber sur un pepin avec les noyaux d'anneau). Meszigues 12 jun 2003 ・09:57 (CEST)

ahahaha, t'es tombé sur un pépin en causant de noyau ! bravo, Meszigues ! Bon boulot, merci ;D Alvaro 12 jun 2003 ・15:38 (CEST)

---

J'aimerai qu'on précise que Linux est monolithique modulaire. MacosX est monolithique ?! Et darwin son micro noyau il sert à quoi ? Windows un micro noyau ? Bof, il est pas monolithique mais MICRO noyau... Un bon compromis serait MACRO noyau. Je rapelle qu'on est encore obligé de rebooter WindowsXP après avoir installer certain programmes. Si Windows utilisait un 'vrai' micro noyau, il en serait autrement !

Mac OS X utilise un 'vrai' micro-noyau (ou presque : XNU, dérivé de Mach), et on est quand même obligé de rebooter redémarrer après avoir installé certains logiciels. Il faudra que je ponde un article sur XNU un de ces jours moi. Alibaba 3 avr 2004 à 00:38 (CEST)

>Pas d'accord, MacOSX a (au même titre que windows) un noyau hybride (micronoyau enrichi)

Sommaire 1 Confusion 2 Traduction 3 Copie et enrichissement de cette page 4 Développeur noyau ? 5 Modifications récentes sur les micro-noyaux 5.1 Modifications sur les micro-noyaux 6 Fusion 7 Schémas 8 Structure globale 8.1 Mémoire 8.2 introduction revue 8.3 Windows - noyau monolithiques 8.4 L'existence d'un noyau présuppose une partition virtuelle de la mémoire vive physique en deux régions disjointe 8.5 Mémoire 8.6 Exécution dans le noyau 8.7 gestion de mémoire et cache 8.8 Question de logique 8.9 Gestion optimiste et non optimisée de la mémoire 8.10 Drivers en espace utilisateur dans les noyaux monolithiques 8.11 Maintenance des noyaux monolitiques : FUD ? 8.11.1 Changement de mode 8.12 Proposition de sélection de cet article pour Portail:Informatique

[modifier] Confusion

Je trouve que cette partie est légèrement confuse : « Mais la mise en place de micronoyaux, même si elle est très interressante en théorie s'avère difficile. Ainsi les performances de Linux sont supérieures à celles de ses concurrents (noyaux généralistes), sans compter qu'il fut finalement porté sur de très nombreuses plateformes et qu'il est modulaire depuis 1995. », car déja Linux n'est pas un micro-noyaux. [[Utilisateur:Francois Trazzi|François Trazzi | ↹ ]] 22 oct 2004 à 21:17 (CEST)

>linux n'est, en effet pas un micro noyaux, alors où est le problème ?

[modifier] Traduction

cette page est elle une pale tentative de traduction de la meme en anglais ? Si oui, le resultat n'est pas satifaisant, si non, alors elle devrait etre reecrite plus lisiblement. AMHA. Stéphane 6 avr 2005 à 02:27 (CEST)

[modifier] Copie et enrichissement de cette page

Je me suis servi de cette page pour créer une autre page sur les noyaux ici : http://www.clubic.com/wiki/Noyau (Dans le mêmes conditions de licences. N'hésitez pas à copier/modifier. La discussion sur OS X est interressante, mais vous oubliez la notion de bus objet sur les micronoyaux! (Ce qui fait de OS X un mk noyau)

Le bus objet fait partie de Gnome (via CORBA) et KDE (en plus light et plus modulaire) depuis pas mal de temps, il s'agit plutôt d'une couche applicative basse que d'une couche noyau. Certains diront même que noyau et objets ne font pas bon ménage, toussa... ;-) Nÿco 6 avr 2005 à 10:39 (CEST)

Non, on ne parle pas du même bus. Les micronoyaux sont basées sur l'utilisation d'un bus également sur lequel les services viennent se brancher Voir mon lien. De plus pour les 'objets une technologie objet ne suppose pas nécessairement un langage objet. (C'est le cas de nombreux noyaux, dont 100% des noyaux modulaires).

(indente bien tes réponses et signe avec 4 tildes stp)

Les micro-noyaux, ne sont _généralement_ pas basés sur un _bus_, encore moins _objet_, c'est une généralité qui est fausse. Il en existe sans doute, mais ce n'est pas généralisable. Tu as des exemples stp ?

Mach et L4. A ton avis, pourquoi est hurd/mach est basé sur des échanges de 'messages' plutôt que des appels de fonctions ? Qu'est ce qui fait 'circuler' les 'messages'?

Non, je ne vais pas voir ton lien, c'est un fork de cette page, c'est stupide d'avoir fait ça.

C'est beaucoup plus qu'un simple fork. Inutile de m'insulter.

Il serait bon d'intégrer les modifs que tu as apportées sur ton site perso sur cet article Wikipédia. Si tu veux en maintenir une copie, libre à toi.

Le site en question crée une encyclopédie dédiée à l'informatique. Il est normal qu'on trouve des choses communes aux deux sites, et il est normal que le site en question (clubic) avance des notions qui peuvent être plus pointues que wikipedia. Qui plus est, celà permet une prise en charge des ressources matérielles par ce site, et allège la charge de Wikipédia. Maintenant ce n'est que mon avis.Je veux bien faire un backport sur wikipedia. La question est où je mets le brouillon? Mieux vaut corriger déjà sur ce site avant de le reporter ici?

Modulaire ne signifie pas objet, il n'y a pas correspondance/bijection/synonyme.

Quand on parle 'de technologie objet' on parle pas forcément de python ou de C++, on parle d'héritage et de classe. Et les technologies d'héritages et de classes sont effectivement dans la très grande majorité des systèmes actuels. La vfs (virtual filesystem) de linux est un exemple type de technologie objet écrite en langage non objet. Il y a très clairement dans les divers fs un héritage de fonction de la vfs. Que le terme 'class' apparaisse ou non n'est pas important. Idem pour les périphériques, et les modules sont des classes abstraites dans une syntaxe UML.

Nÿco 6 avr 2005 à 11:39 (CEST)

[modifier] Développeur noyau ?

Question, à part moi qui débarque dans la discussion, qui travaille sur le dev. d'un noyau? Ce serait interressant d'avoir d'autres personnes compétantes (et si possible dans d'autres noyaux que linux)

[modifier] Modifications récentes sur les micro-noyaux

Bonjour, j'ai modifié la partie sur les micro-noyaux en ajoutant plus de détails (sources : doc de Mach et L4, articles de Jochen Liedtke, expérience personnelle). Est-ce que des personnes de passage pourraient donner leur avis sur cette nouvelle version ? Merci

Même chose pour la partie micro-noyaux hybrides. Je trouvais que la définition précédente n'insistait pas suffisamment sur la notion d'architecture réellement "hybride". Or la définition de "hybride" est pourtant bien précise. J'ai repris celle de Wikipedia anglophone ("Hybrid" implies that the kernel in question shares architectural concepts or mechanisms with both monolithic and microkernel designs - specifically message passing and migration of "non-essential" code into userspace while retaining some "non-essential" code in the kernel proper for performance reasons.") tout en laissant la définition précédentes et les exemples. Cependant peut on réellement qualifier Linux de noyau hybride ? Je trouve cela étrange, peut on avoir plus d'explications là-dessus ? De même, selon la définition précédente, Hurd ne serait pas hybride puisqu'il rajoute les serveurs nécessaires au micro-noyau, mais ne constitue pas un noyau en soi. C'est une collection de serveurs externes. Qu'en pensez vous ?

Sinon dans la partie micro-noyaux enrichis, peut on réellement parler de défauts ? Un micro-kernel sans serveurs externes n'a pas de raison de vivre, il est trop minimaliste. Ne devrions nous pas enlever en conséquence cette notion d'avantages et de défauts ?

Cedric77 2 août 2005 à 17:09 (CEST)

[modifier] Modifications sur les micro-noyaux

En effet la partie sur les micro noyau est bien plus interressante présentée ainsi. Je me demande si on devrait proposer des shémas d'architectures : même si les notions sont simplifiées, je ne suis pas sûr que n'importe qui soit capable de lire et de comprendre ce texte, y compris parmis les informaticiens.

Dans le cadre de la définition anglaise, Linux est clairement non-hybride : il ne reprend absoluement pas l'architecture d'un micro noyau (spinlock vs mpi/ipc... ). Il y a peut être eu une confusion quand je dit que Linux (et tout les OS) ont au minimum les 'fonctionnalités d'un micro noyau' est l'allocation de mémoire et d'ordonancement. Je pense que la formule est mauvaise. 'Fonctions de bases d'un noyau' est meilleur?

Idem pour HURD. Hurd n'est absoluement pas hybride, c'est au contraire un des rares micro noyau 'pur'. Les noyau hybrides sont XNU (OSX), Windows XP (Mais ce n'est pas documenté), et les noyau RT utilisant un micro noyau temps réel qui aloue du temps d'exécution à "autre" noyau (RTLinux par ex)

V_atekor

Effectivement ce serait préférable d'accompagner l'article de schémas qui montreraient bien la différence entre les différents concepts. Je ne pourrai pas m'en occuper en septembre, mais dès octobre je m'y attèle et je pourrai faire des propositions.

Cedric77 31 août 2005 à 17:55 (CEST)

[modifier] Fusion

Noyau (informatique), Micronoyau et Noyau monolithique

La page Micronoyau est indiquée comme doublon, j'ai rajouté le bandeau pour Noyau monolithique (qui est peu détaillé). Noyau (informatique) semble être la page la plus développée, mais doit-on en faire une page monolithique pour autant ? ;-) --Ant.amarilli 4 septembre 2005 à 13:51 (CEST)

Toutes les informations de Micronoyau et Noyau monolithique se trouvent déjà dans Noyau (informatique), sauf les exemples que j'ai importés. Il faut simplement transformer les 2 premiers en redirect vers le troisième. Seul problème : Micronoyau est écrit Micro-noyau dans l'article Noyau (informatique), je vais renommer Micronoyau après la fusion. jerome66 18 octobre 2005 à 11:55 (CEST)

Micronoyau est déjà un redirect de Micro-noyau, je ne vais rien renommer dutout. jerome66 18 octobre 2005 à 11:59 (CEST)

Quelle est la politique de Wikipedia concernant ce genre de situations : on a un long article Noyau (informatique) (après l'ajout des schémas ce sera encore plus à rallonge ...) et dedans suffisamment de matière pour faire des parties indépendantes Micronoyau et Noyau monolithique. Pourquoi la fusion a t'elle été demandée ? Quelles considérations rentrent en ligne de compte dans ces choix ? Cedric77 20 octobre 2005 à 14:24 (CEST)

[modifier] Schémas

Pour éclaircir les différences entre le concept de noyau monolithique et celui de micro-noyau, et si possible d'autres notions relatives aux noyaux, nous pourrions utiliser des schémas. Voila ce que cela pourrait donner :

• pour un noyau monolithique, version assez détaillé :

http://cartonum1.free.fr/wikipedia/Noyau_design_monolithique.png

"Représentation schématique d'un noyau monolithique : le noyau inclus la plupart des services. Les programmes utilisateurs ou les bibliothèques qu'ils utilisent font des appels système pour utiliser les fonctionnalités du noyau."

• pour un mirco-noyau, version très schématique inspirée de ce qu'utilise la wikipedia anglophone :

http://cartonum1.free.fr/wikipedia/Noyau_informatique_design_micro-noyau.png

"Représentation schématique d'un système d'exploitation basé sur un micro-noyau. Les micro-noyaux sont accompagnés d'une collection de serveurs pour fournir des fonctionnalités équivalentes aux noyaux monolithiques. Ils communiquent entre eux, avec le noyau ou avec les processus utilisateurs via les IPC. Les IPC qui encapsulent des appels systèmes sont en rouge. Dans l'idéal seuls les serveurs ont besoin d'y faire appel."

• toujours pour un micro-noyau mais avec plus de détails (trop ?) :

http://cartonum1.free.fr/wikipedia/Exemple_design_micro-noyau.png

"Design d'exemple pour un micro-noyau. Chaque double flèche représente un appel système effectué par l'un des serveurs. Il est composé de deux changements de contexte et d'espace d'adressage (1 flèche = 1 changement de contexte) : un premier pour traiter la requête dans le micro-noyau et un second pour redonner la main au serveur appelant. Comme on peut le voir les drivers sont implémentés au choix en espace noyau ou utilisateur, selon la politique "d'externalisation" que l'on s'est fixée."

Je pense insérer le premier (en simplifiant peut être la partie noyau) et le deuxième dans l'article. Pour l'instant le troisième me semble trop détaillé, mais il aide bien à comprendre ... Qu'en pensez vous ? Cedric77 1 novembre 2005 à 08:11 (CET)

c'est une bonne chose :) un peu fouilli, qques problèmes de taille d'ajustement, d'homogénéité, mais franchement je trouve ça un bon départ. Aurélien 4 novembre 2005 à 22:55 (CET)

Effectivement l'homogénéité n'y est pas. Qu'est ce qui semble le mieux pour cet article ? Un schéma très simplificateur comme le second (sur le modèle de l'article de la wikipedia anglophone), un schéma qui essaye de synthétiser plus d'information sur les noyaux et les fonctions qu'ils remplissent comme le premier et le troisième ? Bien sur les noms utilisés comme le driver IDE ou le serveur ext3 ont pour but de montrer des exemples et ne sont pas du tout représentatif de toutes les fonctionnalités des noyaux et micro-noyaux, mais peut être qu'ils permettront de mieux faire comprendre les concepts. Par ailleurs il y a des légendes pour chacune de ces images, je viens de les rajouter. Aurélien, que veux tu dire par taille d'ajustement ? Cedric77 5 novembre 2005 à 18:59 (CET)

Mentionner IDE ou ext2/ext3 peut être tentant mais les lecteurs de l'article ne devraient pas avoir à connaître ces termes pour le comprendre. Pourquoi ne pas parler de "contrôleur de disque" et de "pilote de système de fichier" (même si c'est plus long et qu'il faudrait trouver un racourci ou un arrangement particulier pour le faire tenir dans ton dessin) ? Je suis bien d'accord qu'un échantillon de tout ce qu'offre un noyau est bien suffisant. Il faut essayer de faire simple "mais pas trop" ;-). Pour le dernier point, je voulais parler de l'échelle des dessins, qui semble variable (taille des boîtes et des polices de caractères n'est pas uniforme, mais c'est peut-être un effet de thumbnail de wikipedia). Aurélien 25 novembre 2005 à 23:54 (CET)

J'ai une forte préférence pour le 1er et le 3ième, car il faut que les lecteurs puissent retrouver les informations relatives au texte qu'ils ont lu dans les deux cas, voir que le but est d'offir les même services et appréhender les differences structurelles entre les diverses technologies. Je pense qu'il faudrait marquer plus le rôle de la communication dans le schéma micro-noyau, son rôle et son impact sont discutés dans l'article, il faut que ça paraisse sur le schéma. v_atekor

J'abonde. Aurélien 25 novembre 2005 à 23:54 (CET)

Merci pour vos commentaires, je vais faire de nouvelles versions. Cedric77 12 décembre 2005 à 23:30 (CET)

Voila un exemple de nouvelle version possible pour un micro-noyau : *http://cartonum1.free.fr/wikipedia/micro-noyau_couleur.jpg et pour un noyau monolithique : *http://cartonum1.free.fr/wikipedia/noyau-monolithique_couleur.jpg

Par manque de temps, je ne vais pas pouvoir reprendre ou faire évoluer ces schémas dans les mois qui viennent. Si quelqu'un pense pouvoir en tirer quelque chose, les fichiers OpenOffice Impress (.sxi) sont disponibles dans le même répertoire (http://cartonum1.free.fr/wikipedia/). Cedric77 7 janvier 2006 à 02:42 (CET)

Ok ils sont très bien fait

j'en ai préparé également, mais je ne sais pas comment les mettre en ligne :/ Les miens recouvrent :

• Ordonanceur
• Gestionnaire de mémoire
• Micro noyaux
• noyaux monolithiques

Mais tes schémas d'architecture de noyaux sont mieux fait, je pense qu'il est préférable de les utiliser. Remarque secondaire : les IPC passent aussi par le noyau en monolithique.

Je rajouterai le schéma sur l'ordonancement et celui sur le gestionnaire de mémoire. v_atekor

Voilà, j'ai un peu retouché tes schémas, et j'ai ajouté pour la mémoire et l'ordonnanceur.

Je pense que l'article est assez correct, pour rester minimaliste ;) J'ai aussi complété pour les méta noyaux. L'article me semble bien plus (bien trop?) complet que dans les autres langues (surtout anglais) Avant de proposer l'article dans les articles de qualité : Questions à bâton rompus dont je n'ai pas la réponse Est-ce qu'il faut une section :

1. histoire / historique
2. Personnages/ Laboratoires important
3. Noyaux / CPU

Merci de t'être occupé des schémas v_atekor, c'est super comme ça. Exact pour ta remarque sur les IPC du schéma du noyau monolithique, c'est un oubli de ma part. Au passage peut être qu'en colorant cette fonctionnalité en rouge comme les IPC cela permettrait de mieux comprendre que les IPC passent par le noyau mais qu'on ne représente pas cette communication afin de ne pas alourdir le schéma.

Concernant cette page de discussion, j'ai retiré les schémas initiaux placés au début de cette section, ils ralentissaient le chargement de la page. Les images sont toujours accessibles via les liens qui les remplacent. Cedric77 17 janvier 2006 à 01:22 (CET)

[modifier] Structure globale

Un point important du point de vue de la compréhension globale, l'article commence par dire que "Tous les systèmes d'exploitation ne sont pas construits autour de la notion de noyau." Or, à ce niveau, le lecteur n'est pas censé savoir ce qu'est un noyau, il faudrait donc déplacer ces paragraphe vers la suite, et commencer directement par "Un noyau informatique est ....", sinon ce ne sera compréhensible qu'aux personnes connaissant déjà les noyaux, ce qui est aberrant. v_atekor

L'article commence par "en informatique le noyau d'un système d'exploitation est le logiciel qui assure ...", donne une liste, et continue par "si tous les systèmes d'exploitation ne sont pas construits autour de la notion de noyau...", puis reprend sur ce qu'est un noyau, etc. Aurélien 26 novembre 2005 à 00:02 (CET)

Je sais c'est moi qui l'ai modifié :)v_atekor

[modifier] Mémoire

Les gestionnaires de mémoire évolués sont "relativement" récent. Un gestionnaire de mémoire avec l'ensemble des propriétés mentionnées n'est pas possible, par exemple avec d'ancien CPU, sur Unix 1. La suppression de DOS pour la gestion de mémoire était justifiée, mais pas forcément le remaniement de tout le paragraphe (OS9, Unix < system 4 ... ). Les gestionnaires de mémoire "évolués" se basent sur la mmu, qui est apparue pour le grand public avec l'i386...

Le système de mémoire virtuel date des années 60. Ce n'est pas vraiment ce que j'appelle récent. Que cela soit apparu récemment dans le monde grand public ne le rend pas récent pour autant. (Bruno Jargot 26 juillet 2006 à 21:12 (CEST))

En effet. J'essaie de corriger ça. v_atekor 16 octobre 2006 à 10:33 (CEST)

[modifier] introduction revue

Mieux ?

[modifier] Windows - noyau monolithiques

Au cours de la conférence Intitulé "Fonctionnement interne de Windows Vista" de 12h45, lors des "journées Microsoft de la sécurité" du 3 mars 2006 au CNIT ; Bernard Ourghanlian (Directeur de la Sécurité et des Technologies de Microsoft) précisa que "contrairement a une idée reçue, Windows utilise un noyau monolithique et non pas un micro-noyau". Quelqu'un peut-il confirmer ? -- Jeanot 5 mars 2006 à 19:18 (CET)

Le hic c'est que :

• C'est la publicité qui avait été faite autours de Windows NT (3,4, 2k)
• Le code est fermé.

Mais si il y a une documentation officielle, je modifie tout ça. v_atekor 20 mars 2006 à 11:45 (CET)

[modifier] L'existence d'un noyau présuppose une partition virtuelle de la mémoire vive physique en deux régions disjointe

Je demande une référence sur cette affirmation qui me paraît douteuse. C'est peut-être un point de vue, peut-être même respectable, mais c'est actuellement présenté comme une vérité générale, ce dont je doute. Simple exemple, le noyau Linux supporte l'architecture m68k sans MMU. Marc Mongenet 24 juin 2006 à 20:56 (CEST)

Ca n'a rien à voir avec la présence d'une mmu, mais directement avec la définition de noyau, plus précisément avec l'abstraction de la mémoire pour les applications et les contraintes liées à l'ordonnancement préemptif. Ce qui n'est pas forcément obtenu via une mmu!!!

Linux sur des procs sans mmu, les premières versions d'Unix et Multics possèdent un espace noyau et un espace user bien qu 'il n'y ait pas de mmu et la mémoire est abstraite au niveau applicatif

Que la mmu apporte une abstraction et des mécanismes plus puissants c'est entendu, mais on peut faire des choses sans - Au minimum alouer et désalouer de la mémoire sans que les applications se marchent les unes sur les autres ... lorsqu'elles ne font que des accés autorisés évidement ;)

Si tu lis le reste de l'article, la séparation espace utilisateur/noyau est un des casse tête fondamental des noyaux (sur TOUTES les architectures matérielle et sur tous les systèmes basés sur des noyaux)

Références : Andrew Tanenbaum, Systèmes d'exploitation, [Pearson Education France, 2003, 2e éd. (ISBN 2-7440-7002-5)] est déjà cité dans la biblio. ;

Et quand on modifie un article on évite d'introduire des approximations. Les noyaux ne sont pas présents sur tous les systèmes d'exploitations mais seulement sur certains. v_atekor 27 juin 2006 à 10:34 (CEST)

Merci beaucoup pour le suivi, mais j'ai encore beaucoup de peine avec le vocabulaire de cet article, et des articles sur les systèmes d'exploitation en général. Mais je poserai les questions dans cette page de discussion, promis. :) Marc Mongenet 27 juin 2006 à 14:33 (CEST)

Pas de soucis - Pour le vocabulaire, il est francisé (procédure qualité wikipédia... ) v_atekor 27 juin 2006 à 15:48 (CEST)

[modifier] Mémoire

tout processus croit manipuler une mémoire qui ... peut être indéfiniment étendue
Ça me semble faux.
Qui peut être étendue jusqu'à une certaine fraction des capacités d'adressage du processeur me semble correct.
Marc Mongenet 27 juin 2006 à 14:39 (CEST)

Techniquement oui, tu as raison. C'est un problème du gestionnaire de mémoire de s'occuper des limites physiques. Le point important ici est que "pour l'application" il est (virtuellement) possible d'avoir autant de mémoire qu'elle veut - elle n'a pas en s'en occuper. Le système lui refusera la mémoire si il y a lieu. Peut être une reformulation ? j'ai rajouté une note.v_atekor 27 juin 2006 à 15:06 (CEST)

Le rôle d'un OS est de fournir à chaque processus l'illusion qu'il est seule sur une machine aussi bien équipée que possible, mais pas qu'il est sur une machine infinie. Enfin c'est le point de vue qu'on m'a enseigné, mais il y a un peu longtemps pour que je retrouve les sources, arg. :-) Marc Mongenet 27 juin 2006 à 16:21 (CEST)

Mais ca revient au même. Le développeur de l'application n'a pas à se poser la question de la limite effective de la machine. Pour lui, la machine est idéalement puissante ce qui revient au même. Le système garantira de toute façon qu'il reste dans les bornes physiques, et retournera des erreurs si ce n'est pas le cas.v_atekor 27 juin 2006 à 16:36 (CEST)

Non, avoir l'illusion de disposer de toutes les capacités d'une machine réelle ne revient pas à avoir l'illusion de disposer d'une machine infinie. Si la machine est infinie, les allocations mémoire réussissent toujours. Sinon pas. Et c'est LA différence qui compte. Ensuite ce n'est pas le système qui garantit qu'on reste dans les bornes physique (disons 4 Go pour une machine 32 bits). C'est le fait que l'application manipule des données de 32 bits et que les appels systèmes prennent des paramètres 32 bits et qu'en définitive, il n'y a pas moyen d'exprimer une allocation de plus de 4 Go sur une machine 32 bits. Marc Mongenet 27 juin 2006 à 17:06 (CEST)

La virtualisation de la mémoire facilite les changements de contextes dans le cadre d'un système multi-tâches
La virtualisation ne complique-t-elle pas au contraire les changements de contexte ? Il faut reprogrammer le MMU, flusher le TLD, etc. Bref, il y a plus de choses à faire, non ? Marc Mongenet 27 juin 2006 à 14:46 (CEST)

la virtualisation de la mémoire implique la pagination de la mémoire ce qui simplifie immensément le travail de localisation de la mémoire et de sauvegarde des contextes. Ensuite, que la mémoire soit virtualisée ou pas, un changement de contexte est toujours une opération complexe et très couteuse. v_atekor 27 juin 2006 à 15:06 (CEST)

J'en crois pas un mot, je veux une référence. :-) Marc Mongenet 27 juin 2006 à 16:17 (CEST)

Voir les bouqins de Tanenbaum, c'est la référence en la matière. Sinon, pose toi la question de comment tu aloues la mémoire à des processus et que suppose un changement de contexte... v_atekor 27 juin 2006 à 16:32 (CEST)

Oui, ce bouquin manque à ma bibliothèque, beuh. Mais ma remarque porte sur les changements de contexte, pas l'allocation de mémoire ni la relocation. Et je maintiens qu'un changement de contexte dans un OS sans virtualisation (disons le bon vieil AmigaOS) a toutes les raisons d'être plus simple que dans un OS avec virtualisation. Marc Mongenet 27 juin 2006 à 16:57 (CEST)

Heu, là on ne parle pas du même niveau de virtualisation. La seule chose dont je parle par "virtualiser" est que l'application demande au système de lui alouer la mémoire, et le système le fait sous forme de pages mémoires (Amiga aussi). Pas forcément de swap, ni de virtualisation façon xen... Il peut y avoir des couches en plus, mais le minimum est que le système masque la mémoire à l'appli. v_atekor 27 juin 2006 à 17:08 (CEST)

Il n'y a pas de notion de page dans le bon vieil AmigaOS. (Note : il y a une dizaine d'années, j'ai participé au developpement d'une machine virtuelle sur 68030. Mes connaissances sont donc un peu rouillées et dépassées, mais en principe je ne confond quand même pas trop les notions :-) J'ai tout de même un peu de peine avec le vocabulaire, surtout francisé, comme tu le relèves justement plus haut. :) Marc Mongenet 27 juin 2006 à 17:11 (CEST)

Si il n'utilise pas de pages mémoire en interne, il est très probable que Amiga OS n'utilise tout simplement pas la notion de noyau, ce qui était fréquent à l'époque (DOS). Maintenant, il est clair qu'il existe plusieurs solutions au même problème. Si tu as des liens sur le code de AmigaOS, je suis preneur pour voir ce qu'il a dans le ventre, car c'est surprenant. v_atekor 27 juin 2006 à 17:17 (CEST). Amiga OS est basé sur un noyau et utilise une virtualisation de la mémoire : [1] (Voir la section "memory management") et comme c'est un unix, je pense qu'il le fait en se basant sur des pages mémoire v_atekor 27 juin 2006 à 17:22 (CEST)

Note : Je parle de l'AmigaOS du temps de Commodore International, pas des évolutions postérieures (et marginales), que je n'ai pas suivies. L'AmigaOS n'était pas un Unix. Il y a eu un modèle d'Amiga (très peu) vendu avec Unix, l'Amiga 3000UX. Pour la gestion de la mémoire (je ne sais pas pourquoi tu tiens à ce sujet, mais bon), il y avait simplement une liste chaînée de zones libres. Évidemment, la mémoire se fragmentait avec le temps, faute de virtualisation. Pour la relocation, c'était fait en modifiant les pointeurs dans les binaires entre le chargement et l'exécution. Marc Mongenet 27 juin 2006 à 17:56 (CEST)

ok. Je note - je ne connais pas bien amiga, je te fais confiance... ainsi qu'à Google ;)

Peut-être l'AmigaOS n'avait-il pas de noyau, au sens que cet article voudrait donné (mais que je ne comprend pas). Marc Mongenet 27 juin 2006 à 17:59 (CEST)

En fait la notion de noyau c'est fournir une couche d'abstraction (plus ou moins élaborée) commune pour les IO/sheduller/mémoire, et qui est inactif lorsque la machine est inactive. Ces 3 composants sont étroitement liés, et comme le précise l'article, c'est une question de compromis viesse/sécurité/stabilité. v_atekor 27 juin 2006 à 18:34 (CEST)

[modifier] Exécution dans le noyau

Les flots d'exécution dans le noyau sont des continuations des flots d'exécution des processus mis en pause lorsqu'ils effectuent des appels systèmes.
C'est vrai pour certains flots, ceux des appels système. Mais pas pour les nombreux flots issus d'une interruption matérielle. Marc Mongenet 27 juin 2006 à 14:49 (CEST)

Les interruption matérielle sont en général associés à un appel système. Tu as généralement un appel système initié et suspendu pendant un long moment en attendant l'it. lorsqu'elle arrive, l'appel système retourne le contenu de l'It. Sur unix, c'est généralement un read pour des it. C'est shématique, il y a quelques (quasi) exceptions, comme certains signaux (unix sys v) initiés directement par le noyau (kill sur sig fault...) mais il est difficile d'être totalement exhausitif sans se lancer dans une étude de cas. v_atekor 27 juin 2006 à 15:06 (CEST)

C'est un point de vue, il faudrait une source pour me convaincre qu'il est généralisé. Je le trouve criticable conceptuellement aussi bien que statistiquement. Conceptuellement, ça donne la mauvaise impression que tout est synchrone.

Arf, je comprends ce que tu veux dire, mais le problème est alors d'expliquer les liens étroits entre genstionnaire d'It, scheduller et spin qui brisent cette image de "synchronisme" d'un côté ... et les appels systèmes de l'autre. Fondamentalement ça revient à expliquer pourquoi on utilise le concept de noyaux, ce que je voulais éviter autant que posssible (complexe). Par contre il n'y a pas d'"exécution" dans le noyau - quelque soit le noyau. On peut rajouter un paragraphe sur ça? Si tu te lance je te suis - fais les propositions sur la page de discussion en attendant. Le hic est qu'il y a plusieurs technos là aussi... v_atekor

Pour prendre un exemple très important d'asynchronisme, je citerai les interruptions de l'horloge, qui servent notamment au multi-tâches préemptif (mais aussi à faire des stats, des algos LRU et tout ce qu'on veut). Et statistiquement, selon la charge, la plupart des interruptions peuvent être hors flot, soit qu'il n'y a pas d'appel système (calcul intensif), soit une majorité d'interruptions causées par le swapping et autres services hors flot d'exécution fournis par le système en utilisant des périphériques. Marc Mongenet 27 juin 2006 à 16:14 (CEST)

Ok pour l'exemple.

[modifier] gestion de mémoire et cache

Je ne peux pas croire que quelqu'un de compétent ait pu mélanger la gestion mémoire faite par le noyau et le MMU, et les mémoires caches. Additionné à tous les autres trucs peu compréhensibles que contient cet article, il y a de quoi retirer le label de qualité, et même pratiquement de le remplacer par le bandeau recyclage. Marc Mongenet 27 juin 2006 à 18:48 (CEST)

Il n'y a pas de mélange??? Je ne comprends pas du tout pourquoi cette focalisation sur la mmu. Le gestionnaire de mémoire gère les différents emplacements mémmoires. La mmu ne joue qu'un rôle "annexe". Elle apporte des fonctions plus avancée, mais ça n'empêche pas son rôle de gestionnaire de différents niveaux de mémoire par le gestionnaire de mémoire v_atekor 28 juin 2006 à 11:58 (CEST)

[modifier] Question de logique

Le coût se compte en milliers ou dizaines de milliers d'instructions primitives, générant à la fois une charge et des délais d'exécution supplémentaires. Pour ces raisons, les fonctions qui sont utilisées de manière intense sont déplacées dans l'espace noyau.

N'y aurait-il pas une erreur ? Je comprends qu'il faudrait éviter ces appels systèmes ou faire en sorte qu'ils soient gérés autrement. Si on fait exprès de les mettre dans le noyau pour prendre plus de temps, c'est du vice. La Cigale 12 septembre 2006 à 16:56 (CEST)

Non, en fait ce qui se passe, c'est que on s'arrange pour qu'un seul appel système puisse faire "plus de chose", on implémente dans le noyau des appels de haut niveau. Par exemple, un appel sera fait pour un "Open" sur NFS, mais l'open sera traité par des centaines d'opérations DANS le noyau : ouverture de socket, lecture, écritures, ...

Toutes ces opérations, que ce soit le "open" ou l'ouverture de socket, lecture, écriture peuvent être faites dans le noyau ou en dehors du noyau. Mais suivant comment on conçoit le noyau, on peut choisir de faire ces opérations "élémentaires" hors du noyau ou dans le noyau. Le "élémentaire" doit se comprendre en fonction du contexte des tâches à effectuer.

Autre exemple avec un accès disque, une création de fichier. On peut faire toutes les operations d'un driver de système de fichier ou de disque dans le noyau ou hors du noyau. Hors du noyau ce sera fait avec des appels à la fonction ioctl (Unix). Si on choisi de travailler en dehors du noyau, il l'opération open n'est plus un appel système et est traitée dans le monde utilisateur. Par contre, elle fera invariablement appel à des opérations de plus bas niveau. Ce sera le cas pour toutes les opérations qui sont de la responsabilité du noyau, dont les IO. Le simple open lira des structures sur le disque (donc lecture de secteurs sur disques, et décalages ...). A chaque opération, il fera appel à un appel système et en génèrera des quantités. Du coup, au lieu d'avoir un seul appel système "open" qui ne génère qu'un changement de contexte, on a des dixaines d'appels systèmes : un pour chaque ioctl.

Je ne sais pas si je suis plus clair ? v_atekor 16 octobre 2006 à 10:28 (CEST)

Comme ça c'est beaucoup plus clair. Peut-être que la dernière phrase ("A chaque opération...") aurait sa place dans l'article ? La Cigale 16 octobre 2006 à 16:08 (CEST)

Oui, je vais essayer d'expliciter ça. v_atekor 17 octobre 2006 à 10:44 (CEST)

N'y aurait-il pas une erreur ?

Manifestement. Au lieu de:

Pour ces raisons, les fonctions qui sont utilisées de manière intense sont déplacées dans l'espace noyau.

lire

Pour cette raison, les fonctions qui utilisent de manière intensive des appels système sont déplacées dans l'espace noyau.

(Je corrige.) Ceci dit, même pour ça je voudrais quelques exemples. Je crois que je n'en connais aucun.

C'est le cas des drivers, des systèmes de fichiers, des piles réseaux. Tu peux les coder depuis le userspace, en ne passant la main au noyau que pour réaliser les IO, avec des ioctl; mais tu peux écrire un pilote directement dans le noyau. Les deux existes, mais on préférera un appel synthétique à un read avec un driver en espace noyau, que de faire une quantité d'appel ioctl en userspace : la multiplication des appels systèmes a un cout trop important v_atekor (d) 30 novembre 2007 à 11:10 (CET)

Quand à cette affirmation :

Les entrées/sorties font également l'objet d'un traitement par l'ordonnanceur.

peut-on m'expliquer (avec un exemple) ce qu'elle signifie ?

En clair : les interruption sont des évènements (presque) comme les autres. Elles sont empilés et ordonnancées comme les tâches. Il y a parfois un ordonanceur spécialisé pour les interruptions (linux). Je ne sais pas si je suis plus clair, peut être il faudrait il un sous § dédié. v_atekor (d) 30 novembre 2007 à 11:10 (CET)

--Wcorrector (d) 30 novembre 2007 à 07:27 (CET)

[modifier] Gestion optimiste et non optimisée de la mémoire

En cas de pénurie de mémoire, le gestionnaire de mémoire peut allouer le même emplacement à plusieurs processus concurrents. Ce faisant il fait le "pari" que la ressource ne sera pas utilisée simultanément par les deux processus. Il s'agit d'une vision optimiste des choses puisque, si le pari réussi il n'y a pas de conflits et la mémoire disponible est alors suffisante pour tout le monde (optimisme). Cependant il arrive que les deux processus réclament simultanément ce même espace mémoire. Dans ce cas le gestionnaire de mémoire détruit un des processus concurrents. Alors même que les processus ont été autorisés à utiliser de la mémoire, ils ont été tués par le gestionnaire de mémoire - signal OOM (Out Of Memory ). Sous linux, le processus choisi est celui utilisant le plus de mémoire (L'hypothèse est que ce programme est peut être victime d'une fuite de mémoire, ce qui peut être quelques fois vrai.)

La vision pessimiste des choses serait de refuser d'allouer la mémoire à plusieurs processus en cas de pénurie. Le processus qui tente de faire une allocation pendant une pénurie se voir retourner une erreur lors de l'allocation. Fin de non recevoir. Cette vision est pessimiste car elle fait le pari que toute la mémoire sera effectivement utilisée pendant la pénurie, et donc que l'on est réellement en situation de manque. L'avantage est que l'on ne risque pas de subir les foudres du gestionnaire de mémoire. v_atekor 4 juillet 2007 à 16:32 (CEST)

[modifier] Drivers en espace utilisateur dans les noyaux monolithiques

L'article ne décrit pas la possibilité de faire des drivers en userland pour les noyaux monolithiques. Par exemple sous linux : FUSE pour faire des pilote de système de fichier, les couches hautes de l'USB, UIO : user space drivers. Article sous copyright : http://lwn.net/Articles/232575/

Il me semble que le sujet à au contraire été abondamment traité.Dans la première partie, qui est généraliste et commune à toutes les architectures de noyau, les pilotes sont décrits comme ne faisant pas necessairement partie du noyau. Voici ce qui est écrit dans la section fonctions généralements fournies par un noyau

En dehors des fonctionnalités de base, l'ensemble des fonctions des points suivants (y compris les pilotes matériels, les fonctions réseaux et 
systèmes de fichiers ou les services) ne sont pas nécessairement fournies par un noyau de système d'exploitation. Ces fonctions du système 
d'exploitation peuvent être implantées tant dans l'espace utilisateur que dans le noyau lui-même. Leur implantation dans le noyau est faite dans 
l'unique but d'augmenter les performances. En effet, suivant la conception du noyau, la même fonction appelée depuis l'espace utilisateur ou 
l'espace noyau a un coût temporel notoirement différent. Si cet appel de fonction est fréquent, il peut s'avérer utile d'intégrer ces fonctions au  
noyau pour augmenter les performances.

lire également la section générale pilotes (commune à toutes les architectures) :

Les pilotes sont des petits logiciels légers dédiés à un matériel donné qui permettent de faire communiquer ce matériel. En raison du très grand 
nombre d'accès à certains matériels (disques durs par exemple), certains pilotes sont très sollicités. Ils sont généralement inclus dans l'espace 
noyau et communiquent avec l'espace utilisateur via les appels système.
En effet, comme cela a été vu dans le précédent paragraphe, un appel système est coûteux : il nécessite au moins 2 changements de contextes. Afin de
réduire le nombre des appels système effectués pour accéder à un périphérique, les interactions basiques avec le périphérique sont faites dans 
l'espace  noyau. Les programmes utilisent ces périphériques au travers d'un nombre restreint d'appels système.
Cependant, indépendamment de l'architecture, de nombreux périphériques lents (certains appareils photographiques numériques, outils sur liaison 
série, etc.) sont/peuvent être pilotés depuis l'espace utilisateur, le noyau intervenant au minimum.

Le fait que pour des raisons de performances on préfère souvent utiliser des pilotes en espace noyau suppose qu'on ne le fasse pas tout le temps. Les pilotes sur port série, USB sont cités, on pourrait rajouter les systèmes de fichiers, les services, les piles réseau ... Tout ce qui n'est pas directement lié à la gestion de la mémoire/ordonancement/IO v_atekor 14 septembre 2007 à 09:46 (CEST)

[modifier] Maintenance des noyaux monolitiques : FUD ?

Dans 'Noyaux monolithiques non modulaires' :

Cependant, au fur et à mesure de leurs développements, les codes des noyaux monolithiques ont augmenté en taille et il s'est avéré difficile de les maintenir.

Les multiples dépendances créées entre les différentes fonctions du noyau empêchaient la relecture et la compréhension du code. L'évolution du code s'est faite en parallèle à l'évolution du matériel, et des problèmes de portage ont alors été mis en évidence sur les noyaux monolithiques.

Tout ça sent très fort le FUD.

Non, ce sont les arguments qui ont été avancés pour justifier les études sur les micro-noyaux. Certains problèmes ont été résolus par une meilleure organisation du code, et d'autre n'ont toujours pas été résolus, que ce soit via des noyaux modulaires ou des micronoyaux.

HURD ou celui de Windows XP utilisent des micro-noyaux censés faciliter le portage mais n'existent que pour quelques architectures

Ça c'est de l'anecdote. On peut supposer que le portage de Windows XP dépend de questions de management dans lequel le marketing a plus d'importance que la facilité technique (je veux dire que MS a assez de ressources pour faire un travail de dingue consécutif à des choix techniques désastreux).

Quand à HURD, peut-être n'a t-il jamais trouvé son public, sa vitesse de croisières, des développeurs, des architectures supportées, des utilisateurs, etc. parce que trop lent à démarrer et linux a pris le créneau (je n'en sais rien, j'invente — mais c'est ce qu'un défenseur de HURD pourrait dire).

Hurd à subit plusieurs refontes (changements de micronoyaux) qui l'ont largué d'un point de vue fonctionnel et qui laisse un code très immature par rapport à un linux. Mais quelques soient les raisons, politiques ou techniques, les noyaux modulaires sont effectivement plus portés que les autres. Ce qui tend surtout à prouver que la technologie du noyau est indépendante de la facilité de portage, comme c'est indiqué dans le texte. v_atekor (d) 30 novembre 2007 à 10:27 (CET)

D'un point de vue théorique, le grand nombre de lignes de code exécutées en mode noyau engendre des problèmes de portabilité.

En quoi ?

En facilité de portage. L'argument qui était avancé est que le travail étant plus délicat en espace noyau, moins tu as de code en espace noyau, plus la portabilité est simplifiée. Plus tu réduits les adhérences au matériel au minimum il est plus simple de changer de matériel. On est bien d'accord l'argument qui servait surtout à financer des recherches sur les micronoyaux est tombé, et la pratique contredit l'argument théorique. C'est bien dit dans l'article. v_atekor (d) 30 novembre 2007 à 10:27 (CET)

--Wcorrector (d) 30 novembre 2007 à 08:36 (CET)

[modifier] Changement de mode

C'est le contexte qui est la cause des ralentissement. Le changement de mode d'exécution n'a pas d'influence en performance, sinon à cause du changemetn de contextev_atekor (d) 30 novembre 2007 à 10:36 (CET)

La nécessité du changement de contexte lors d'un appel système tien à la non réentrance du code noyau. Si deux appels systèmes sont effectués, et qu'ils influent l'un sur l'autre (sections critiques entre autres) puisque le code ne peut être duplique, il devient alors nécessaire de maintenir un état du noyau qui tient en compte son état interne, et reflète donc les influences d'un appel système sur l'autre. Enfin, pour il est nécesaire pour effectuer un appel système de sauvegarder l'état d'autres sous systèmes tels que l'ordonanceur v_atekor 1 décembre 2007 à 16:57 (CET)

[modifier] Proposition de sélection de cet article pour Portail:Informatique

Cet article est proposé pour faire partie de la sélection Wikipédia:Sélection/Informatique. Cette page permet d'afficher aléatoirement un article parmis la sélection sur Portail:Informatique. Les articles sélectionnés représentent la vitrine du projet.

Vous êtes invités à vous exprimer sur la page suivante : Wikipédia:Sélection/Informatique/Noyau de système d'exploitation. Toutes les remarques d'amélioration sont les bienvenues, mais notez que puisque c'est un vote interne au projet, seuls les votes des participants déjà inscrits sur le projet informatique seront pris en compte. --T (d) 11 décembre 2007 à 13:27 (CET)