Discussion:Noyau de système d'exploitation

message: 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. François Trazzi | ↹  22 oct 2004 à 21:17 (CEST)
thread_title:  Confusion 

message: 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)
thread_title:  Traduction 

message: 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)
thread_title:  Modifications récentes sur les micro-noyaux 

message: 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)
thread_title:  Modifications  sur les micro-noyaux 

message: 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)
replies: text: 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)
replies: text: Micronoyau est déjà un redirect de Micro-noyau, je ne vais rien renommer dutout. jerome66 18 octobre 2005 à 11:59 (CEST)
thread_title:  Fusion 

message: 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)
replies: text: En effet. J'essaie de corriger ça. v_atekor 16 octobre 2006 à 10:33 (CEST)
thread_title:  Mémoire 

message: 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)
replies: text: 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)
thread_title:  gestion de mémoire et cache 

message: 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)
thread_title:  Gestion ''optimiste'' et non ''optimisée'' de la mémoire 

message: 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)
thread_title:  Drivers en espace utilisateur dans les noyaux monolithiques 

message: 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)
thread_title: Changement de mode

message: Dans le paragraphe "Systèmes à noyaux restreints", je lis:
"Ces systèmes sont généralement adaptés à des applications très ciblées mais posent des problèmes variés (de sécurité avec MS-DOS, de performances avec HURD ou QNX). La plupart d’entre eux sont actuellement inadaptés pour une utilisation généraliste, dans des serveurs ou ordinateurs personnels."
En ce qui concerne QNX je me demande si vous avez travaillé un jour avec ce système ou l'avez seulement vu fonctionner... Les performances de QNX étant nettement supérieures à ce qu'on pouvait atteindre avec UNIX, et tellement insecure que c'était utilmisé pour gérer des betises peu importantes comme les chaines Boing ou la fabrication chez Kodak du temps de l'argentique... En ce qui concerne par exemple l'utilisation plus prosaïque en serveur grand public, il a été utilisé justement pour ses qualités de rapidité et fiabilité, sur des appli grand public. Enfin, en ce qui concerne les ordinateurs personnels, il est exactement aussi adapté que linux son contemporain. Simplement l'un est Open Source et accessible à tous, alors que l'autre avait choisi le créneau industriel ou télécom parceque c'était plus rentable. Mais ce n'est pas un problème technique. J'utilise l'imparfait parceque cela fait déja un certain temps que je n'ai pas réellement travaillé avec QNX, mais il continue toujours sa course en tête depuis 30 ans et encore cette année (2009) a été récompensé de nombreux prix. Pas mal, pour un système posant des problèmes de performances...
Wikipedia est une encyclopédie, donc une somme de savoir et non un lieu où faire passer les idées partisanes.
--Brazz (d) 11 novembre 2009 à 13:06 (CET)
thread_title:  QNX 

message: 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)
thread_title:  Proposition de sélection de cet article pour [[Portail:Informatique]] 

message: Deux références pour un AdQ de cette taille est inacceptable. Il n'est même pas BA dans son état.
: Trop de choses obscures pour moi qui suit novice, dans cet article. Un article de qualité, pour moi, est un article où on comprendre tout avec peu de connaissances sur le sujet. Et c'est assez rare sur Wikipédia malheureusement!
: 
:: N.B. : pense à signer et, si possible, te faire un compte, c'est plus pratique.
:: Tout comprendre avec peu de connaissance sur le sujet n'est pas le propre d'un bon article, mais d'un COURS. Et ça, tu trouveras sur Wikibooks ou Wikiversité, mais pas sur WP.
:: Un BA peut parfaitement être totalement impossible à appréhender pour un novice du sujet, mais c'est justement à ça que servent les hyperliens sur les articles conjoints. En cliquant suffisamment, tu devrais même arriver à la page sur l'apprentissage de la lecture.
:: Mais certains sujets ne peuvent pas être approchés par des néophytes : il faut une certaine dose de vernis technique pour comprendre. Et ça ne remet pas en cause le statut de BA.
:: Ceci étant dit, cet article précis n'est effectivement pas un AqQ ou un BA, mais ce n'est pas lié au fait qu'un débutant n'y comprendra rien.
::  Mac LAK [ Discuter ] 17 juillet 2016 à 13:26 (CEST)
thread_title:  Trop peu de références