MMU o TLB le consideri o si puo' forzare compilazione a salti relativi ?
Ci stavo pensando; praticamente dipende dal riuscire a fare funzionare il kernel sia con memoria virtuale, sia senza.
La *protezione* della memoria non è un gran problema (praticamente quando il kernel dice "imposta a sola lettura per il livello 3 questa area", il driver della cpu ignora la richiesta o riporta errore), mentre per la paginazione è un po' più complesso.
Cioè, non è che sia un gran problema fare un kernel che lavora in un singolo grande spazio di indirizzamento, ma è farlo in modo che sia più trasparente possibile.
Il kernel è diviso in 3 categorie: arch/platform/kernel. In kernel ci va tutto quello che è indipendente dalla piattaforma (scheduler, allocazione memoria, filesystem, ipc, network etc), in arch ci va tutto quello che è dipendente dall'architettura (i386, x86_64, ARM, PPC etc), e in platform ci va tutto quello che è dipendente dalla piattaforma (IBM PC, la tua board di fiducia... praticamente dove puoi fare più assunzioni possibili sull'hardware).
Il trick qua è poter spostare il più possibile della gestione dell'MMU nel driver CPU in arch/ in modo che il codice in kernel/ possa essere più generico possibile. Forse possiamo aggirare il problema fornendo in kernel/ 2 tipi di gestore di memoria (quello da usare può essere scelto durante la compilazione): uno che lavora con MMU, e l'altro che lavora senza; dato che tutti i bisogni di allocazione e gestione passano per questo modulo, la restante parte di kernel/ non deve pensarci su.
La famosa scheda UDOO che ho ordinato (che dovrebbe arrivare a settembre, ma vista la quantità di ordini arriverà probabilmente a inizio ottobre) monta sia un iMX.6 di architettura Cortex-A9, sia un SAM3X di architettura embedded Cortex-M3, perciò avrò l'hardware per testare anche contemporaneamente le due strategie.
Giusto per avere un'idea, che caratteristiche di memoria hanno le schede su cui vorresti eseguirlo?