Co se týče kódu jádra, kromě kódu specifického pro architekturu, kterého je velmi malá část (1% až 5%?), je veškerý zdrojový kód jádra společný pro všechny architektury.
O binárních souborech:
Ve většině distribucí Linuxu vmlinuz je symbolický odkaz, který ukazuje na skutečný kód jádra gzip; jako vmlinuz-3.16.0-4-amd64 . Jsem si jistý, že OP mluví o druhém, ale zmiňuje to první ve prospěch čtenáře.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
I když je skutečně pravda, že kód ARM je skutečně menší, i když jádra nebyla komprimována, kódy jádra v ARM jsou často vyráběny na zakázku a mají aktivovaného mnohem méně kódu než ve verzích protějšků Intel (např. Intel má spoustu grafické karty, i když jen moduly, zatímco obvykle se vlastní jádro ARM musí vypořádat pouze s tím, které je přítomno v SoC).
Navíc porovnávání již komprimovaných náhodných binárních kuliček nemusí vždy přinést pravdivé výsledky, protože podle nějaké podivné náhody se větší binární soubor může zmenšit kvůli určité optimalizaci komprese.
Takže ve skutečnosti, abyste mohli efektivně porovnat binární jádra, musíte je zkompilovat s identickými volbami a ponechat je nekomprimované (nebo dekomprimovat výsledný vmlinuzxxx soubor).
Spravedlivá shoda by byla porovnáním jiných, nekomprimovaných binárních souborů, například /bin/ls nebo /usr/sbin/tcpdump a navíc architekturu podobnou té, kterou se snažíme přizpůsobit (stroje ARM jsou stále z velké části 32bitové, nicméně již existuje několik 64bitových)
Netřeba dodávat, že stejný kód zkompilovaný v ARM bude vždy (daleko) menší, protože strojový kód ARM je kód platformy RISC. Má také menší podmnožinu instrukcí strojového kódu, což vede k menšímu kódu. Na druhou stranu, Intel má větší sadu instrukcí, a to také kvůli dědičnosti retro-kompatibility s více generacemi mikroprocesorů.
Z http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Koncepce RISC CPU je stará a je také velmi efektivní. V RISC CPU máte menší pracovní zátěž, kterou spouští každá instrukce, tyto instrukce jsou také velmi často rozděleny na I/O a paměť, aby se dále eliminovala režie. To umožňuje velmi efektivní využití času CPU a paměti, ale může také vyžadovat určitý objemný kód na straně softwaru, aby vše fungovalo. Když byl RISC poprvé vyvinut, byl to způsob, jak jít jednoduše proto, že přístup k paměti a HDD byl pomalý. Objemné a složité instrukce nalezené v x86 CPU byly na starších CPU těžkopádné a nedokázaly držet krok se systémy RISC.
Konverzace však není dostatečně přímá, protože čipy Intel jsou v dnešní době komplexní bestie a hluboko v pseudo-CISC vrstvě mají RISC strategie a návrhy, které dekódují a emulují operační kódy Intel, jak je známe.
Operační kódy ARM jsou také objemné, řekněme ve srovnání s MIPS, protože ARM je levný procesor se specializovanými instrukcemi určenými pro dekódování videa (je jim věnováno asi 30 % procesoru).
Jako krátké cvičení si vezměte binární soubor tcpdump a čtyři architektury Linuxu, ke kterým mám přístup:
MIPS 32 bitů -> 502,4 kB
ARM 32 bitů -> 718 kB
Intel 32 bitů (i386) -> 983 kB
Intel 64 bitů (x86_64) -> 1,1 M
Takže zpět k vaší původní otázce:
- Jádra ARM "narůstají" co do velikosti, protože architektura má menší rozmanitost základního hardwaru pro konkrétní distribuci.
- Avšak, což je mnohem důležitější, jejich velikost se snižuje, protože vytvořený kód je efektivnější a kompaktnější.
"Binární" jádra (vmlinuz nebo tak) jsou krátký úsek kódu, který dekomprimuje zbytek samotného komprimovaného jádra. Mají tolik společného, že velká část začátku souboru je stejná (takže se komprimuje do stejného).
Rozdíly ve velikosti zdrojových archivů je spíše irelevantní, většina změn z jedné verze na další jsou řádky změněny a přidány nové ovladače (a ovladače se v binárním jádře nezobrazují, používají se pouze na některých počítačích, a tedy typicky v externích modulech).