Anche se la maggior parte del codice nel kernel Linux è scritto in C, ci sono ancora molte parti di quel codice che sono molto specifiche per la piattaforma su cui è in esecuzione e devono tenerne conto.
Un esempio particolare di ciò è la memoria virtuale, che funziona in modo simile sulla maggior parte delle architetture (gerarchia delle tabelle delle pagine) ma ha dettagli specifici per ciascuna architettura (come il numero di livelli in ciascuna architettura, e questo è aumentato anche su x86 con introduzione di nuovi chip più grandi.) Il codice del kernel Linux introduce macro per gestire l'attraversamento di queste gerarchie che possono essere elise dal compilatore su architetture che hanno meno livelli di tabelle di pagine (in modo che il codice sia scritto in C, ma prenda i dettagli dell'architettura in considerazione.)
Molte altre aree sono molto specifiche per ciascuna architettura e devono essere gestite con codice specifico per l'architettura. La maggior parte di questi coinvolge il codice in linguaggio assembly. Esempi sono:
-
Cambio di contesto :Il cambio di contesto implica il salvataggio del valore di tutti i registri per il processo che viene commutato e il ripristino dei registri dal set salvato del processo pianificato nella CPU. Anche il numero e il set di registri è molto specifico per ciascuna architettura. Questo codice è in genere implementato in assembly, per consentire l'accesso completo ai registri e anche per assicurarsi che venga eseguito il più velocemente possibile, poiché le prestazioni del cambio di contesto possono essere fondamentali per il sistema.
-
Chiamate di sistema :Il meccanismo mediante il quale il codice dello spazio utente può attivare una chiamata di sistema è solitamente specifico per l'architettura (e talvolta anche per il modello di CPU specifico, ad esempio Intel e AMD hanno introdotto istruzioni diverse per questo, le CPU più vecchie potrebbero non avere quelle istruzioni, quindi i dettagli per quelli sarà ancora unico.)
-
Gestori di interruzioni :I dettagli su come gestire gli interrupt (interrupt hardware) sono solitamente specifici della piattaforma e di solito richiedono una colla a livello di assembly per gestire le convenzioni di chiamata specifiche in uso per la piattaforma. Inoltre, le primitive per abilitare/disabilitare gli interrupt sono solitamente specifiche della piattaforma e richiedono anche codice assembly.
-
Inizializzazione :I dettagli su come dovrebbe avvenire l'inizializzazione di solito includono anche dettagli specifici della piattaforma e spesso richiedono del codice assembly per gestire il punto di ingresso al kernel. Sulle piattaforme che hanno più CPU (SMP), anche i dettagli su come portare online altre CPU sono solitamente specifici della piattaforma.
-
Primitive bloccanti :L'implementazione di primitive di blocco (come gli spinlock) di solito implica anche dettagli specifici della piattaforma, poiché alcune architetture forniscono (o preferiscono) diverse istruzioni della CPU per implementarle in modo efficiente. Alcuni implementeranno operazioni atomiche, altri forniranno un cmpxchg che può testare/aggiornare atomicamente (ma fallire se un altro scrittore è entrato per primo), altri includeranno un modificatore di "blocco" alle istruzioni della CPU. Questi spesso comportano anche la scrittura di codice assembly.
Ci sono probabilmente altre aree in cui è necessario un codice specifico per piattaforma o architettura in un kernel (o, in particolare, nel kernel Linux). Guardando l'albero dei sorgenti del kernel, ci sono sottoalberi specifici per l'architettura sotto arch/ e sotto include/arch/ dove puoi trovare altri esempi di questo.
Alcuni sono davvero sorprendenti, ad esempio vedrai che il numero di chiamate di sistema disponibili su ciascuna architettura è distinto e alcune chiamate di sistema esisteranno in alcune architetture e non in altre. (Anche su x86, l'elenco delle chiamate di sistema differisce tra un kernel a 32 bit e uno a 64 bit.)
In breve, ci sono molti casi che un kernel deve essere a conoscenza che sono specifici per una piattaforma. Il kernel Linux cerca di astrarre la maggior parte di questi, quindi gli algoritmi di livello superiore (come il funzionamento della gestione e della pianificazione della memoria) possono essere implementati in C e funzionare allo stesso modo (o quasi allo stesso modo) su tutte le architetture.
Oltre a eseguire il porting del kernel Linux, dovrai definire l'interfaccia binaria dell'applicazione (ABI) per i programmi "spazio utente" e porta i livelli più bassi dello stack software dello spazio utente. Linux è tipicamente utilizzato con componenti di spazio utente di basso livello del progetto GNU, di cui i più critici sono:
- Il compilatore, l'assemblatore e il linker C:GCC e GNU Binutils. Per un'architettura CPU completamente nuova, è necessario eseguire il porting di questo software prima ancora di iniziare il porting del kernel, poiché il kernel è esso stesso un programma C e deve essere compilato. Se esiste già il supporto "back-end" per la CPU della tua piattaforma, ma non con Linux come kernel del sistema operativo, hai sostanzialmente meno lavoro da fare e potresti essere in grado di farla franca rimandando la maggior parte del lavoro fino a quando il kernel non è attivo e in esecuzione.
- La libreria di runtime C:"GNU libc". Questa libreria include il codice che crea chiamate di sistema e interagisce in altro modo direttamente con il kernel.
- La libreria "interfaccia per funzioni esterne", libffi, che è un componente essenziale di molti interpreti di lingue di alto livello, ed esegue uno dei pochi compiti rimanenti che richiede una piccola quantità di linguaggio assembly scritto a mano.
Molti altri software hanno componenti opzionali dipendenti dalla piattaforma; ad esempio, la navigazione Web sarà sostanzialmente più veloce se scrivi primitive crittografiche ottimizzate a mano per NSS e OpenSSL per la tua nuova architettura CPU e back-end di compilazione just-in-time per IonMonkey e V8. Ma questi non sono essenziali per creare una nuova piattaforma.