N'en jetez plus.....

Manu a dit:
Mettons une fois pour toute les choses au point Mac OS X N'EST PAS UNIX!!.
Il me semble que si (contrairement à Linux).
Mais je crois que c'est un sujet à débat pour geeks unixiens et qui n'aboutit nulle part dans la mesure où ce qui compte c'est de savoir si on peut compiler des trucs unix dessus et la réponse est oui, via le bon config.truc, comme pour tous les autres.

Par contre tu as tout à fait raison en disant que Darwin n'est pas OSX.

En effet ce qui fait OSX c'est Darwin bien sûr mais aussi Cocoa par exemple (qui n'est pas dans darwin) et tout ce qui en découle, l'architecture des Services par exemple, et tout un tas d'autres trucs qui font que mes applis Cocoa même sans interface graphique ne tourneront pas dans Darwin.


naas a dit:
article archi mega chié pour la vulgarisation de macosx du feu de dieu !
Ça existe déjà et je suis sûr d'en avoir lu de très bon (en anglais en tout cas) du temps des débuts.
Sors ton google et trouve nous ça ;)
 
  • J’aime
Réactions: naas
Naas, puisque tu le demandes, je vais faire une retrospective assez rapide. Dans les années 80, l'explosion de la micro apporte la puissance des ordinateurs dix à cent fois plus gros à un nouveau type d'ordinateur utilisable sur un bureau. Dans des universités et les centres de recherche, des projetsfusent . Notamment celui d'un chercheur de l'Université de Rochester qui se nomme Richard Rashid. A cette époque, le système le plus utilisé dans les universités est Unix. Une des variantes sera d'aiileurs développé à l'Université de Berkeley, c'est BSD. Le système Unix bien que très solide avait un gros inconvénient c'est que au fur et à mesure qu'on le peaufinait (ajout du support du réseau, etc), son noyau grossisait et donc pouvait poser des problèmes à la stabilité de l'OS et aux performances. D'où l'idée de 'dégraisser' celui-ci en le rendant plus petit et en y gardant que les fonctionalités dites vitales et en implémentant les autres fonctionalités (gestion de fichiers, etc) sous forme de serveurs. c'est la naissance des micro-noyau. Le projet Accent conduit par Richard Rashid s'inscrivait dans cette mouvance. Mais Rashid changea d'université et emmena son projet à l'université de Carnegie Melon. Là, il revit sa copie et forma une équipe pour continuer les travaux du projet Accent. c'est le projet qui donna naissance au micro-noyau Mach. Avi Tevanian faisait partie de l'équipe.
Pour plus de précisions, je vous invite à lire cet article

Comme vous le voyez, beaucoup de notions apportées par Mach (ports, thread, gestion de la mémoire virtuelle, support des architectures multi processeurs, etc) ont par la suite été incorporées dans les système Unix et d'autres (Windows NT).

Le gros reproche que l'on fait aux micro-noyaux c'est qu'en implémentant les fonctionalités OS sous forme de serveurs, cela pénalise les performances. d"autant que les échanges entre les serveurs et le micro-noyau se font par l'envoi de messages.
C'est pour cela qu'Apple au lieu d'utiliser Mach sous sa forme micro-noyau avec freeBSD comme serveur apportant les spécificités Unix, a plutôt décidé de créer un noyau simple incluant Mach, BSD, I/O kit pour la gestion des drivers, etc. les échanges à l'intérieur du noyau se faisant par appel direct de procédures. Mécanisme plus performant que l'emploi de messages.
Ce noyau Apple l'a mis en distribution libre sous licence sous le nom de Darwin.

Un noyau tout seul ne fait pas un système d'exploitation. Apple a donc dans un souci de modularité conçu son OS en couches en ajoutant au noyau, des différentes couches dont Aqua constitue la couche la plus haute et Darwin la plus basse.

TOUTES ces couches forment Mac OS X.

Pour info : Rashid bosse chez Microsoft, Avi Tevanian chez Apple (cela vous le saviez).

On peut utiliser Darwin comme noyau et se faire une distrib. Tout comme les distrib linux utilisent le même noyau mais l'OS ainsi constitué en ajoutant des apis différents et une interface (KDE ou autre) a un nom particulier (red hat, Mandrake, etc).

Quand je dis que Mac OS X n'est pas un Unix c'est que son noyau déjà n'est pas un noyau Unix traditionel. Mêm si celui-ci incorpore BSD. Tout le noyau de BSD n'est pas dans Mac OS X. certaines fonctionalités du noyau BSD sont apportées par Mach. Par souci de modernité, vu que FreeBSD évolue plus vite que Mach, certaines des fonctionalités de ce dernier sont dépassées par rapport à celles de FreeBSD. Dans un tel cas, Apple utilise la technique des poupées russes en enveloppant ( on dit wrapper en jargon geek) les fonctionalités de Mach par celles plus modernes et actuelles de freeBSD. c'est de cette façon par exemple que les threads de Mac OS X sont des threads Mach à 'coloration' FreeBSD. La coloration ici étant que ces threads sont Posix. Alors que à l'origine les threads Mach ne le sont pas.
 
Moi je disais qu'il était UNIX parce qu'il me semblait que les personnes autorisées avaient admis qu'il était compatible avec une certaine norme "UNIX" dont on se fiche éperdument mais qui fait parler les geeks, mais je suppose que c'est encore un autre sujet ;)

Et puis tout ça, ça me fait mal à la tête, t'aurais pas un dessin plutôt qu'un long discours ? ;)
 
Manu a dit:
Naas, puisque tu le demandes, je vais faire une retrospective assez rapide. Dans les années 80, l'explosion de la micro apporte la puissance des ordinateurs dix à cent fois plus gros à un nouveau type d'ordinateur utilisable sur un bureau. Dans des universités et les centres de recherche, des projetsfusent . Notamment celui d'un chercheur de l'Université de Rochester qui se nomme Richard Rashid. A cette époque, le système le plus utilisé dans les universités est Unix. Une des variantes sera d'aiileurs développé à l'Université de Berkeley, c'est BSD. Le système Unix bien que très solide avait un gros inconvénient c'est que au fur et à mesure qu'on le peaufinait (ajout du support du réseau, etc), son noyau grossisait et donc pouvait poser des problèmes à la stabilité de l'OS et aux performances. D'où l'idée de 'dégraisser' celui-ci en le rendant plus petit et en y gardant que les fonctionalités dites vitales et en implémentant les autres fonctionalités (gestion de fichiers, etc) sous forme de serveurs. c'est la naissance des micro-noyau. Le projet Accent conduit par Richard Rashid s'inscrivait dans cette mouvance. Mais Rashid changea d'université et emmena son projet à l'université de Carnegie Melon. Là, il revit sa copie et forma une équipe pour continuer les travaux du projet Accent. c'est le projet qui donna naissance au micro-noyau Mach. Avi Tevanian faisait partie de l'équipe.
Pour plus de précisions, je vous invite à lire cet article

Comme vous le voyez, beaucoup de notions apportées par Mach (ports, thread, gestion de la mémoire virtuelle, support des architectures multi processeurs, etc) ont par la suite été incorporées dans les système Unix et d'autres (Windows NT).

Le gros reproche que l'on fait aux micro-noyaux c'est qu'en implémentant les fonctionalités OS sous forme de serveurs, cela pénalise les performances. d"autant que les échanges entre les serveurs et le micro-noyau se font par l'envoi de messages.
C'est pour cela qu'Apple au lieu d'utiliser Mach sous sa forme micro-noyau avec freeBSD comme serveur apportant les spécificités Unix, a plutôt décidé de créer un noyau simple incluant Mach, BSD, I/O kit pour la gestion des drivers, etc. les échanges à l'intérieur du noyau se faisant par appel direct de procédures. Mécanisme plus performant que l'emploi de messages.
Ce noyau Apple l'a mis en distribution libre sous licence sous le nom de Darwin.

Un noyau tout seul ne fait pas un système d'exploitation. Apple a donc dans un souci de modularité conçu son OS en couches en ajoutant au noyau, des différentes couches dont Aqua constitue la couche la plus haute et Darwin la plus basse.

TOUTES ces couches forment Mac OS X.

Pour info : Rashid bosse chez Microsoft, Avi Tevanian chez Apple (cela vous le saviez).

On peut utiliser Darwin comme noyau et se faire une distrib. Tout comme les distrib linux utilisent le même noyau mais l'OS ainsi constitué en ajoutant des apis différents et une interface (KDE ou autre) a un nom particulier (red hat, Mandrake, etc).

Quand je dis que Mac OS X n'est pas un Unix c'est que son noyau déjà n'est pas un noyau Unix traditionel. Mêm si celui-ci incorpore BSD. Tout le noyau de BSD n'est pas dans Mac OS X. certaines fonctionalités du noyau BSD sont apportées par Mach. Par souci de modernité, vu que FreeBSD évolue plus vite que Mach, certaines des fonctionalités de ce dernier sont dépassées par rapport à celles de FreeBSD. Dans un tel cas, Apple utilise la technique des poupées russes en enveloppant ( on dit wrapper en jargon geek) les fonctionalités de Mach par celles plus modernes et actuelles de freeBSD. c'est de cette façon par exemple que les threads de Mac OS X sont des threads Mach à 'coloration' FreeBSD. La coloration ici étant que ces threads sont Posix. Alors que à l'origine les threads Mach ne le sont pas.
Je suis enfin d'accord avec toi Manu... et beau résumé coup de boule

Manu a dit:
Quand je dis que Mac OS X n'est pas un Unix c'est que son noyau déjà n'est pas un noyau Unix traditionel.
On l'appellera ce noyau Darwin (c'est pas moi qui le dit :p).

Tu vas dire que je chipote un peu...:p en fait juste pour précisser...

En fait, quand je dis que OS X c'est un Unix, c'est qu'il fait parti de cette grande famille, mais avec ses particularités propres à OS X... Effectivement OS X n'a rien avoir avec "l'Unix" tel que l'on connait à l'origine et même avec d'autres membres de cette grande famille aujourd'hui...
 
NightWalker a dit:
En fait, quand je dis que OS X c'est un Unix, c'est qu'il fait parti de cette grande famille, mais avec ses particularités propres à OS X... Effectivement OS X n'a rien avoir avec "l'Unix" tel que l'on connait à l'origine et même avec d'autres membres de cette grande famille aujourd'hui...
"Evolution" pour résumer ?! ;) :zen:
 
Pour continuer le débat, et surtout pour montrer que Mac OS X n'est pas un Unix habillé avec aqua, c'est que Apple a vraiment bien peaufiné son bébé en ajoutant des comportements inédits que l'on ne trouve pas sur d'autres systèmes Unix.

Par exemple le noyau de Mac OS X est extensible. En effet Apple applique à son noyau la technologie qui lui a si bien réussi dans le passé. Les Plugins. Sauf que ceux-ci sont chargés à la demande comme extensions du noyau ( KEXT modules dans le jargon technique OS X).

C'est ainsi que la majorité des drivers sont impléméntés sous la fome de modules Kext et sont chargés à la demande. Plug and play oblige!!

Un développeur peut développer un module snifeur du traffic réseau pour un besoin particulier. Comme cette fonctionnalité s'exécute en mode noyau, il doit l'implémenter sous la forme d'un module KEXT. Apple fournit d'ailleurs dans l'I/O kit des outils de développement de module KEXT.

Tous les composants du noyau de OS X (File system, couche réseau, Mach, BSD, gestion des drivers) sont ainsi extensibles. Ce qui permet d'apporter au noyau des améliorations sans mettre en péril ses fondations.

D'autre part l'utilisation de Mach par Apple (et NeXT avant lui) n'est pas fortuit. En effet les concepteurs de Mach ont été beaucoup influencés par l'approche orienté objet qui était également à l'époque une technologie émergeante.

C'est ainsi que tout dans Mach est objet. (objet mémoire, objet thread, etc) chaque objet est identifié par un port. . le mécanisme d'échange entre les objets est l'IPC (Inter Processus Communication). Cet échange est basé sur l'envoi de messages. tout comme en orienté objet, les interraction entre objets se font par envoi de messages. Pour demander à un objet une action particulière, il faut lui envoyer cette demande sous forme de message à son port.

L'élégance de Mac OS X c'est d'avoir 'plaqué' au dessus de ce noyau 'orienté objet', un environnement orienté objet utilisé pour développer des applis: COCOA. Ainsi, tous les objets Mach ont des équivalents en Cocoa.

thread Mach --> NSThread objet cocoa
objet mémoire Mach --> NSData objet cocoa
objet Tâche Mach --> NSTask objet cocoa.
port Mach --> NSPort cocoa

...etc.
Comme un objet est identifié par son port, il peut donc se trouver n'importe où. Même sur une autre machine. C'est ainsi que lorsque le gestionnaire d'objets de Mach lorsqu'il ne trouve pas sur la machine l'objet (le port) auquel un message est destiné, il l'envoi à un autre noyau mach sur le réseau. Dés que l'un des noyaux s'apperçoit que l'objet destinataire est sur la machine courante, il le fait savoir au noyau emetteur qui crée un objet proxy .
Apple a utilisé toute cette infrastructure pour implémenter ce qui fait le charme caché de Cocoa, l'architecture des applications distribuées décrite en détail ici

Attention c'est en anglais et la lecture est fastidieuse et quelque peu indigeste. Il faut vraiment aimer!!!

C'est à ma connaissance le seul OS à fournir un environnement aussi riche et sophistiqué. Faire du distribué en cocoa sur OS X c'est un régal!!

Tout cela pour dire que la symbiose Cocoa - Mach est l'une des choses qui fait le charme et l'élégance de cet OS.
 
  • J’aime
Réactions: fanou
Spyro a dit:
Moi je disais qu'il était UNIX parce qu'il me semblait que les personnes autorisées avaient admis qu'il était compatible avec une certaine norme "UNIX" dont on se fiche éperdument mais qui fait parler les geeks, mais je suppose que c'est encore un autre sujet ;)

Et puis tout ça, ça me fait mal à la tête, t'aurais pas un dessin plutôt qu'un long discours ? ;)

Aucun problème, il suffit de demander ;) -> Dessin d'UNIX


Mais je suis pas très sûr que ta tête apprécie :D
 
Manu a dit:
...
Tous les composants du noyau de OS X (File system, couche réseau, Mach, BSD, gestion des drivers) sont ainsi extensibles. Ce qui permet d'apporter au noyau des améliorations sans mettre en péril ses fondations.

...
T'es sûr que OS X est le seul extensible en la matière ?

Comme un objet est identifié par son port, il peut donc se trouver n'importe où. Même sur une autre machine. C'est ainsi que lorsque le gestionnaire d'objets de Mach lorsqu'il ne trouve pas sur la machine l'objet (le port) auquel un message est destiné, il l'envoi à un autre noyau mach sur le réseau. Dés que l'un des noyaux s'apperçoit que l'objet destinataire est sur la machine courante, il le fait savoir au noyau emetteur qui crée un objet proxy .
Apple a utilisé toute cette infrastructure pour implémenter ce qui fait le charme caché de Cocoa, l'architecture des applications distribuées décrite en détail ici
Comme architecture distribuée, il y a déjà CORBA sous Unix, DCOM sous Windows.

Je suis désolè Manu: si l'on ne tient pas compte de l'interface graphique, tu n'as pas un SEUL exemple appuyant la thèse que OS X est meilleur que les autres.
 
cygwin a dit:
...Je suis désolè Manu: si l'on ne tient pas compte de l'interface graphique, tu n'as pas un SEUL exemple appuyant la thèse que OS X est meilleur que les autres.
benh c'est justement ou apple sait faire ce que les autres ne savent pas, exploiter au maximum un os en proposant une interface graphique utilisable par tous :D :D :D
parceque c'est bien gentil des truc hyper mega chiadé mais si il faut s'adapter au truc en question benh moi perso je trouve que c'est raté, moi ce que j'aime bien c'est que la techno se plie a ce que je veuille faire, pas l'inverse :zen:
 
naas a dit:
benh c'est justement ou apple sait faire ce que les autres ne savent pas, exploiter au maximum un os en proposant une interface graphique utilisable par tous :D :D :D
Voilà, il suffisait de dire simplement : OS X est meilleur parce qu'il a une meilleure interface graphique. Essayer d'aller au delà est vraiment un travail ingrat voire contre productif.
 
naas a dit:
benh c'est justement ou apple sait faire ce que les autres ne savent pas, exploiter au maximum un os en proposant une interface graphique utilisable par tous :D :D :D
parceque c'est bien gentil des truc hyper mega chiadé mais si il faut s'adapter au truc en question benh moi perso je trouve que c'est raté, moi ce que j'aime bien c'est que la techno se plie a ce que je veuille faire, pas l'inverse :zen:
Je vote Naas président.... :p

Blague mise à part, Apple a encore pousser plus loin dans Tiger en proposant Core Image et Core Audio. T'imagines, enfin d'après leur démo, tu n'es même plus obligé de taper dans les contrôleurs vidéo ou audio toi même. Tout est standardisé en appel API ou des objets près à intégrés dans les applications de "M tout le monde"... C'est carrément monstrueux... ce que j'aimerai bien savoir c'est comment Apple va réussir à faire ce tour de passe entre les contôleurs graphiques (par ex.) de ATI et NVidia ?

Pour embêter un peu Manu :p

Manu a dit:
Pour continuer le débat, et surtout pour montrer que Mac OS X n'est pas un Unix habillé avec aqua...
si je dis que OS X c'est Darwin habillé avec Aqua ????
 
cygwin a dit:
T'es sûr que OS X est le seul extensible en la matière ?


Comme architecture distribuée, il y a déjà CORBA sous Unix, DCOM sous Windows.

Je suis désolè Manu: si l'on ne tient pas compte de l'interface graphique, tu n'as pas un SEUL exemple appuyant la thèse que OS X est meilleur que les autres.
Sous Unix CORBA n'est pas natif en ce sens qu'il ne fait pas partie de l'architecture de l'OS. Alors que l'architecture de Mach permet de faire du distribué SANS AJOUTER une couche quelconque. Unix peut tourner sans corba et Windows sans DCOM mais Mac OS X ne peut tourner sans Mach.

J'ai pas dit que Mac OS X est meilleur cela ne veut rien dire. Je dis tout simplement que Apple a conçu son OS très ingénieusement. Pour une personne qui s'interesse à la conception des OS, celui de Mac OS X est vraiment un cas d'école. Bref c'est LE système d'exploitation moderne par excellence.

Un exemple, les fichiers /etc/passwd et /etc/group ne sont pas utilisés comme dans les systèmes unix. les utilisateurs, leur mot de passe et les groupes sont stockés dans un annuaire de type LDAP (qui remplace Netinfo) c'est un fonctionnement STANDARD dans OS X.

Tu connais un exemple de noyau d'OS extensible? les unix et linux dès que le noyau est modifié, il faut le recompiler. Dans Mac OS X on peut modifier un module KEXT sans recompiler le noyau de l'OS.
 
NightWalker a dit:
Je vote Naas président.... :p

Blague mise à part, Apple a encore pousser plus loin dans Tiger en proposant Core Image et Core Audio. T'imagines, enfin d'après leur démo, tu n'es même plus obligé de taper dans les contrôleurs vidéo ou audio toi même. Tout est standardisé en appel API ou des objets près à intégrés dans les applications de "M tout le monde"... C'est carrément monstrueux... ce que j'aimerai bien savoir c'est comment Apple va réussir à faire ce tour de passe entre les contôleurs graphiques (par ex.) de ATI et NVidia ?

Pour embêter un peu Manu :p

si je dis que OS X c'est Darwin habillé avec Aqua ????
Rappele-toi Apple avait racheté Silicon Grail une boite spécialisée dans la conception des cartes graphiques de très haut niveau. Ces ingénieurs connaissent très bien l'architecture des cartes graphiques. Ils bossent en général avec les ingés de NVidia et ATI. D'ailleurs je me souviens que dans une interview, le patron de NVidia ne tarissait pas d'eloges ces ingés d'Apple. ils sont à l'origine de core video, core image et quartz extreme.
 
Manu a dit:
Sous Unix CORBA n'est pas natif en ce sens qu'il ne fait pas partie de l'architecture de l'OS. Alors que l'architecture de Mach permet de faire du distribué SANS AJOUTER une couche quelconque. Unix peut tourner sans corba et Windows sans DCOM mais Mac OS X ne peut tourner sans Mach.

J'ai pas dit que Mac OS X est meilleur cela ne veut rien dire. Je dis tout simplement que Apple a conçu son OS très ingénieusement. Pour une personne qui s'interesse à la conception des OS, celui de Mac OS X est vraiment un cas d'école. Bref c'est LE système d'exploitation moderne par excellence.

Un exemple, les fichiers /etc/passwd et /etc/group ne sont pas utilisés comme dans les systèmes unix. les utilisateurs, leur mot de passe et les groupes sont stockés dans un annuaire de type LDAP (qui remplace Netinfo) c'est un fonctionnement STANDARD dans OS X.

Tu connais un exemple de noyau d'OS extensible? les unix et linux dès que le noyau est modifié, il faut le recompiler. Dans Mac OS X on peut modifier un module KEXT sans recompiler le noyau de l'OS.

Tu sembles bien connaître Darwin, et c'est vrai que le côté orienté objet de Mach est interessant d'n point de vue théorique...;et peut laisser dubitatif niveau performance; par contre tu NE connais PAS Linux c'set clair.
Linux est un noyau monolithique modulaire. Bien sûr si tu modifies le scheduler c'est pas un moduel à recharger, mais si par exemple tu vux monter une partition d'un système de fichier pas supporté par ton noyau de base, bine tu compile le module et puis insmod tu le charge et ça marche (pareil pour les drivers de périphériques classiques).
 
Manu a dit:
Rappele-toi Apple avait racheté Silicon Grail une boite spécialisée dans la conception des cartes graphiques de très haut niveau. Ces ingénieurs connaissent très bien l'architecture des cartes graphiques. Ils bossent en général avec les ingés de NVidia et ATI. D'ailleurs je me souviens que dans une interview, le patron de NVidia ne tarissait pas d'eloges ces ingés d'Apple. ils sont à l'origine de core video, core image et quartz extreme.

ah non, je ne savais pas, je l'avais raté cette information... c'est cool ça... j'adore de plus en plus cet OS... vivement l'arrivée de mon G5 pour que je puisse goûter au XCode et plus tard Tiger...
 
Gallenza a dit:
...Linux est un noyau monolithique modulaire. Bien sûr si tu modifies le scheduler c'est pas un moduel à recharger, mais si par exemple tu vux monter une partition d'un système de fichier pas supporté par ton noyau de base, bine tu compile le module et puis insmod tu le charge et ça marche (pareil pour les drivers de périphériques classiques).
:mouais: bah jusque là j'arrivais un peu a suivre mais là... chui perdu :mouais:
 
Naas, je vais essayer de prendre un exemple simple pour expliquer le fonctionnement de Mach et montrer son gros apport dans le fonctionnement global de Mac OS X.

J'ai un projet de construction d'un immeuble pour abriter une entreprise futuriste c'est à dire dynamique.

Mon immeuble dans son architecture simple dispose au rez-de-chaussée d'un service chargé de la gestion et de l'organisation globale de l'entreprise abrité dans l'immeuble je l'appelle Noyau de l'immeuble. Il a une organisation très solide et toute la solidité de l'immeuble et l'efficacité de l'Entreprise dépendent de lui.

A chaque étage, il n'y a qu'un seul bureau affecté à un seul service. Les services sont de tout ordre. Service de comptabilité, service vidéo , service presse, service photo, etc.

L'affectation d'un service à un étage est effectuée par le noyau de l'immeuble. Chaque service est composé d'un ou plusieurs employés chacun étant affecté à une fonction particulière. ex :bdans le service photo un employé est chargé d'appliquer les filtres un autre de gérer les couleurs, etc.

A chaque service est affecté un ou plusieurs projets.

La façon dont travaille les employés est assez particulière.

1 - Tous les services partagent un même espace de travail c'est à dire une espèce de grand bureau divisé en mini-espaces. De sorte que lorsqu'un employé veut exécuter une tâche, il le fait dans le mini-espace de travail que lui a attribué le Noyau pour bosser. Dès qu'il a fini, le noyau peut affecter ce mini-espace à un autre employé.

2 - A un instant t, un seul employé d'un service donné est actif. car il utilise toutes les ressources du seul bureau du service..

3 - Chaque service dispose d'un ou plusieurs boites aux lettres. Ces boites aux lettres et leur nombre sont déterminés par le noyau qui effectue également leur gestion.
C'est par ces boites aux lettres que les employés de chaque service reçoivent les tâches qu'ils doivent exécuter. A un instant t un employé peut se voir attribuer plusieurs boites aux lettres quand il a beaucoup de boulot. Chaque employé gère les tâches d'une boite aux lettres suivant la méthode premier entré premier servi .

4 - Chaque tâche affecté à un employé passe par le noyau qui se charge de la déposer dans la boite aux lettres. Pour qu'un employé demande à un autre employé d'effectuer une tâche, il lui faut une authorisation. Cette authorisation lui est donnée par l'employé qui exécute la tâche. Mais cette authorisation est gérée par le noyau qui en garde une trace.
5 - Chaque boite aux lettre est identifié par un numéro de la forme Xyyzz avec X le numéro de l'immeuble , yy un numéro de service, zz un numéro de séquence.
par exemple 10422 est la boite au lettre de l'employé 22 du service situé au 04 ème étage de l'immeuble 1.
6 - Le noyau d'un immeuble peut recevoir une demande de tâche destinée à un employé d'un autre immeuble. Dans ce cas il envoie la demande au noyau de l'immeuble concerné qui le transmettra à l'employé destinataire.

Voilà l'organisation de mon immeuble.

Quest ce que cela à avoir avec Mac OS X direz-vous? Eh bien je viens en fait de décrire là l'architecture de Mach le noyau de Mac OS X.

Un immeuble est une machine sous Mac OS X.

Un service à un étage est une application. Service photo c'est par exemple potoshop, service vidéo Final cut etc.

Un projet correspond a une fenêtre ouverte de l'appli.

Chaque employé dans un service A est un thread de l'application A.

Une boite aux lettre est un Port et est identifié par le numéro du Port.

Les tâches exécutées par un thread font l'objet d'une demande déposée sur sa boite aux lettres euh! pardon son PORT. Celui-ci porte un numéro que j'ai décrit plus haut.

L'espace de travail commun c'est la mémoire.

Où est l'architecture permettant de faire du distribué me direz-vous?

Eh bien un employé 34 du service 02 de l'immeuble 2 peut demander des tâches à l'employé 11 du service 25 de l'immeuble 4 et à l'employé 47 du service 15 de l'immeuble 8.
Ces deux demandes passent par le noyau de l'immeuble 2 qui les transmet aux noyaux des immeubles 4 et 8.

Tout se fait de manière transparente.

La gestion du multi processing est également immédiate. En effet une machine bi processeur signifie dans notre exemple qu'à chaque étage il n'ya pas qu'un seul bureau mais 2.

Ainsi au lieu d'affecter un seul employé à une tâche donnée, le noyau peut en affecter 2 car la contrainte n°2 indiqué ci-dessus a sauté vu que chaque service dispose de 2 bureaux. Cela veut tout simplement dire que dans un système multiprocesseur, plusieurs threads peuvent bosser EN MEME TEMPS. C'est pourquoi Apple dit souvent qu'avec un power mac bi-processeur on bosse deux fois plus vite.

CQFD.

J'espère avoir éclairci quelques lanternes.

Pardon pour la longueur.
 
Manu a dit:
Naas, je vais essayer de prendre un exemple simple pour expliquer le fonctionnement de Mach et montrer son gros apport dans le fonctionnement global de Mac OS X.

......

La gestion du multi processing est également immédiate. En effet une machine bi processeur signifie dans notre exemple qu'à chaque étage il n'ya pas qu'un seul bureau mais 2.

Ainsi au lieu d'affecter un seul employé à une tâche donnée, le noyau peut en affecter 2 car la contrainte n°2 indiqué ci-dessus a sauté vu que chaque service dispose de 2 bureaux. Cela veut tout simplement dire que dans un système multiprocesseur, plusieurs threads peuvent bosser EN MEME TEMPS. C'est pourquoi Apple dit souvent qu'avec un power mac bi-processeur on bosse deux fois plus vite.

CQFD.

J'espère avoir éclairci quelques lanternes.

Pardon pour la longueur.

tu sais quoi tu m'epate !!! :up: :up: :up: :up:

j'ai tout compris :up: :up: :up:

merci et continue comme ça, les choses que tu dis devrait etre consigné et à lire par les petits nouveau ou les trolls de base
 
  • J’aime
Réactions: Lordwizard
Pour continuer cette discussion et pour faire suite à quelques mails me demandant d'utiliser l'exemple pour expliquer d'autres notions interessante du fonctionnement du noyau de Mac OS X, je vais détailler comment le noyau gère l'espace de travail.

Comme je l'ai indiqué plus haut, lorsqu'un employé veut exécuter un boulot quelconque, le noyau lui attribue un mini-espace.

Le noyau peut également attribuer à un employé un mini-espace pour que celui-ci range les données ou autres ressources dont il a besoin pour bosser.

Il peut arriver que plusieurs employés d'un service se retrouvent dans l'espace de travail chacun dans un mini-espace. Mais partageant tous les données et resources se trouvant dans un autre mini-espace.

Un employé dans un espace de travail n'est pas forcément actif tout le temps. Il peut être en repos à l'attente d'un document qu'il a demandé à un autre employé par exemple.

Dans le noyau, il existe un employé qui gère l'espace de travail. il tient à jour deux cartes. Dans la première, il note tous les employés qui sont dans l'espace de travail et pour chacun d'entre eux, il met à jour une priorité qui dépend de la durée de oisiveté de l' employé dans l'espace de travail. Plus un employé est oisif longtemps plus sa pririté baisse.

La seconde carte vituelle que j'appellerai MV. C'est une carte de taille fixe dans laquelle sont notés tout le contenu du bureau d'un service, toutes les ressources utilisées par les employés du service. A cette carte est associée une table de correspondance indiquant pour chaque élément de la carte, sa place dans l'espace de travail s'il y a été chargé.

A quoi cela sert-il? eh bien souvenez-vous que lorsqu'un employé veut bosser, le noyau doit trouver un mini-espace libre pour lui. S'il y en a pas, il doit 'dégager' un employé. Pour cela il se base sur la carte de priorité des employés.

D'autre part, le 6 ème étage de mon immeuble heberge un service particulier c'est les ressources humaines. C'est ce service qui se charge de déménager les employés et/ou leurs ressources de l'étage de leur service à l'espace de travail et vice-versa.

C'est à ce service que le noyau fait appel pour attribuer un mini-espace et 'dégager' un employé oisif.

J'ai indiqué que dans un mini-espace se trouvaient des ressources et données partagés par plusieurs employés.

En effet lorsqu'un employé dispose d'un mini-espace entier pour ses données et ses ressources, il signale au noyau quels sont les données et ressources qu'il accepte de partager avec d'autres employés.

Dans ce cas le noyau tient à jour la liste des ressources partagées et le nombre d'employés dans l'espace de travail qui l'utilisent.

Dès qu'un employé quelconque veut modifier une ressource partagée, le noyau créer dans son mini-espace une copie de la ressource qu'il peut alors modifier et diminue de 1 le nombre d'employés partageant la ressource puisqu'un d'eux dispose de sa copie. Ensuite le noyau met à jour la carte MV.

Cela veut dire qu'aucune copie n'est créée pour une ressource partagée en CONSULTATION. Ce détail est fondamental.

J'ai indiqué dans mon post précédent que pour demander une tâche à un employé, il faut lui envoyer la demande sous forme de message que le noyau se chargera de mettre dans sa boite aux lettres.

Eh bien c'est justement dans l'espace de ressources partagées que l'employé émetteur va rédiger sa demande en y joignant si possible tous les documents permettant au destinataire d'effectuer la tâche demandée.

Que pensez-vous que va faire le noyau de ce message qui peut être ENORME. (demande+plusieurs documents)

Eh bien contrairement à d'autres OS, le noyau ne va pas déplacer ce gros message pour le déposer dans la boite aux lettres du destinataire. Il mettra tout simplement dans la boite aux lettres un post-it indiquant que le destinataire peut CONSULTER le message dans le mini-espace des ressource partagées.

Je viens de décrire là deux choses imporatantes de Mach le noyau de Mac OS X.

La gestion de la mémoire virtuelle MV et la communication entre processus ou l'IPC.

La gestion de la mémoire virtuelle de Mach illustrée par la carte MV. Le service du noyau gérant les deux cartes gére en fait la mémoire virtuelle. Le service du 6 ème étage chargé du déménagement c'est ce qu'on appelle le pager. Le pager ne se trouve pas dans le noyau C'est lui qui s'occupe du fameux swap.

Le swap c'est grossomodo dégager un employé et ses ressources du mini-espace pour les remettre dans le bureau de son service.

Il faut noter aussi que les ressources partagées ne peuvent être 'swapées' que lorsque le noyau s'apperçoit que tous les employés qui l'utilisaient ont été swapés.

Le fait d'indiquer sur un post-it la location d'un message comme ressource partagée c'est faire du 'mapping'. C'est ainsi que l'on peut par cette astuce passer d'un thread à un autre des données importantes. C'est l'IPC (Inter Processus Communication).

La gestion des données partagées consistant à ne copier la donnée dans l'espace d'un employé que lorsqu'il veut la modifier c'est faire du 'copy-on-write' .

En résumé :

Pour gérer la mémoire virtuelle le noyau fait appel à un employé du service 'ressources humaines' en envoyant la demande de swap sous forme de message à la boite aux lettres de l'employé de ce service. Donc en utilisant l'IPC.

D'autre part l'efficacité de l'IPC est due à l'utilisation du copy-on-write technique de gestion de la mémoire virtuelle et non au déplacement de messages.


On dit en langage de geek que dans Mach la gestion de la mémoire virtuelle et l'IPC sont très liés. On se sert de l'un pour implémenter l'autre.

C'est de cette astuce que Mach tire sa puissance assez particulière.