En ce qui concerne le code du noyau, outre le code spécifique à l'architecture, qui est une très petite partie (1% à 5% ?), tout le code source du noyau est commun à toutes les architectures.
À propos des binaires :
En fait, dans la plupart des distributions Linux, vmlinuz est un lien symbolique qui pointe vers le code réel du noyau compressé ; comme vmlinuz-3.16.0-4-amd64 . Je suis sûr que l'OP parle de ce dernier, mais mentionne le premier pour le bénéfice du lecteur.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
S'il est vrai que le code ARM est en effet plus petit, même si les noyaux n'ont pas été compressés, les codes du noyau dans ARM sont souvent personnalisés et ont beaucoup moins de code activé que dans les versions homologues d'Intel (par exemple, Intel a beaucoup de cartes vidéo, même si seuls les stubs de modules, alors que généralement le noyau ARM personnalisé n'a à gérer que celui qui est présent dans le SoC).
De plus, la comparaison de blobs binaires aléatoires déjà compressés ne donne peut-être pas toujours les vrais résultats selon une étrange coïncidence, un binaire plus grand pourrait devenir plus petit en raison d'une optimisation de la compression.
Donc en réalité, pour comparer efficacement les noyaux binaires, il faut les compiler avec des options identiques, et les garder non compressés (ou décompresser le résultat vmlinuzxxx fichier).
Une correspondance équitable serait de comparer d'autres binaires non compressés, par exemple /bin/ls , ou /usr/sbin/tcpdump , et de plus une architecture similaire à celle que nous essayons de faire correspondre (les machines ARM sont encore largement en 32 bits, mais il en existe déjà quelques unes en 64 bits)
Inutile de dire que le même code compilé dans ARM sera toujours (beaucoup) plus petit car le code machine ARM est un code de plate-forme RISC. Il contient également un sous-ensemble plus petit d'instructions de code machine, ce qui se traduit par un code plus petit. D'autre part, Intel dispose d'un plus grand ensemble d'instructions, également en raison de l'héritage de rétrocompatibilité avec plusieurs générations de microprocesseurs.
De http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Le concept du processeur RISC est ancien et il est également très efficace. Dans les processeurs RISC, vous avez des charges de travail plus petites exécutées par chaque instruction, ces instructions sont également très souvent divisées en E/S et en mémoire pour éliminer davantage les frais généraux. Cela permet une utilisation très efficace du temps CPU et de la mémoire, mais peut également nécessiter un code volumineux du côté logiciel pour que tout fonctionne. Lorsque RISC a été développé pour la première fois, c'était la voie à suivre simplement parce que l'accès à la mémoire et au disque dur était lent. Les instructions volumineuses et complexes trouvées dans un processeur x86 étaient encombrantes sur les processeurs plus anciens et ne pouvaient pas suivre les systèmes RISC.
Néanmoins, la conversation n'est pas si simple, car les puces Intel sont une bête complexe de nos jours, et au plus profond de la couche pseudo-CISC, elles ont des stratégies et des conceptions RISC qui décodent et émulent les opcodes Intel tels que nous les connaissons.
Les opcodes ARM sont également volumineux, par rapport à un MIPS, par exemple, puisque l'ARM est un processeur bon marché avec des instructions spécialisées dédiées au décodage vidéo (environ 30 % de la matrice du processeur leur est dédiée).
Comme petit exercice, prenons le binaire tcpdump et les quatre architectures Linux auxquelles j'ai accès :
MIPS 32 bits -> 502.4K
BRAS 32 bits -> 718K
Intel 32 bits (i386) -> 983K
Intel 64 bits (x86_64) -> 1.1M
Revenons donc à votre question initiale :
- Les noyaux ARM "croissent" moins en taille car l'architecture a moins de diversité dans le matériel de base pour une distribution spécifique.
- Cependant, et bien plus significatif, leur taille est moindre car le code produit est plus efficace et compact.
Les noyaux "binaires" (vmlinuz ou plus) sont une courte portion de code qui décompresse le reste du noyau compressé proprement dit. Ils ont tellement en commun qu'une grande partie du début du fichier est le même (donc il se comprime au même).
Différences de taille des archives sources n'est pas pertinent, la plupart des changements d'une version à l'autre sont des lignes modifiées , et de nouveaux pilotes ajoutés (et les pilotes n'apparaissent pas dans le noyau binaire, ils ne sont utilisés que sur certaines machines et donc généralement sur des modules externes).