D'où vient Mac OS X?

L'histoire de MacOS est un peu plus compliquée. Cela m'intéressait beaucoup à la fin des années 90, alors que Mach avait été présenté dans le monde entier comme un moyen plus rapide de construire un système Unix.

L'origine du noyau est un peu plus compliquée.

Tout commence avec AT & T qui distribue gratuitement son système d'exploitation à certaines universités. Cet Unix a été considérablement amélioré à Berkeley et est devenu le fondement des variantes d’Unix BSD. Il intègre plusieurs innovations telles que le "Fast File System" (UFS), les liens symboliques introduits et l’API de sockets. AT & T suivit sa propre voie et construisit System V en même temps.

Pendant ce temps, les recherches se sont poursuivies et certaines personnes ont adopté les travaux de BSD comme base. À la CMU, le noyau BSD a été utilisé comme base pour le prototypage de quelques nouvelles idées: des threads, une API permettant de contrôler le système de mémoire virtuelle (via des "pagers" enfichables - mmap au niveau utilisateur), un système d’appel de procédure distant au niveau du noyau et la plupart des autres. surtout l’idée de déplacer certaines opérations au niveau du noyau vers l’espace utilisateur. Ceci est devenu le noyau de Mach.

Je ne suis pas sûr à 100% de savoir si mmap venait de Mach et a été adopté plus tard par BSD, ou si Mach a simplement lancé l'idée et que BSD a ajouté son propre mmap basé sur les idées de Mach.

Bien que le noyau Mach ait été décrit comme un micro-noyau, jusqu'à la version 2.5, il s'agissait simplement d'un système fournissant le fil, mmap, des fonctionnalités de transmission de messages, mais demeurant un noyau monolithique, tous les services s'exécutaient en mode noyau.

À cette époque, Rick Rashid (maintenant chez Microsoft) et Avie Tevanian (maintenant chez Apple) avaient eu une idée nouvelle qui pourrait accélérer Unix. L'idée était d'utiliser l'appel système mmap pour transmettre les données à copier de l'espace utilisateur aux "serveurs" implémentant le système de fichiers. Cette idée consistait essentiellement à essayer d'éviter de copier les mêmes données, mais elle était présentée comme un avantage des micro-noyaux, même si la fonctionnalité pouvait être isolée d'un micro-noyau.

Les points de repère de ce système Unix plus rapide soutenu par VM sont ce qui a poussé les gens de NeXT et de la FSF à choisir Mach comme base de leurs noyaux.

NeXT est allé avec le noyau Mach 2.5 (qui était basé sur BSD 4.2 ou 4.3) et GNU ne commencerait pas le travail avant des années. C'est ce que les systèmes d'exploitation NeXTSTEP utilisaient.

Pendant ce temps à la CMU, le travail sur Mach continuait et ils ont finalement réalisé la vision de plusieurs serveurs s'exécutant sur un micro-noyau avec la version 3.0. Je ne suis pas au courant que quiconque dans la nature soit capable d'exécuter Mach 3.0, car tous les serveurs de niveau utilisateur intéressants utilisaient du code AT & T, ils étaient donc considérés comme encombrés. Il restait donc un produit de recherche.

À peu près à la même époque, l’équipe Jolitz avait réalisé un portage de plus de 4,3 BSD vers l’architecture 386 et avait publié ses efforts de portage sur DrDobbs. 386BSD n’était pas activement maintenu et un groupe a été créé pour maintenir et faire progresser 386BSD, l’équipe de NetBSD. Des combats internes au sein du groupe NetBSD ont provoqué la première scission et FreeBSD en est issu. À l'époque, NetBSD souhaitait se concentrer sur un BSD multiplate-forme et FreeBSD souhaitait se concentrer sur un système Unix performant sur les plates-formes x86. Un peu plus tard, NetBSD s'est à nouveau séparé en raison d'autres conflits, ce qui a conduit à la création d'OpenBSD.

Une fourchette de BSD 4.3 pour plates-formes x86 est devenue commerciale avec une société appelée BSDi, et divers membres de l’équipe initiale de Berkeley y ont travaillé et ont maintenu de bonnes relations avec l’équipe de BSD de l’Université.

AT & T n'a pas été amusé et a entamé le procès AT & T vs BSDi, qui a ensuite été élargi pour poursuivre également l'Université. La plainte portait sur BSDi et utilisait un code propriétaire d’AT & T qui n’avait pas été réécrit par Berkeley. Cela établissait un décalage entre BSD et le système d’exploitation Linux à venir.

Bien que les choses ne semblaient pas bonnes pour les défendeurs, quelqu'un a vite compris que SystemV avait incorporé d'importants morceaux de code BSD sous licence BSD et qu'AT & T n'avait pas rempli ses obligations. Un accord a été conclu selon lequel AT & T n'aurait pas à retirer son produit du marché et l'Université a accepté d'extraire tout code pouvant encore être basé sur le code AT & T.

L'université a ensuite publié deux versions de BSD 4.4 encombré et 4.4 lite. La version encombrée démarrerait et s'exécuterait, mais contiendrait du code AT & T. La version lite ne contenait aucun code de AT & T mais ne fonctionnait pas.

Les différents efforts de BSD ont repris leur travail sur la nouvelle version 4.4 lite et ont mis en place un système de démarrage en quelques mois.

Pendant ce temps, le micro-noyau Mach 3.0 n'est pas très utile sans aucun des serveurs utilisateurs.

Un étudiant d’une université scandinave (je pense que j’ai peut-être tort) a été le premier à créer un système complet Mach 3.0 avec un système d’exploitation complet basé sur la version 4.4 lite. Je crois que cela s’appelait "Lites". Le système fonctionnait mais était lent.

Entre 1992 et 1996, BSD avait déjà un appel système mmap () et la plupart des autres systèmes Unix. Le "micro-noyau" qui n’était pas là ne s’est jamais vraiment concrétisé. NeXT avait toujours un noyau monolithique. La FSF essayait toujours de construire Mach, et ne voulant pas toucher au code BSD ni contribuer aux efforts de la BSD open source, elle continuait de s'en prendre à une vision du noyau mal spécifiée et se noyait sous les protocoles RPC. noyau. Le micro-noyau avait fière allure sur le papier, mais il s’est avéré trop technique et a tout ralenti.

À ce stade, nous avons également eu le débat Linus vs Andy sur les micro-noyaux vs les noyaux monolithiques et le monde a commencé à se rendre compte qu’il était tout simplement impossible d’ajouter tous ces cycles supplémentaires à un micro-noyau et d’avancer encore devant un noyau monolithique bien conçu. .

Apple n'avait pas encore acquis NeXTSTEP, mais commençait également à considérer Mach comme un noyau potentiel pour ses futurs systèmes d'exploitation. Ils ont embauché Open Software Foundation pour porter Linux sur le noyau Mach, et cela a été fait depuis leurs bureaux de Grenoble. Je crois que cela s'appelait "mklinux".

Lorsque Apple a acheté NeXT, il ne disposait que d'une base Unix relativement ancienne, d'un Unix basé sur 4.2 ou 4.3 et, à ce jour, même les logiciels libres ne fonctionnaient pas correctement sur ces systèmes. Ils ont engagé Jordan Hubbard hors de FreeBSD pour mettre à niveau leur pile Unix. Son équipe était responsable de la mise à niveau du territoire des utilisateurs, et il n’est pas surprenant que l’utilisateur MacOS ait été mis à niveau vers les dernières versions disponibles sur BSD.

Apple a fait passer leur Mach de 2,5 à 3,0 à un moment donné, mais a décidé de ne pas adopter l'approche du micro-noyau et a tout gardé en cours de traitement. Je n'ai jamais été en mesure de confirmer si Apple utilisait Lites, avait embauché le pirate informatique scandinave ou s'il avait adopté la version 4.4 lite comme système d'exploitation. J'imagine que oui, mais j'étais déjà passé sous Linux et j'avais arrêté de suivre le monde BSD / Mach.

Il y avait une rumeur à la fin des années 90 selon laquelle Avie chez Apple aurait tenté d'embaucher Linus (qui était déjà célèbre à ce moment-là) pour travailler sur son bébé, mais Linus a choisi de continuer à travailler sur Linux.

En dehors de l’histoire, cette page décrit l’utilisateur et le noyau Mach / Unix:

http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html#//apple_ref/doc/uid/TP30000905-CH1g-CACDAEDC

J'ai trouvé ce graphique de l'histoire d'OSX: texte alternatif

miguel.de.icaza
la source

Je croyais comprendre que la raison principale invoquée par Stallman à la FSF pour Mach n’était pas la performance mais la facilité d’utiliser un débogueur: il pouvait utiliser le débogueur pour déboguer des serveurs Mach beaucoup plus facilement que le code de débogage exécuté dans l’espace noyau. Bien que ce soit peut-être la performance qui l’ait convaincu, c’était un moyen viable de le mettre en œuvre.

skiphoppy

Si vous voulez vraiment voir un vrai micro-noyau en action, essayez QNX. Dans QNX4, le noyau ne contenait que 32 Ko et ne gérait que le transfert de messages, la planification du processeur et les interruptions. Toutes les autres parties du système d'exploitation QNX pouvaient être remplacées sans arrêter ou redémarrer le système, ce qui était extrêmement robuste. À une époque, il existait un émulateur de fenêtre pour QNX appelé Willows, qui exécutait les applications Windows plus rapidement que les fenêtres natives. Bien que cela n’ait rien à voir avec OS-X en tant que tel, QNX a prouvé que les micro-noyaux sont vraiment viables s’ils sont correctement préparés.

l'image n'est plus disponible.

Hermann Ingjaldsson le

Image pas encore disponible

Sildoreth

Steve Jobs a proposé un emploi à Linus en 2000. Linus en parle ici. wired.com/2012/03/mr-linux/all/1

Alistair McMillan

D'où vient Mac OS X?

Réponses: