Scelte 

Ares é ancora molto giovane e come tale rimane un progetto ancora aperto. 
In altre parole il sistema é ancora nella fase in cui si presenta ad uno stato indifferenziato.
Ció vuol dire che con le attuali scelte di fondo che riguardano le specifiche generali, l'uso della modalità protetta e l'indirizzamento della memoria si può approdare ad una qualunque scelta finale.

 Quello verso cui ci stiamo orientando é un sistema real time message-based. Ne dovrebbe derivare un prodotto finale molto agile e veloce la cui caratteristica fondamentale sarebbe quella di rispondere in modo quasi immediato alle chiamate di sistema e piú in generale alle richieste "esterne". Questa almeno é l'idea originale lanciata da Paolo ed in base alla quale stiamo muovendo i primi passi.

 In realtá tuttavia, visto lo stato attuale di avanzamento e la previsione di lunghissimi tempi di sviluppo (mancanza cronica di tempo) sono ancora possibili scenari alternativi. 
Un'idea che mi sta girando ultimamente in testa é ad esempio la possibilitá di creare un sistema basato sul concetto di macchine virtuali in modo da mettere a disposizione dell'utente finale tre o quattro diversi ambienti su cui poter installare piú sistemi operativi da far girare su console diverse.
In pratica l'utente finale dovrebbe avere a disposizione tre o quattro console su cui installare e far girare ad esempio Linux Windows e Os2 e dovrebbe poter passare dall'una all'altra semplicemente con una combinazione di tasti. 
L'idea sembra carina, ma non so se é realmente realizzabile e, anche se lo fosse presenterebbe un problema di fondo che forse inciderebbe troppo sulla effettiva utilizzazione.
Infatti, una volta che si trovassero a girare su macchine virtuali i vari sistemi ne risulterebbero sicuramente rallentati. Inoltre non oso pensare ai possibili conflitti e violazioni di condivisione che sicuramente ne deriverebbero. :-))

 Io e Paolo rimaniamo comunque aperti a qualunque suggerimento, idea e proposta in merito ed anzi ci auguriamo che arrivino commenti e che si sviluppino discussioni sul progetto. 

Naturalmente abbiamo deciso di realizzare un sistema che giri in modalitá protetta a 32 bit.
La configurazione della memoria sará del pari basata su tutte le potenzialitá messe a disposizione dalle ultime generazioni di processori e quindi si avvarrá di una struttura che affianca insieme segmentazione e paginazione (anche se si potrebbe pensare ad un modello di memoria lineare paginato...).
Abbiamo inoltre deciso (anche in seguito ad una piccolo sondaggio nel forum Unix di Mc-Link) di mantenere il sistema compatibile allo standard Posix e di rispettarne dunque pienamente specifiche e direttive.

 

  Struttura

Fermo quanto sin qui detto circa l'apertura del progetto, passiamo ora ad esaminare la struttura verso cui é orientato Ares quale sistema real time message based. 
Ci serviremo di alcuni concetti elaborati in un articolo di R. A. Burgess che ha il pregio di illustrare in termini molto semplici e chiari i meccanismi base del sistema.
Il lavoro essenziale di un sistema operativo consiste come noto nello eseguire e "schedulare" processi (o task).
In un sistema message based i processi ed il task scheduler comunicano tra loro tramite appunto l'invio di messaggi. 
Naturalmente i messaggi hanno bisogno di un luogo da cui venir prelevati dal destinatario in modo che non vadano persi quando quest'ultimo é impegnato in un'altra attivitá (si pensi al fin troppo evidente esempio della segreteria telefonica). Ne deriva che i processi possono trovarsi in tre stati generali. O sono in esecuzione, o sono "ready to run", oppure sono in attesa di un qualche messaggio (in futuro potremmo scoprire la necessita' di altri stati.
Poste dunque queste necessarie premesse possiamo delineare le prime chiamate di sistema atte a far funzionare il nostro meccanismo:

 - NewTask (creazione di un nuovo processo)
- SpawnTask (duplicazione processo padre)
- CreateMailbox (creazione mailbox del processo)
- SendMsg (invio messaggio)
- WaitMsg (attesa messaggio)
- CheckMsg (controllo messaggi)

 Sulla base di queste primitive possiamo giá ipotizzare un piccolo scenario relativo al funzionamento del kernel:

 Task1 é in esecuzione
Task1 crea la mailbox1
Task1 chiama SpawnTask (per avviare Task2)
Kernel controlla la prioritá del nuovo task
Kernel mette Task1 in condizione di ready-to-run
Kernel mette Task2 in esecuzione

 Task2 é in esecuzione
Task2 crea la mailbox2
Task2 invia messaggio a mailbox1
Kernel controlla se c'e' un task in attesa sulla mailbox1 (negativo)
Kernel inserisce il messaggio nella mailbox1

 Task2 é ancora in esecuzione
Task2 chiama WaitMsg sulla mailbox2
Kernel mette Task2 in attesa sulla mailbox2
Kernel valuta i Task ready-to-run
Kernel mette Task1 in esecuzione

 Task1 é in esecuzione
Task1 chiama WaitMsg sulla mailbox1
Kernel passa il messaggio dalla mailbox1 al Task1
Kernel valuta i Task ready-to-run (solo Task1 ready)

 Task1 é in esecuzione
Task1 invia messaggio a mailbox2
Kernel inserisce il messaggio nella mailbox2
Kernel mette Task1 in condizione di ready-to-run
Kernel mette Task2 in esecuzione (prioritá piú alta)

 etc...
etc...

 Come si vede da questo piccolo esempio, il meccanismo é assai semplice ed immediato. Naturalmente il tutto é stato descritto in modo molto semplificato e generico. Ma il passaggio all'implementazione non presenta comunque un grosso livello di complessitá sul piano pratico.

 Questo per ora é tutto, qualunque idea o commento saranno comunque ben accetti da me e Paolo sia direttamente in mailbox sia a mezzo di discussione pubblica nel forum "Unix" di Mc-Link.