Cominciamo col dire che Tanebaum, per i sistemi operativi, non è che sia proprio il massimo della vita.
Sono epici i suoi scontri con Linus su cosa deve fare un sistema operativo, come lo fa, e perchè funziona oppure no nel "mondo reale".
Grande attenzione quindi ad "abbeverarsi" ai guru (o presunti tali), soprattutto in campo accademico.
Da noi si diceva
"chi sa fare, fa"
"chi non sa fare, insegna"
"chi non sa insegnare, amministra"
"chi non sa amministrare, fa politica".
---
OK, tornando a bomba, visto che di SO "qualcosina" ne ho sviluppati, andando ultrasintetico...
1) un SO completo di gui richiede (oggi) milioni di ore-uomo, è diciamo così qualcosa tipo "come mi creo uno shuttle nel garage ?"
2) fermo questo punto non così irrilevante, ai "miei tempi" si scrivevano proprio i SO (rudimentali, s'intende) all'università, oggi non so (forse insegnano, a malapena, le tabelline).
Pensare di partire da 0, ma proprio 0, senza almeno un'infarinatura teorica, è diciamo così... coraggioso
3) è quindi del tutto irrealistico il progetto. Non è invece irrealistico acquisire una conoscenza "dietro le quinte", ossia diversa da "pigio un bottone esce una stampa".
4) per questo obiettivo (ben più realistico) le primissime (ma proprio basilari) funzioni che un SO "moderno" deve svolgere sono
-RESource. Gestione arbitrata delle risorse (e quindi tutti i problemi di deadlock, recovery, avoidance etc)
-CPU. Scheduling fair e unfair, algoritmi vari, applicazioni multiCPU
-MEM. Memoria virtuale.
-FS. File system. In realtà nel 99% dei casi oggi si usano FS già fatti, e ci si concentra sull'interazione memoria-cpu-risorse
-NET. Gestione networking (una volta non si trattava quasi, oggi è al centro di ogni progetto).
5) suggerisco quindi, con calma e sangue freddo, di partire dalla "base", ossia RES. Tanto per iniziare ad avere un'idea (vaga, ma sempre meglio di "avanti-avanti-avanti") di cosa succede dietro le quinte
I miei sono solo suggerimenti, s'intende...![]()

