Per quanto riguarda il codice del kernel, oltre al codice specifico dell'architettura, che è una porzione molto piccola (dall'1% al 5%?), tutto il codice sorgente del kernel è comune a tutte le architetture.
Informazioni sui binari:
In realtà nella maggior parte delle distribuzioni Linux, vmlinuz è un collegamento simbolico che punta all'effettivo codice del kernel compresso con gzip; come vmlinuz-3.16.0-4-amd64 . Sono sicuro che l'OP stia parlando di quest'ultimo, menzionando tuttavia il primo a beneficio del lettore.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
Sebbene sia effettivamente vero che il codice ARM è effettivamente più piccolo, anche se i kernel non sono stati compressi, i codici kernel in ARM sono spesso realizzati su misura e hanno molto meno codice attivato rispetto alle versioni della controparte Intel (ad es. schede video, anche solo i moduli stub, mentre solitamente il kernel ARM personalizzato deve fare i conti solo con quello presente nel SoC).
Inoltre, il confronto di blob binari casuali già compressi potrebbe non produrre sempre i risultati veri poiché per qualche strana coincidenza un binario più grande potrebbe diventare più piccolo a causa di un'ottimizzazione della compressione.
Quindi, in realtà, per confrontare efficacemente i kernel binari, devi compilarli con opzioni identiche e mantenerli non compressi (o decomprimere il vmlinuzxxx risultante file).
Una corrispondenza equa sarebbe confrontare altri binari non compressi, ad esempio /bin/ls o /usr/sbin/tcpdump , e inoltre un'architettura simile a quella che stiamo cercando di abbinare (le macchine ARM sono ancora in gran parte a 32 bit, tuttavia ce ne sono già alcune a 64 bit)
Inutile dire che lo stesso codice compilato in ARM sarà sempre (molto) più piccolo perché il codice macchina ARM è un codice della piattaforma RISC. Ha anche un sottoinsieme più piccolo di istruzioni in codice macchina, che si traduce in un codice più piccolo. D'altra parte, l'Intel ha un set di istruzioni più ampio, anche a causa dell'eredità della retrocompatibilità con più generazioni di microprocessori.
Da http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Il concetto della CPU RISC è vecchio ed è anche molto efficiente. Nelle CPU RISC hai carichi di lavoro più piccoli eseguiti da ciascuna istruzione, queste istruzioni sono anche molto spesso suddivise in I/O e memoria per eliminare ulteriormente l'overhead. Ciò consente un uso molto efficiente della CPU e del tempo di memoria, ma può anche richiedere un codice ingombrante sul lato software per far funzionare tutto. Quando RISC è stato sviluppato per la prima volta, era la strada da percorrere semplicemente perché l'accesso alla memoria e all'HDD era lento. Le istruzioni ingombranti e complesse che si trovano in una CPU x86 erano ingombranti sulle CPU più vecchie e non riuscivano a tenere il passo con i sistemi RISC.
Tuttavia, la conversazione non è abbastanza diretta, dato che i chip Intel sono una bestia complessa al giorno d'oggi, e in fondo al livello pseudo-CISC hanno strategie e progetti RISC che decodificano ed emulano i codici operativi Intel così come li conosciamo.
Anche i codici operativi ARM sono ingombranti, rispetto diciamo a un MIPS, poiché l'ARM è un processore economico con istruzioni specializzate dedicate alla decodifica video (circa il 30% del die del processore è dedicato a loro).
Come breve esercizio, prendi il binario tcpdump e le quattro architetture Linux a cui ho accesso:
MIPS 32 bit -> 502.4K
BRACCIO 32 bit -> 718K
Intel 32 bit (i386) -> 983K
Intel 64 bit (x86_64) -> 1,1 milioni
Quindi, tornando alla tua domanda iniziale:
- I kernel ARM "crescono" di dimensioni inferiori perché l'architettura ha meno diversità nell'hardware di base per una distribuzione specifica.
- Tuttavia, cosa molto più significativa, crescono di dimensioni inferiori perché il codice prodotto è più efficiente e compatto.
I kernel "binari" (vmlinuz o giù di lì) sono un breve tratto di codice che decomprime il resto del kernel compresso vero e proprio. Hanno così tanto in comune che gran parte dell'inizio del file è lo stesso (quindi si comprime allo stesso modo).
Differenze di dimensioni degli archivi di origine è piuttosto irrilevante, la maggior parte delle modifiche da una versione all'altra sono righe modificate e nuovi driver aggiunti (e i driver non vengono visualizzati nel kernel binario, sono utilizzati solo in alcune macchine e quindi in genere moduli esterni).