[NOS] Kernel

[AmigaCori]

• 

Continuate, anche partendo da cose gia' dette nel thread generico su NsaOS in merito al kernel.

[clros]

• 

@dsar:
Potresti dirci qualcosa in più sugli OS "a layer"?

[AmigaCori]

• 

Ricordatevi che NOS deve essere, anzi dovrebbe essere, un OS realizzabile ed utilizzabile per uso desktop ma soprattutto che sia un qualcosa non a livello di disponibilita' di risorse di MS

Cioe' non deve essere l'OS utopico ma l'OS "migliore" per uso desktop che, essendo nuovo, non deve badare a compatibilita' con se stesso nel passato

[clros]

• 

Ovviamente per layer non mi riferisco a "layer di compatibilità"

..e da quello che ho capito nemmeno a layer tipo il modello ISO/OSI in cui tutti i layer servono obbligatoriamente per far funzionare correttamente il tutto. Penso tu ti riferisca a layer che aggiungono ulteriori funzionalità, un po' come fa swing con AWT su Java.

Questo puo' andare bene.  Ma concretamente, posiamo iniziare a definire cosa devono fare i layer di base (..e poi anche i layer superiori)?

[clros]

• 

Questo puo' andare bene.  Ma concretamente, posiamo iniziare a definire cosa devono fare i layer di base (..e poi anche i layer superiori)?

Certo, un primo step sarebbe quello di definire le interfacce lato kernel, per esempio definire un accesso generico all'hardware

Ok, qui però sono parecchio impreparato...Mi viene in mente qualcosa tipo le varie funzioni di Exec.library, ma l credo siano ad un livello un po' piu' alto rispetto a quello di cui stiamo discutendo...

[clros]

• 

Questo puo' andare bene.  Ma concretamente, posiamo iniziare a definire cosa devono fare i layer di base (..e poi anche i layer superiori)?

Certo, un primo step sarebbe quello di definire le interfacce lato kernel, per esempio definire un accesso generico all'hardware

Ok, qui però sono parecchio impreparato...Mi viene in mente qualcosa tipo le varie funzioni di Exec.library, ma l credo siano ad un livello un po' piu' alto rispetto a quello di cui stiamo discutendo...

[TheKaneB]

• 

Una struttura a layer è presente, bene o male, in qualsiasi OS. Il problema è che alcuni componenti non sempre rientrano perfettamente nella gerarchia, ed esistono componenti che dialogano con un layer più profondo di 2-3 livelli, piuttosto che con il livello immediatamente sottostante.

Un esempio concreto?

Layer hardware 3D
Layer OS Driver Model
Layer driver 3D
Layer API 3D (DirectX / OpenGL)
Layer Window Compositing (le finestre)
Layer GUI (il contenuto delle finestre)
Thread GUI dell'applicazione.

Ecco, in questo scenario (molto schematizzato e semplificato per scopi puramente accademici), se l'applicazione volesse fare uso di chiamate dirette OpenGL (magari un visualizzatore di modelli 3D), dovrebbe avere la possibilità di scavalcare un paio di layers ed arrivare direttamente al subsystem OpenGL / DirectX.

Sicuramente non è un esempio bellissimo, anzi ci sono varie scappatoie, in questo specifico caso, per far ritornare l'applicazione sulla sua struttura layered, ad esempio si può predisporre un widget "fake" nella GUI che bypassa tutte le chiamate al layer sottostante. Tuttavia ci sono numerosi altri campi in cui si rivela utile bypassare alcuni livelli.

In genere tale esigenza si mostra quando un'applicazione si ritrova nella situazione di sfruttare una risorsa a basso livello, quindi roba come codec audio/video implementati in hardware, hardware customizzato (ad esempio un "coso" USB per pilotare un aggeggio qualsiasi, con un suo programma di gestione che lo manipola a basso livello tramite interfaccia RS232).

Si possono creare delle escamotage per tutte queste situazioni, ma secondo me la struttura a layers non dovrebbe essere tassativamente obbligatoria, ma "caldamente consigliata". Secondo me sarebbe bene lasciare una porticina aperta per quelle applicazioni che potrebbero beneficiare di un controllo più a basso livello (non per forza a livello hardware, si potrebbero trovare esempi di più ampio respiro), per garantire una maggiore flessibilità agli sviluppatori.

[AmigaCori]

• 

Bella questa cosa di poter, all'occorrenza, saltare dei layer. Si potrebbe rivelare utile anche in situazioni un po' critiche come i sistemi PDA dove magari c'e' HW piu' dedicato che nei PC

Quindi lato kernel siamo su un kernel ibrido se usiamo il sistema classico dei driver video ove i driver sarebbero in kernel space per evitare decadimento di prestazioni oppure un micro kernel se utilizziamo UEFI?.

Riassumendo:
Personality (per risolvere il problema di avere SW)
Kernel ibrido?
Layer ma flessibili?

[TheKaneB]

• 

Il discorso dei layer, per come lo vedo io, sarebbe una "struttura" ma non un meccanismo. Cioè l'OS lo strutturiamo a layers, però senza implementare alcun meccanismo di segregazione che impedisca di saltarli.

Il kernel direi che dovrebbe essere un microkernel con alcuni driver critici in kernel-space, quindi direi video e network, che sono i due componenti che massacrano maggiormente l'OS con tonnellate di IRQ e syscalls (che ho già mostrato essere terribili in un microkernel).
Il resto comunque andrebbe buttato tutto in user-space.

Volendo, si potrebbe anche ipotizzare un networking-kernel che gestisce i driver di rete e che si intervalla con l'application kernel tramite un hypervisor.

Un meccanismo simile, che può sembrare astruso, viene usato in ambito embedded da anni. Ci sono infatti dei processori embedded che possono far girare 2 domini logici distinti, di solito uno dedicato alla User Interface e l'altro dedicato alla crittografia ed al networking, questi processori vengono usati ad esempio nei POS (le macchinette per pagare con carta di credito/bancomat al supermercato).

In questo modo potremmo avere un kernel dedicato solo al network che si smazza tutta la mole pesante di lavoro con uno scheduler hard-realtime, ed un application-kernel che gira in parallelo ad esso in un dominio logico distinto e comunica con il precedente tramite shared memory (gestito via hardware). Si tratta di un utilizzo "creativo" delle istruzioni di virtualizzazione già presenti in tutti i processori moderni, che rendono molto leggera la virtualizzazione della CPU.

Vi piace l'idea? ;-)

[clros]

• 

cosa intendi per "dominio logico"? Due core separati?

[AmigaCori]

• 

Due kernel, un application-kernel e l'altro dedicato al network, il networking-kernel che comunicano via HW tramite la memoria che e' quindi condivisa e sono gestiti dall'hypervisor?. Pero' non credo d'aver capito se sia cosi'

[TheKaneB]

• 

cosa intendi per "dominio logico"? Due core separati?

in gergo, un dominio logico è la "parte CPU" di una macchina virtuale.

Per fare una VM completa, bisogna emulare tutto l'hardware, se invece ci si limita a virtualizzare solo la CPU, allora si parla di domini logici.

In poche parole, la tecnica consiste nel dividere la CPU in 2 domini logici, senza emulare l'hardware come farebbe ad esempio VMWare, e far girare un kernel normale sul primo dominio e un kernel dedicato solo al networking sul secondo.

In questo modo non ci sono problemi di race conditions sull'hardware, in quanto non parliamo di OS generici (ciascuno con la sua rete, la sua grafica, il suo audio), ma di un OS "solo network" ed un OS che fa tutto il resto. Quindi non serve un'intera macchina virtuale, ma soltanto il dominio logico della CPU.

Possiamo quasi paragonarli a due processi, solo che la separazione è ancora più profonda, perchè ci sono due kernel distinti che girano sopra un hypervisor, e sotto i kernel ci sono i processi veri e propri.

Quindi invece di avere:

Hardware - Kernel - Processi

Abbiamo:

Hardware - Hypervisor - Dominio logico - Kernel - Processi

[Z80Fan]

• 

Secondo me non bisogna pensare troppo e solo a "layer", cioè a livelli, uno sopra l'altro.

È importante anche usare strategie più "peer-to-peer": nell'esempio portato da TheKaneB, ci dovrebbero essere i peer "applicazione", "gui manager" (gestore delle finestre), "composer delle finestre", "video API" (uno o più servizi esportati dalla scheda video che identificano varie API per la grafica, come OpenGL o D3D).

Un'applicazione, se vuole fare 3D nella finestra, avrà un apposito controllo "Graphics Frame", reso disponibile dal gui manager, a cui può inviare i suoi comandi grafici, che dal gui manager saranno passati al composer e infine alla api.
Se invece un'applicazione è in full-screen, ha il lock dello schermo, e quindi può inviare direttamente i comandi all'api, o meglio, al composer, per evitare che un'applicazione possa monopolizzare lo strumento in caso di bug o crash improvviso senza unlock della risorsa (che cmq un OS fatto bene dovrebbe prevenire).

Quindi in ultima analisi, l'api dovrebbe essere un layer, così come il composer, mentre le applicazioni e il gestore finestre dovrebbero essere allo stesso livello.

Il kernel direi che dovrebbe essere un microkernel con alcuni driver critici in kernel-space, quindi direi video e network, che sono i due componenti che massacrano maggiormente l'OS con tonnellate di IRQ e syscalls (che ho già mostrato essere terribili in un microkernel).
Il resto comunque andrebbe buttato tutto in user-space.

Io dico: un driver che deve stare in kernel-space, non ha bisogno di starci tutto. Come hai detto anche te, il motivo per cui si mettono i driver in kernel-space è perchè la gestione degli interrupt è rapidissima, essendo il kernel sempre mappato in memoria virtuale. Ma solo il codice dell'ISR ha bisogno di star li, di sicuro non il compilatore degli shader (rimanendo sul tema della grafica).

Perciò, la soluzione che avrei in mente è che un driver può essere suddiviso in due parti, comunicanti tramite un'area di memoria condivisa e ben delimitata (una per ogni coppia di driver), con una parte (snella il più possibile) che sta in kernel-space, e l'altra che sta in user-space.

Un esempio con le schede video: la parte superiore del driver prende i comandi e i dati dalle applicazioni, li pre-elabora, e li mette nella memoria condivisa (cosa che ha un bassissimo overheat), dove verranno prelevati dalla parte kernel e inviati alla scheda video nelle modalità e nelle tempistiche relative al dispositivo.

Similmente, una scheda di rete ÜberNet 9000, da 100 Tbps, avrà si un'inifinità di IRQ, ma tutto quello che deve fare il driver in kernel-space è leggere il buffer della scheda e mettere i dati in un buffer in ram, nella stessa area che è condivisa con la sua controparte user (e avvisare lo scheduler di svegliare il processo al massimo). Se siamo anche fortunati, la ISR deve solo avviare un'operazione DMA e l'hardware pensa al resto.

Volendo, si potrebbe anche ipotizzare un networking-kernel che gestisce i driver di rete e che si intervalla con l'application kernel tramite un hypervisor.

Il concetto è interessante; ma due (tre) kernel... troppo lavoro, non mi piace!
Cmq penso che si possa fare anche con un singolo kernel... si possono anche usare strategie di scheduling differente nel caso il processo/thread sia utente o kernel.

[TheKaneB]

• 

L'idea l'ho buttata giù pensando ad alcuni processori embedded che hanno la separazione dei domini logici via hardware, ed è praticamente trasparente (è come avere 2 CPU fisiche).
Chiaramente se implementato senza supporto hardware, basandosi solo sulla virtualizzazione, diventa pesante.

Tuttavia mi sembra una tecnica plausibile a livello server, dove le CPU vengono appositamente ottimizzate per la virtualizzazione.
Comunque meglio rimanere in ambito desktop/tablet/PDA per il NOS, altrimenti rischiamo di perdere di vista gli aspetti pragmatici e si cade troppo nell'accademico (che non amo particolarmente).

[clros]

• 

L'idea l'ho buttata giù pensando ad alcuni processori embedded che hanno la separazione dei domini logici via hardware, ed è praticamente trasparente (è come avere 2 CPU fisiche).
Chiaramente se implementato senza supporto hardware, basandosi solo sulla virtualizzazione, diventa pesante.

Ma..a qst punto...se avessimo a disposizione CPU multicore, non si potrebbe suddividere il lavoro sui 2 core senza appoggiarsi ad istruzioni di virtualizzazione?