1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Les mises à jour du noyau




Le noyau de Mac OS X a subi quelques modifications très significatives dans Tiger. Le noyau est une bête intéressante : un micro-noyau Mach, associé à une interface d'appel système de style BSD traditionnel, plus plusieurs technologies entièrement crées par Apple, comme l'IOKit. Mais pour les besoins de cette discussion, et dans la perspective de la plupart des développeurs, on peut le considérer comme une entité simple, qui présente seulement plusieurs interfaces différentes.

Rationalisation de l'interface

Malheureusement, historiquement, ce sont ces interfaces qui ont manqué dans Mac OS X. Il y a beaucoup de choses intéressantes associées au noyau que les développeurs (Apple comprise) ont eu besoin de faire pour supporter leurs applications Mac OS X. Aux premiers stades de la vie de Mac OS X, c'est tout ce qu'Apple pouvait faire pour rendre simplement ces choses là possibles. Plus tard, on a pris en considération l'efficacité. Mais à chaque étape, les développeurs étaient mis en garde, que beaucoup de choses qu'ils avaient besoin de faire, n'étaient pas "officiellement supportées" au delà de la version majeure courante du système d'exploitation.

Apple n'a pas découragé ces activités "non-officielles", cependant. Ils ont reconnu que c'était leur propre inaptitude à fournir des APIs officielles stables pour les fonctionnalités demandées, qui était la cause principale de la situation.

Le message aux développeurs était un peu étrange : " Nous, chez Apple, nous reconnaissons que vous avez besoin de faire ce genre de choses ; mais nous n'avons pas encore une interface stable ; vous pouvez utiliser cette API, et creuser un peu dans les structures de données ; gardez à l'esprit que les choses peuvent changer dans la prochaine révision majeure de Mac OS X ; si vous pouvez arriver à minimiser l'utilisation des structures de données du noyau, alors, faites-le". La recommandation finale était toujours : "Dites-nous s'il vous plaît pourquoi vous avez besoin de faire ce que vous faites, et comment nous pouvons rendre votre tâche plus facile".

Cela a duré pendant des années, largement ignoré de l'utilisateur occasionnel. De temps en temps, les utilisateurs avaient à télécharger un nouveau pilote d'imprimante, ou une extension VPN du noyau, en faisant la mise à jour à une nouvelle version majeure de Mac OS X, mais c'est normal.

D'une façon plus significative, l'absence d'APIs stables et officielles du noyau a aussi empêché quelques parties du noyau d'être bien explorées par des développeurs indépendants. Prenez par exemple les greffons du système de fichiers qui étaient une caractéristique très prisée du noyau de Mac OS X. Peut-être que seulement les lecteurs les plus pointus se rappelleront les possibilités excitantes des modules superposés, enfichables, du système de fichiers, qui fut présentée à la communauté des développeurs Mac, dans les premiers temps -avant 10.0- du développement de Mac OS X. Le support du nouveau système de fichiers se ferait à l'aide d'un module chargé dynamiquement ! Des couches de chiffrement pouvaient être ajoutées facilement à tout module existant du système de fichiers.

Tout cela semblait très prometteur, mais le seul vendeur à tirer un avantage effectif de ces possibilités fut Apple. Peu de développeurs indépendants étaient désireux de s'engager à créer (puis à prendre en charge) quelque chose d'aussi critique qu'un greffon de système de fichiers, au dessus d'APIs du noyau et de structures de données instables et "non supportées".

Quelque chose d'autre arriva en chemin. Malgré ses avertissements pressants aux développeurs, Apple a cherché avec force à fournir une compatibilité binaire pour les extensions du noyau (kexts) à travers toutes les révisions majeures de Mac OS X. Cet effort a été largement un succès, mais à un coût faramineux.

Pour maintenir la compatibilité binaire, Apple dut abandonner beaucoup de modifications du noyau qui auraient été bénéfiques. Des améliorations "évidentes" de performance ne furent pas mises en place. La capacité d'Apple a rajouter de nouvelles caractéristiques était très limitée. Toutes les modifications devaient être très prudentes, puisque Apple ne sut jamais quelles extensions existantes tierces du noyau allaient fourrager dans quelles structures de données. Encore pire, quelques bogues ne purent en fait pas être corrigées, parce qu'en le faisant, on aurait rompu la compatibilité binaire avec une ou plusieurs kexts importantes. Et même en dépit de tous ces efforts, des extensions du noyau indépendantes se cassaient quand même après des mises à jour majeures de l'OS.

A l'évidence, cette situation n'était pas idéale. Des parties du noyau restaient non utilisées, des bogues n'étaient pas corrigées, les améliorations du noyau avaient à être différées, et les kexts continuaient à se casser de temps en temps. Mais en même temps les développeurs apprenaient comment faire sous Mac OS X les choses associées au noyau réellement nécessaires, et Apple a appris ce dont les developpeurs avaient le plus besoin, et la meilleure manière de le fournir.

Avec Tiger, Apple est enfin prêt à planter dans le sol quelques poteaux de l'interface du noyau. Pour la première fois, il y a des Interfaces de Programmation du Noyau (KIPs) stables, officiellement supportées. Mieux encore, il y a un mécanisme de contrôle de version de l'interface, et des principes de migration qui vont empêcher que la situation pré-Tiger ne se reproduise plus jamais.

A partir de Tiger, les extensions du noyau vont être liées par les KPIs, plutôt que directement au noyau. Les KPIs ont été fractionnées en petits modules, si bien que les kexts peuvent se lier seulement avec les interfaces qu'elles ont réellement besoin d'utiliser.

Chaque KPI a un cycle de vie bien défini, avec les étapes suivantes :
• Supporté : la KPI est compatible (source et binaire) d'une version à une autre.
• Désapprouvé : l'interface peut être supprimée des mises à jour majeures suivantes. Des avertissements du compilateur sont créés quand on les utilise.
• Abandonné : il n'est plus possibles de construire de nouvelles extensions du noyau avec cette KPI, mais la compatibilité binaire avec les kexts existantes qui utilisent cette KPI est encore assurée.
• Non supporté : les kexts qui utilisent cette KPI ne marchent plus. Point !

La partie la plus importante de ce nouveau système est que le noyau lui-même peut, et va changer, en coulisse. Les KPIs ne vont descendre vers l'étape "non supportée" du cycle de vie que quand les modifications du noyau l'exigeront absolument.

Encore mieux : des versions multiples de KPIs peuvent coexister sur le même système. Cela permet à une KPI de s'améliorer avec de nouvelles possibilités et une interface modifiée, sans briser les extensions du noyau qui se lient à des versions plus anciennes de la KPI. Le but, c'est de permettre au noyau de subir une énorme quantité de changements, tout en acceptant encore toutes les KPIs.

Pour tester cela, il y a Tiger lui-même. Bien que le noyau de Tiger ait beaucoup changé en arrière plan, il y a des KPIs pour permettre à peu près tous les "mauvais comportements" antérieurs à Tiger des extensions du noyau. Oui, quelques kexts vont se briser dans Tiger, mais cela n'a rien de nouveau pour une mise à jour majeure du système. Cette fois, cependant, le futur semble plus brillant.

(En plus, la possibilité de plonger dans les structures de données du noyau, et de lier directement au noyau existe toujours sous Tiger. Mais cela devrait être rarement nécessaire, et est fortement désapprouvé. Apple dit aussi sans équivoque que tout kext qui procède ainsi se lie à une version spécifique du noyau (pas simplement une version majeure, la version exacte). Même dans ces conditions, le lien à un noyau spécifique est effectivement raisonnable dans quelques situations rares, tel que le développement de logiciel interne, alors, c'est bien que ce soit encore possible.)

Il y a quelques détails supplémentaires, dans ce monde des extensions du noyau qui, étonnamment, conduisent à les rendre plus familières à l'utilisateur (oui, l'utilisateur, pas seulement le développeur).

Les extensions du noyau sont maintenant censées contenir des noms de produits directement lisibles (et peut-être localisables). Cette information sera utilisée dans des boîtes de dialogue et d'autres éléments d'état dans l'interface utilisateur. Pour les développeurs qui ont besoin de plusieurs kexts pour implémenter leur produit, Tiger permet aussi le groupement des extensions du noyau, de façon à ce que de multiples kexts puissent être présentés à l'utilisateur comme un seul produit.

D'accord, je suppose que c'est aussi une modification "favorable au développeur". Les appels au noyau sont bien plus faciles à gérer quand l'utilisateur peut lire " AcmeSoft Driver version 1.03" directement sur l'écran, et que le développeur peut savoir exactement de quel ensemble d'extensions du noyau il s'agit.

Au total, il est clair que, avec Tiger, Noël est arrivé tôt, pour les développeurs d'extensions du noayu, mais aussi pour les utilisateurs.

La simultanéité

Dans les versions précédentes de Mac OS X, le noyau était essentiellement uni-thread. Un seul thread pouvait tourner à un moment donné. Les autres threads pouvaient continuer à tourner, tant qu'ils n'éxécutaient pas du code à l'intérieur du noyau.

Par exemple, une application de création de fractals n'a pas besoin d'être dans le noyau pour faire les calculs nécessaires pour dessiner l'itération suivante de l'image fractale. D'un autre côté, une application qui veut faire des entrées/sorties sur le réseau, un fichier ou un disque doit passer par le noyau pour cela.

Le noyau de Mac OS X utilise le verrouillage pour respecter ces contraintes. Dans Panther et avant, tout code qui a besoin de faire un appel au noyau pour que son travail s'effectue doit d'abord récupérer un "verrouillage du noyau". Si un autre thread est déjà verrouillé, le thread doit simplement attendre que le noyau devienne disponible. Imaginez maintenant 50 threads différents qui cherchent tous à récupérer le verrouillage du noyau en même temps, et vous avez ce qu'on appelle un "conflit de verrouillage". Le verrou lui-même est aussi qualifié d'entonnoir, parce qu'il canalise conceptuellement tous les threads en compétition en un seul flux d'activité en série.

J'ai décrit le noyau antérieur à Tiger comme "essentiellement" uni-thread parce qu'en réalité, il utilise un système à double entonnoir. Comme je l'ai dit précédemment, un thread qui veut s'exécuter dans le noyau a besoin de récupérer l'entonnoir du noyau. Mais s'il a besoin de faire une entrée/sortie sur le réseau, il peut renoncer à l'entonnoir du noyau, et solliciter l'entonnoir du réseau. Autrement dit, il y a un entonnoir pour le réseau, et un autre pour tout le reste dans le noyau. Et comme il se trouve que "tout le reste" est le plus souvent une entrée/sortie de fichier, l'entonnoir du noyau est aussi appelé l'entonnoir du système de fichiers.

Même avec un double entonnoir, ce système est ce qu'on appelle un verrouillage à gros grain. Plus est grosse la fonctionnalité protégée par le verrouillage, plus le grain du verrou est gros. Et plus le verrouillage est gros, plus il y a des chances de conflit de verrouillage. Un seul "entonnoir noyau", et un "entonnoir réseau" représentent un grain très gros, en fait.

Les choses s'aggravent quand vous considérez un système multi-CPUs. Un plus grand nombre de threads qui s'affrontent pour le même nombre de verrous du noyau implique encore plus de conflit. Il n'y a pas actuellement de Macs avec plus de deux CPUs, mais il faut y faire face : un Mac à double CPU, double cœur est inévitable (confirmé !). Une bête de ce genre ne va pas s'adapter gentiment à un noyau à double entonnoir. Que peut faire un OS ?

Le verrouillage à grain plus fin est la solution évidente. Au lieu de restreindre l'accès du noyau à d'énormes blocs de code, les verrous peuvent être placés devant des éléments de fonctionnalité moindre. Par exemple, au lieu de permettre à un seul thread à la fois de faire "n'importe quelle entrée/sortie réseau" dans le noyau, des verrous plus petits peuvent être placés à différents endroits de la pile du réseau : tampons de mémoire, sockets, couches de protocole, etc...

Comme il peut y avoir autant de threads qui tournent dans le noyau qu'il y a d'éléments individuels verrouillés, plus de verrous implique plus de threads, et moins de risque qu'un thread ne réclame exactement le même verrou qu'un autre. Le résultat final est moins de conflit, et la possibilité de s'adapter à un plus grand nombre de CPUs (ou de cœurs, avec des CPU multi-cœurs, ou de threads avec un multithreading symétrique).

L'envers de ma médaille, c'est une quantité mesurable de travail supplémentaire nécessitée par la gestion et la synchronisation de chaque verrou. Plus de verrous, c'est plus de travail. A un certain moment, on passe plus de temps à gérer et à synchroniser le verrouillage qu'on en a gagné en introduisant un verrouillage de grain plus fin. Si bien que, si un verrouillage à très gros grain comme celui de Panther avec son double entonnoir est à l'évidence insuffisant, il n'est pas bon non plus d'aller trop loin dans la direction opposée avec une énorme quantité de verrous élémentaires sur chaque fraction de fonctionnalité du noyau.

La meilleure façon de déterminer le réglage optimal pour le verrouillage du noyau est de commencer avec un gros grain (qui est le plus facile à implanter), et d'affiner le grain progressivement jusqu'à ce que les performances cessent de s'améliorer pour une charge typique dans un sous-système. C'est la technique qu'Apple a utilisée pour développer le noyau de Tiger. Tiger abandonne le double entonnoir, et le remplace par des verrous sur des éléments logiques de chaque sous-système du noyau.

Par exemple, un thread qui fait un appel système d'entrée/sortie de fichier peut commencer par récupérer le verrou du gestionnaire d'appel système générique, puis l'abandonner, et récupérer le verrou sur le gestionnaire de descripteur de fichier, puis le lâcher et attraper le verrou sur le code d'accès à la structure de données de fichiers du noyau, puis le lâcher pour un verrou sur le code d'accès au système de fichiers, et ainsi de suite.

Dès qu'un thread a abandonné un verrou, un autre thread peut le prendre, en suivant des cheminements bien définis à travers chaque sous-système du noyau, en attrapant et en relâchant les verrous quand ils se présentent. Dans la pratique, cela s'apparente beaucoup à ce que le "pipe line" fait dans un CPU, mais avec des compromis différents pour la "longueur du pipe line" (nombre de verrous) et pour le flux d'ensemble.

Une des conséquences des nouvelles possibilités multi-thread du noyau, c'est que les développeurs d'extensions du noyau doivent être sûrs absolument de ne pas considérer qu'ils sont le seul processus alloué dans leur morceau du noyau, à un moment donné. C'est très facile de s'affranchir de cette contrainte quand le noyau est divisé en deux morceaux énormes. Le verrouillage à grain plus fin du noyau de Tiger implique un travail plus grand de synchronisation, aussi bien pour Apple que pour les développeurs indépendants d'extensions du noyau.

Le support 64 bits

Panther avait introduit un support 64 bits rudimentaire dans Mac OS X. Il étendait l'espace d'adressage virtuel (dans le noyau seulement) à 64 bits, permettait l'utilisation de registres 64 bits, et des instructions qui les manipulent (c'est à dire, l'arithmétique 64 bits). Mais les processus autres que ceux du noyau ne voyaient encore qu'un espace d'adressage de 32 bits. Un seul processus pouvait utiliser plus de 4 Go de mémoire (rappelez-vous, le Power Mac G5 peut avoir jusqu'à 8 Go de RAM), mais cela obligeait le programmeur à jongler manuellement avec plusieurs espaces de mémoire, chacun adressable sur 32 bits.

Tiger fait franchir à Mac OS X un autre petit pas dans la direction 64 bits, en autorisant n'importe quel processus à voir un espace d'adressage sur 64 bits. Un tel processus doit utiliser dans son code des pointeurs 64 bits, bien sûr, et cela implique qye toutes les bibliothèques qu'il utilise doivent aussi être compilées en utilisant des pointeurs 64 bits.

Sous Tiger, la seule bibliothèque 64 bits est "libSystem" qui est essentiellement la couche BSD. Une version 32 bits de libSystem est aussi fournie, évidemment (sans cela, les applications 32 bits ne pourraient pas tourner sous Tiger).

Un processus peut faire beaucoup de choses en utilisant seulement libSystem : les entrées/sorties de fichier et de réseau, les communications inter-processus, et plus de maths. Mais la chose importante, c'est qu'il est impossible de faire toute opération GUI. (Désolé, curses ne compte pas).

Pour les Applications GUI qui ont besoin d'adresser plus de 4 Go de mémoire, la stratégie recommandée pour Tiger est de mettre en place un processus de travail en 64 bits qui utilise uniquement libSystem, et renvoie ses résultats à l'application hôte en utilisant l'un des nombreux mécanismes de communication inter-processus disponibles.

Le confinement des processus 64 bits à une prison sans GUI peut sembler sévère, mais dans la pratique, une grande proportion des processus qui utilisent 64 bits sont des processus "sans visage", qui font des calculs pour le compte d'un système plus gros : rendu offline, processus pour serveurs, calcul scientifique, etc... C'est quand même une amélioration depuis le support 64 bits de Panther ; c'est au moins quelque chose.

Il est clair que la route vers un support complet 64 bits sera longue. Il y a peu de bénéfices à être un processus 64 bits pour la plus grande majorité des applications graphiques (GUI). Néammoins, il est prudent de considérer que en fin de compte, tous les Macs vont avoir des CPUs 64 bits. L'introduction de versions 64 bits sur tous les sous-systèmes de Mac OS X (Carbon, Cocoa, Core Foundation, Quick Time, Quartz, etc...) semble inévitable.

Je me demande seulement quels seront les bénéfices d'introduire ce support par morceaux. Par exemple, cela semblerait déloyal pour Carbon d'être 64 bits alors que Cocoa ne l'est pas. De toute façon, toutes les bibliothèques graphiques de haut niveau reposent sur des services de bas niveau comme Quartz et Core Foundation. Si bien qu'il me semble que la meilleure transition dans le futur, sera de délivrer un système 64 bits complet en une seule fois. C'est une demande exigeante, et c'est pourquoi je pense que cela prendra du temps.

Pour résumer, sur le noyau

Avec les CPUs à deux cœurs en route, la suppression de l'entonnoir double peut sembler la modification la plus importante, dans le noyau de Tiger. Mais l'introduction d'interfaces de programmation stables pour le noyau est le héros gagnant ici. Sans les KPIs, aucune des autres modifications radicales du noyau de Tiger n'aurait été possible. Les KPIs rendent finalement l'équipe de développement du noyau d'Apple libre de faire toutes les choses qu'elle à toujours voulu faire.

Bien que le support 64 bits soit habituellement cité comme une caractéristique du noyau, le noyau de Tiger est allé à peu près aussi loin qu'il pouvait aller dans ce domaine. La balle est maintenant dans la cour des bibliothèques de l'espace utilisateur.