Kärnor varierar från tillverkare till tillverkare. Många av dessa kärnor kommer från den rena kärnkällan som finns på CAF, vad dessa tillverkare gör är att ta dessa lagerkällor, ändra dem så att de passar utifrån kortet / chipset som används, också implementera sina egna drivrutiner.

Ta en titt runt dig, det finns variationer av pekskärmar, variationer av wifi-chipsets, för att inte tala om, accelerometer, sensorer, batterier, kompass, ljud, grafik.

Ta en kärnkälla från för exempel HTC fungerar inte på en Samsung och tvärtom.

Tillverkarna står fritt att plocka ut eller källa ut olika bitar som integreras i kretskortet. Det är inga hårda eller snabba regler inblandade. Därav mycket hacking / modifieringar för att få kärnan att fungera ordentligt.

Du får aldrig jämföra med Linux-distributionskärnor där den har PCI, PCI-Express, SATA, VGA, SVGA, USB , Ethernet eftersom de är ett helt annat bollpark-spel. De stora skillnaderna med CentOS och med Android Linux Kernel är detta - ALLA drivrutiner är sammanställda antingen som moduler eller inbyggda, all Linux-distribution kommer därför helt enkelt att "fungera ur lådan". Återigen, med Linux-distributioner på skrivbordet - du har en arkitektur - x86, därmed en Linux-kärna från säg en Dell-dator, kan fungera ur lådan på en Lenovo förutsatt att bog-standard-drivrutinerna är kompilerade.

Glöm inte, i Android-världen finns det variationer av kärnan byggd för specifika ARM-chipsets, till exempel ARMv6, ARMv7, det finns TEGRA, det finns EXYNOS, och de är binära inkompatibla med varandra. Därför, om en kärna är kompilerad för TEGRA, glöm den, den fungerar inte på ARMv7!

Anledningen till att vissa kärnor på Android verkar vara "trasiga" beror på tillverkaren. Vissa (Zte är ett mycket bra exempel) släpper en slaktad källa som kan kompileras från källan men inte startar på grund av en saknad drivrutin som inte täcks av GPLv2- eller GPLv3-licensen. Det är problemet, därför måste vissa hackare leta efter github och leta efter några ledtrådar; vissa tillverkare, om inte alla, följer det. Den aktuella inkarnationen av Ztes källa är enligt uppgift 2.6.35.7, men i själva verket representerar den faktiska 2.6.32.9-källbasen med många modifieringar således inte den sanna kärnkällan för 2.6.35.7!

Detta är där tillverkarna måste släppa sina respektive källor, inte bara för att vara kompatibla med GPLv2 eller senare, utan snarare för att samhället ska kunna modifiera det, till exempel att lägga till överklockningsmöjligheter.

Därför finns det hacking bakom kulisserna och mycket bråk med förare som försöker få det att fungera, och det är inte lätt att felsöka heller .. Vissa förare kan vara korslicensierade, MEN kan inte distribueras beroende på klausulen och villkoren som förhandlats fram.

Tack och lov ändras allt nu med kärna 3.x.x. linje av källor, eftersom Android-drivrutiner nu är integrerade i de vanliga källorna. Men det finns en gotcha!

Försök att portera en 3.x.x. kärna till en befintlig telefon som är ungefär 12-18 månader gammal; Inte en snöbolls chans i helvete skulle det fungera, det beror på att, av de olika faktorerna, är 3.xx-källorna väldigt annorlunda än 2.6.x-källan och skulle ta mycket hacking för att få det att fungera - jag borde veta, har försökt portering 2.6.38.6 källa för Zte Blade och misslyckades.

På samma sätt har den senaste kärnutgåvan 3.0.1 - när man arbetar på ics4blade-projektet på Modaco gjort många försök att porta det men det beror på det enkla faktum att Zte gjorde en mycket dålig röra av källa som gjorde det omöjligt att portera.

PC-arkitekturen är uppbyggd kring råvarudelar eftersom den började som kloner av en specifik produkt, IBM PC, som var särskilt utformade för att vara kompatibla med den och därför med varandra. Generellt sett kan du ta ett program eller kringutrustning från en PC-kompatibel och placera den i en annan och förvänta dig att den fungerar. Denna förmåga är tillräckligt användbar för att människor har fortsatt att kräva det även när tekniken utvecklats. Du kan placera ett PCI Express-kort i vilken modern dator som helst, som om du kunde sätta ett ISA-kort i vilken PC-klon som helst.

Smartphones har ingen sådan historik. De är utformade som monolitiska produkter, ett komplett system som består av hårdvara och programvara som "bara fungerar" som det är. Det finns ingen förväntan att människor ska ta delar ur en telefon och lägga dem i en annan, så ingenjörer behöver inte ta hänsyn till interoperabilitet när de utformar sina produkter.

Även inom Linux-kärnkällträdet, det finns mycket fragmentering i drivrutinerna för ARM-plattformar. Eftersom telefoner vanligtvis är utformade bakom stängda dörrar, slutar ingenjörsteam vid olika företag ofta att göra dubbla arbeten, utforma i princip samma hårdvara som sina konkurrenter och sedan skriva sina egna drivrutiner för sin egen design. När de är färdiga och produkten släpps går de direkt till nästa; det är inte värt sin tid att gå tillbaka och refaktora förarna för tidigare produkter eller slå samman dem med konkurrenternas förare. Resultatet är en uppsjö av engångsdrivrutiner för enheter som liknar men inte helt samma.

Dessutom är smartphones vanligtvis baserade på SOC som har specialiserad hårdvara integrerad tillsammans med processorn. För en del av detta kan det handla om att ladda en viss drivrutin eller inte; kärnan som helhet kan behöva byggas med speciella konfigurationsalternativ för att köras på en SOC, som är oförenliga med de specialalternativ som behövs för att köras på en annan SOC.

Anledningen är att Androids Linux-kärna i allmänhet inte kompileras på Android själv utan istället måste den kompileras från en annan dator. Detta orsakar olika problem, eftersom enhetskonfigurationen inte är tillgänglig under kompileringstiden, och det är inte möjligt att kompilera en generisk kärna med alla drivrutiner på grund av utrymmesbegränsning (medan de flesta skrivbordsfördelningar helt enkelt hade samlat alla drivrutiner i moduler laddade från en initramfs) . Därför var utvecklarna tvungna att ta reda på vilka drivrutiner som skulle paketeras för varje enskild enhet. Inte bara det, varje förare har i allmänhet ett dussin eller så kompilera tidsalternativ för att växla olika drivrutinsfunktioner, och tillverkare släpper vanligtvis inte sin officiella konfiguration (de värsta gärningsmännen öppnar inte ens sina förare eller höll inte uppströms kopia av drivrutinerna uppdaterade). Eftersom tillverkaren inte släpper sina konfigurationer kommer ofta den något annorlunda konfigurationen som utvecklaren använder att avslöja subtila buggar som inte finns med tillverkarens konfiguration.

Drivrutinsprogrammering är mycket svårare än applikationsprogrammering, eftersom det inte finns någon kärna som skyddar dig från den ojämna hårdvaran som har specifika tidskrav i realtid och sådant, och det innebär till och med att ha en annan prestanda karaktäristik kan få föraren att missa några hårda realtidshändelser från hårdvaran; dessa missar kan dyka upp antingen som fel eller prestandafrågor.

Ett annat problem är binär inkompatibilitet. Det finns två orsaker till binär inkompatibilitet, den första är CPU-typen, som har täckts av t0mm13b, men den andra frågan som är mer relevant för portning är ABI-inkompatibilitet (applikations binärt gränssnitt). Om tillverkare inte öppnar källkod för sina drivrutiner, måste utvecklare använda den kompilerade modulen från en lager-ROM. Detta väcker olika ABI-inkompatibilitetsproblem, eftersom drivrutinsmodulerna i sig har specifika förväntningar på till exempel strukturlayout och funktionsanropsparametrar, och när kärnan kompileras har den inte rubrikfilen för att beskriva ABI vid den tidpunkt då drivrutinen kompileras, så utvecklare var tvungna att omvandla drivrutinen för att skapa en rubrikfil eller så kunde rubrikfilerna i källträdet ha modifierats kraftigt eftersom drivrutinen kompilerades och utvecklare var tvungna att återställa dessa ändringar för att göra kärnan kompatibel igen med drivrutinen ABI. Till skillnad från att kompilera från källan kommer kompilering för binär drivrutin inte att utlösa kompileringsfel på grund av funktionsparameterfel eller strukturkompatibilitet, det kraschar helt enkelt bara din enhet medan den körs, och felsökning av dessa problem är mycket svårt. I PC-världen är vi bekanta med den röra som nVidia och ATi lämnade oss på grund av deras insisterande på att släppa bara binära drivrutiner, föreställ dig att ha den där röran för alla förare, föreställ dig det "roliga" det skapar.

PC-hårdvara är i allmänhet också bättre standardiserad än mobil hårdvara, de flesta datorer behöver inte drivrutiner för vibratorer, accelerometer, gyroskop, 3G-radio, närhetssensor, NFC, etc. Även på enheter som har 3G ansluter den vanligtvis till hårdvaran med standardiserade anslutningar som PCMCIA eller PCI-E.

Tja .... drivrutiner och kärnan är inte exakt samma.

Drivrutiner är det som styr cellantennen, wifi, bluetooth etc. Dessa är proprietära drivrutiner eftersom tillverkaren måste skapa en sätt (drivrutinerna) att prata med sin hårdvara.

Kärnan är en mellannivå mellan operativsystemet / applikationen och de faktiska drivrutinerna (eller CPU eller minne eller annan hårdvara). Det är det som gör att ditt operativsystem / appar kan gränssnitt med dessa hårdvarukomponenter.

Alla de miljoner kärnor du ser skiljer sig verkligen inte så mycket från varandra. Vanligtvis tar en programmerare / modder den befintliga kärnan och "tweak" den för att försöka få en skillnad prestanda ur den. Du kan i princip säga att de bara justerar (för det mesta) "konfigurationen" av kärnan. I Android-världen tittar dessa modderar främst på: över- eller underklockning av CPU-klockan (viktigt för att antingen spara batterilivslängd eller försöka köra de flesta processintensiva applikationer som videospelemulatorer eller videouppspelning), eller de tittar på under- spänning (för att spara batterilivslängd genom att köra din CPU utanför de ursprungliga inställda parametrarna ... vilket varierar från person till person eftersom inga processorer är 100% exakt samma).

Telefoner och andra inbäddade har inte ett BIOS för att ge abstraktion mellan hårdvaran och operativsystemet, vilket resulterar i att operativsystemet kompileras för den hårdvara det distribueras till. Även enheter som använder samma kretsuppsättning kan konfigureras på olika sätt (med hjälp av alternativa bussar etc.) \ resultatet är att kärnan måste kompileras i enlighet med detta. Eftersom det inte finns några förväntningar på förändringar i hårdvaran utförs ingen hårdvarudetektering. Kärnan startar snabbare och är mindre som ett resultat - detta är en standardprincip för ett inbäddat operativsystem

CentOS installeras på olika hårdvaror, men

1. Det är alla datorer som varierar mindre än telefoner,
2. En Ubuntu-kärna, Debian-kärna och Elementary-kärna är alla olika kärnkällor.

När det gäller din andra punkt, se svaren / svaren som publicerats tidigare.