Perché ci sono così tanti kernel Android diversi (risposta tecnica per favore)

Android non è un kernel comune che viene utilizzato su tutti i dispositivi? Ad esempio CentOS verrà installato su Dell, HP e una varietà di altri hardware. Sicuramente ci sono diversi moduli ma è comunque CentOS.

Qual è il motivo per cui CyanogenMod è sempre "rotto"? Ho sempre sentito nei forum che stanno lavorando al porting di questo driver o quel driver. Se usassero lo stesso kernel i driver non funzionerebbero con esso? Vedo anche un milione di diversi tipi di kernel per diversi dispositivi.

I kernel variano da produttore a produttore. Molti di questi kernel provengono dalla linea pura di sorgenti di kernel disponibili su CAF, ciò che questi produttori fanno è prendere quelle fonti di stock, modificarle in base alla scheda / chipset utilizzata e implementare i propri driver.

Dai un'occhiata in giro, ci sono variazioni di touchscreen, variazioni di chipset wifi, per non parlare di accelerometro, sensori, batterie, bussola, suono, grafica.

Prendendo ad esempio un sorgente del kernel da HTC, non funzionerà su un Samsung e viceversa.

I produttori sono liberi di scegliere i vari bit che vengono incorporati nel circuito. Non ci sono regole rigide o veloci. Da qui il sacco di hacking / modifiche per far funzionare correttamente il kernel.

Non devi mai confrontarti con i kernel di distribuzione Linux desktop in cui sono presenti PCI, PCI-Express, SATA, VGA, SVGA, USB, Ethernet in quanto sono un gioco a sfera completamente diverso. La differenza principale con CentOS e il kernel Linux di Android è questa: TUTTI i driver sono compilati come moduli o integrati, quindi qualsiasi distribuzione Linux "funzionerà immediatamente". Ancora una volta, con le distribuzioni Linux desktop - hai un'architettura - x86 quindi un kernel Linux, ad esempio un PC Dell, può funzionare immediatamente su un Lenovo a condizione che i driver standard siano compilati.

Non dimenticare, nel mondo Android, ci sono variazioni del kernel create per specifici chipset ARM, come ARMv6, ARMv7, c'è TEGRA, c'è EXYNOS e sono binari incompatibili tra loro. Quindi se un kernel è compilato per TEGRA, dimenticalo, non funzionerà su ARMv7!

Il motivo per cui alcuni kernel su Android sembrano essere "rotti" dipende dal produttore. Alcuni (Zte è un ottimo esempio) rilasciano una fonte macellata che può essere compilata dalla fonte ma non si avvia a causa di un driver mancante non coperto dalla licenza GPLv2 o GPLv3. Questo è il problema, quindi alcuni hacker devono andare in giro per github alla ricerca di alcuni indizi; alcuni produttori, se non tutti, rispettano. L'attuale incarnazione del sorgente di Zte è presumibilmente 2.6.35.7, ma in realtà la sua base di sorgente 2.6.32.9 con molte modifiche non rappresenta quindi il vero sorgente del kernel per 2.6.35.7!

È qui che i produttori devono rilasciare le rispettive fonti, non solo per essere conformi a GPLv2 o versioni successive, ma piuttosto perché la comunità sia in grado di modificarlo, come l'aggiunta di funzionalità di overclocking.

Quindi ci sono hacking coinvolti dietro le quinte e molti problemi con i driver che cercano di farlo funzionare, e non è nemmeno facile eseguire il debug. Alcuni driver possono essere concessi in licenza incrociata, MA NON possono essere distribuiti a seconda della clausola e delle condizioni come negoziata.

Per fortuna, tutto è cambiato ora con la linea di fonti del kernel 3.xx, poiché i driver Android sono ora integrati nelle fonti tradizionali. Ma c'è un gotcha!

Prova a trasferire un kernel 3.xx su un telefono esistente che ha circa 12-18 mesi; Non una possibilità di una palla di neve all'inferno avrebbe funzionato, perché, a causa dei diversi fattori, le fonti 3.xx sono molto diverse dalla fonte 2.6.xe richiederebbero un sacco di hacking per farlo funzionare - dovrei sapere, ho provato porting della sorgente 2.6.38.6 per Zte Blade e fallito.

Allo stesso modo, l'ultima versione del kernel 3.0.1 - lavorando sul progetto ics4blade su Modaco, ha fatto numerosi tentativi per portarlo, ma questo è dovuto al semplice fatto che Zte ha fatto un brutto pasticcio del sorgente che ha reso quasi impossibile il porting .

L'architettura del PC è costruita attorno a parti di materie prime perché è nata come clone di un prodotto specifico, il PC IBM, che è stato specificamente progettato per essere compatibile con esso e quindi tra di loro. In generale, potresti prendere un programma o un dispositivo periferico da un PC compatibile e inserirlo in un altro e aspettarti che funzioni. Questa capacità è abbastanza utile che le persone hanno continuato a richiederla anche quando la tecnologia si è evoluta. È possibile inserire una scheda PCI Express in qualsiasi PC moderno proprio come si potrebbe inserire una scheda ISA in qualsiasi clone di PC.

Gli smartphone non hanno una storia simile. Sono progettati come prodotti monolitici, un sistema completo costituito da hardware e software che "funziona" così com'è. Non ci si può aspettare che le persone prendano le parti da un telefono e le inseriscano in un altro, quindi gli ingegneri non devono tenere conto dell'interoperabilità quando progettano i loro prodotti.

Anche all'interno dell'albero dei sorgenti del kernel Linux, c'è molta frammentazione nei driver per piattaforme ARM . Poiché i telefoni sono generalmente progettati a porte chiuse, i team di ingegneri di diverse società spesso finiscono per fare un lavoro duplicato, progettando sostanzialmente lo stesso hardware dei loro concorrenti e quindi scrivendo i propri driver per il proprio design. Una volta che hanno finito e il prodotto è stato rilasciato, vanno direttamente a lavorare su quello successivo; non vale la pena dedicare tempo a tornare indietro e riformattare i driver per i prodotti passati o fonderli con i driver della concorrenza. Il risultato è una pletora di driver unici per dispositivi simili ma non uguali.

Inoltre, gli smartphone di solito si basano su SOC che dispongono di hardware specializzato integrato con il processore. Per alcuni di questi, può essere più che una questione di caricare o meno un determinato driver; potrebbe essere necessario compilare il kernel nel suo insieme con opzioni di configurazione speciali per l'esecuzione su un SOC, che sono incompatibili con le opzioni speciali necessarie per l'esecuzione su un altro SOC.

Il motivo è che il kernel Linux di Android non viene generalmente compilato su Android stesso, ma deve essere compilato in modo incrociato da un altro computer. Ciò causa vari problemi, poiché la configurazione del dispositivo non è disponibile al momento della compilazione e non è possibile compilare un kernel generico con tutti i driver a causa della limitazione dello spazio (mentre la maggior parte delle distribuzioni desktop ha semplicemente compilato tutti i driver in moduli caricati da un initramfs) . Pertanto, gli sviluppatori hanno dovuto capire quali driver includere nel pacchetto per ciascun dispositivo specifico. Non solo, ogni driver in genere ha una dozzina di opzioni di compilazione per attivare o disattivare varie funzionalità del driver, e i produttori di solito non rilasciano la loro configurazione ufficiale (i peggiori trasgressori non hanno nemmeno open source i loro driver o non hanno mantenuto copia dei driver aggiornati).

La programmazione del driver è molto più difficile della programmazione dell'applicazione, in quanto non esiste un kernel che ti protegga dall'hardware instabile che ha requisiti di temporizzazione specifici in tempo reale e così via, e ciò significa che anche avere una diversa caratteristica di prestazione può far perdere il driver alcuni eventi in tempo reale dall'hardware; questi errori possono presentarsi come bug o problemi di prestazioni.

Un altro problema è l'incompatibilità binaria. Esistono due cause di incompatibilità binaria, la prima è il tipo di CPU, che è stato coperto bene da t0mm13b, ma l'altro problema che è più rilevante per il porting è l'incompatibilità ABI (interfaccia binaria dell'applicazione). Se i produttori non open source i loro driver, gli sviluppatori dovevano utilizzare il modulo compilato da una ROM di serie. Ciò solleva vari problemi di incompatibilità ABI, poiché i moduli driver stessi hanno aspettative specifiche riguardo, ad esempio, al layout della struttura e ai parametri di chiamata delle funzioni, e quando il kernel è compilato, non ha il file header per descrivere l'ABI al momento del driver è compilato, quindi gli sviluppatori hanno dovuto decodificare il driver per creare un file di intestazione o i file di intestazione nell'albero dei sorgenti potrebbero essere stati modificati pesantemente dal momento che il driver è stato compilato e gli sviluppatori hanno dovuto annullare quelle modifiche per rendere nuovamente compatibile il kernel con l'ABI del driver. A differenza della compilazione dal sorgente, la compilazione per il driver binario non attiverà l'errore di compilazione a causa della mancata corrispondenza dei parametri della funzione o dell'incompatibilità della struttura, semplicemente si arresta in modo anomalo sul dispositivo mentre è in esecuzione e il debug di questi problemi è molto difficile. Nel mondo dei PC, abbiamo familiarità con il casino che nVidia e ATi ci hanno lasciato, a causa della loro insistenza nel rilasciare driver solo binari, immaginiamo di avere quel casino per tutti i driver, immaginiamo il "divertimento" che crea.

Anche l'hardware del PC è generalmente meglio standardizzato rispetto all'hardware mobile, la maggior parte dei PC non ha bisogno di driver per vibratori, accelerometro, giroscopio, radio 3G, sensore di prossimità, NFC, ecc. Anche su dispositivi che hanno 3G, di solito si collega all'hardware usando standardizzato connessioni come PCMCIA o PCI-E.

Bene .... i driver e il kernel non sono esattamente gli stessi.

I driver sono ciò che controlla l'antenna cellulare, il wifi, il bluetooth, ecc. Questi sono driver proprietari perché il produttore deve creare un modo (i driver) per parlare con il proprio hardware.

Il kernel è un livello intermedio tra il sistema operativo / l'applicazione e i driver effettivi (o CPU o memoria o qualsiasi altro hardware). È ciò che consente al sistema operativo / alle app di interfacciarsi con questi componenti hardware.

Tutti i milioni di kernel che vedi non sono molto diversi tra loro. Tipicamente un programmatore / modder prenderà il kernel esistente e lo "ottimizzerà" per provare a ottenere una differenza di prestazioni. In sostanza si può dire che stanno solo adattando (per la maggior parte) la "configurazione" del kernel. Nel mondo Android, questi modder guardano principalmente: overclocking o underclocking dell'orologio della CPU (importante per risparmiare la batteria o cercare di eseguire la maggior parte delle applicazioni ad alta intensità di processo come gli emulatori di videogiochi o la riproduzione di video), oppure stanno guardando sotto- voltaggio (per prolungare la durata della batteria eseguendo la CPU al di fuori dei parametri impostati originariamente ... che varia in effetti da persona a persona perché non ci sono due CPU esattamente uguali al 100%).

I telefoni e altri dispositivi integrati non dispongono di un BIOS per fornire l'astrazione tra l'hardware e il sistema operativo, di conseguenza il sistema operativo viene compilato per l'hardware in cui è distribuito. Anche i dispositivi che usano lo stesso set di chip possono essere configurati in modi diversi (usando bus di comunicazione alternativi ecc.) \ Il risultato è che il kernel deve essere compilato di conseguenza. Poiché non si prevedono cambiamenti nell'hardware, non viene eseguito alcun rilevamento dell'hardware. Il kernel si avvia più velocemente ed è di conseguenza più piccolo - questo è un principio standard di un sistema operativo incorporato

CentOS si installa su hardware diverso, ma,

1. Sono tutti i PC che variano meno dei telefoni,
2. Un kernel Ubuntu, un kernel Debian e un kernel elementare sono tutti diversi sorgenti del kernel.

Per quanto riguarda il tuo secondo punto, vedi le risposte pubblicate in precedenza.