Pourquoi y a-t-il autant de noyaux Android différents ?

L'architecture du PC est construite autour de pièces de base parce qu'il s'agissait à l'origine de clones d'un produit spécifique, le PC IBM, qui ont été spécifiquement conçus pour être compatibles avec lui, et donc entre eux. D'une manière générale, vous pouvez prendre un programme ou un périphérique d'un PC compatible et le mettre dans un autre, et vous attendre à ce qu'il fonctionne. Cette capacité est suffisamment utile pour que les gens continuent à l'exiger, même si la technologie a évolué. Vous pouvez mettre une carte PCI Express dans n'importe quel PC moderne tout comme vous pouviez mettre une carte ISA dans n'importe quel clone de PC à l'époque.

Les smartphones n'ont pas cette histoire. Ils sont conçus comme des produits monolithiques, un système complet composé de matériel et de logiciels qui "fonctionnent" tels quels. On ne s'attend pas à ce que les gens prennent des pièces d'un téléphone pour les mettre dans un autre, et les ingénieurs n'ont donc pas à tenir compte de l'interopérabilité lorsqu'ils conçoivent leurs produits.

Même dans l'arbre des sources du noyau Linux, il y a beaucoup de fragmentation dans les pilotes pour les plateformes ARM . Comme les téléphones sont généralement conçus à huis clos, les équipes d'ingénieurs des différentes entreprises finissent souvent par faire un travail en double, en concevant essentiellement le même matériel que leurs concurrents, puis en écrivant leurs propres pilotes pour leur propre conception. Une fois qu'elles ont terminé et que le produit est commercialisé, elles passent directement au suivant ; cela ne vaut pas la peine de revenir en arrière et de remanier les pilotes des produits précédents ou de les fusionner avec ceux des concurrents. Le résultat est une pléthore de pilotes uniques pour des appareils qui sont similaires mais pas tout à fait identiques.

En outre, les smartphones sont généralement basés sur SOC qui ont un matériel spécialisé intégré au processeur. Pour certains d'entre eux, il ne s'agit pas seulement de savoir s'il faut charger ou non un certain pilote ; le noyau dans son ensemble peut devoir être construit avec des options de configuration spéciales pour fonctionner sur un SOC, qui sont incompatibles avec les options spéciales nécessaires pour fonctionner sur un autre SOC.

La raison en est que le noyau Linux d'Android n'est généralement pas compilé sur Android lui-même, mais doit être compilé à partir d'un autre ordinateur. Cela pose plusieurs problèmes, car la configuration du périphérique n'est pas disponible au moment de la compilation, et il n'est pas possible de compiler un noyau générique avec tous les pilotes en raison de l'espace limité (alors que la plupart des distros de bureau ont simplement tous les pilotes compilés dans des modules chargés à partir d'un initramfs). Par conséquent, les développeurs ont dû déterminer les pilotes à empaqueter pour chaque périphérique particulier. De plus, chaque pilote possède généralement une douzaine d'options de compilation permettant d'activer diverses fonctionnalités du pilote, et les fabricants ne publient généralement pas leur configuration officielle (les pires contrevenants n'ouvrent même pas leurs pilotes, ou ne maintiennent pas à jour la copie amont des pilotes). Comme les fabricants ne publient pas leurs configurations, il arrive souvent que la configuration légèrement différente utilisée par le développeur expose des bogues subtils qui n'existent pas avec la configuration du fabricant.

La programmation de pilotes est beaucoup plus difficile que la programmation d'applications, car il n'y a pas de noyau qui vous protège du matériel capricieux qui a des exigences spécifiques en matière de temps réel et ainsi de suite, et cela signifie que même en ayant une caractéristique de performance différente, le pilote peut manquer certains événements en temps réel du matériel ; ces manques peuvent apparaître comme des bogues ou des problèmes de performance.

Un autre problème est l'incompatibilité binaire. Il y a deux causes d'incompatibilité binaire, la première est le type de CPU, qui a été bien couvert par t0mm13b, mais l'autre problème qui est plus pertinent pour le portage est l'incompatibilité ABI (application binary interface). Si les fabricants n'ouvrent pas leurs pilotes, les développeurs doivent utiliser le module compilé à partir d'une ROM de base. Cela soulève divers problèmes d'incompatibilité ABI, puisque les modules du pilote ont eux-mêmes des attentes spécifiques concernant, par exemple, la disposition des structures et les paramètres d'appel des fonctions, et lorsque le noyau est compilé, il n'a pas le fichier d'en-tête pour décrire l'ABI au moment où le pilote est compilé, les développeurs ont donc dû faire de l'ingénierie inverse du pilote pour créer un fichier d'en-tête ou les fichiers d'en-tête dans l'arbre des sources peuvent avoir été fortement modifiés depuis la compilation du pilote et les développeurs ont dû revenir sur ces modifications pour rendre le noyau compatible à nouveau avec l'ABI du pilote. Contrairement à la compilation à partir des sources, la compilation d'un pilote binaire ne déclenchera pas d'erreur de compilation en raison d'une incompatibilité de paramètres de fonction ou de structures, mais fera tout simplement planter votre appareil pendant son fonctionnement, et le débogage de ces problèmes est très difficile. Dans le monde du PC, nous sommes familiers avec le désordre que nVidia et ATi nous ont laissé, en raison de leur insistance à publier des pilotes uniquement binaires, imaginez avoir ce désordre pour tous les pilotes, imaginez le "fun" que cela crée.

Le matériel PC est aussi généralement mieux standardisé que le matériel mobile, la plupart des PC n'ont pas besoin de pilotes pour les vibrateurs, l'accéléromètre, le gyroscope, la radio 3G, le capteur de proximité, le NFC, etc. Même sur les appareils qui disposent de la 3G, celle-ci se connecte généralement au matériel à l'aide de connexions standardisées telles que PCMCIA ou PCI-E.

Les pilotes Well.... et le noyau ne sont pas exactement les mêmes.

Les pilotes sont ceux qui contrôlent l'antenne cellulaire, le wifi, le bluetooth, etc. Il s'agit de pilotes propriétaires car le fabricant doit créer un moyen (les pilotes) de communiquer avec son matériel.

Le noyau est un niveau intermédiaire entre le système d'exploitation/application et les pilotes réels (ou le processeur ou la mémoire ou tout autre matériel). C'est ce qui permet à votre système d'exploitation ou à vos applications de s'interfacer avec ces composants matériels.

Tous les millions de noyaux que vous voyez ne sont pas vraiment très différents les uns des autres. En général, un programmeur ou un modificateur prend le noyau existant et le "modifie" pour essayer d'en tirer des performances différentes. On peut dire qu'il ne fait qu'ajuster (pour la plupart) la "configuration" du noyau. Dans le monde Android, ces moddeurs cherchent principalement à : surclocker ou underclocker l'horloge du CPU (important pour économiser l'autonomie de la batterie ou pour essayer d'exécuter les applications les plus intensives en processus comme les émulateurs de jeux vidéo ou la lecture vidéo), ou ils cherchent à sous-volter (pour économiser l'autonomie de la batterie en faisant fonctionner votre CPU en dehors de ses paramètres d'origine... ce qui varie en effet d'une personne à l'autre parce qu'il n'y a pas deux CPU qui sont fabriqués à 100% exactement de la même manière).

Les téléphones et autres appareils embarqués ne disposent pas d'un BIOS pour fournir une abstraction entre le matériel et le système d'exploitation, de sorte que le système d'exploitation est compilé pour le matériel sur lequel il est déployé. Même les appareils utilisant le même jeu de puces peuvent être configurés de différentes manières (en utilisant des bus de communication alternatifs, etc.). \the Le résultat est que le noyau doit être compilé en conséquence. Comme on ne s'attend pas à des changements dans le matériel, aucune détection du matériel n'est effectuée. Le noyau démarre plus rapidement et est donc plus petit - c'est un principe standard d'un système d'exploitation embarqué.