SuperKernel !

[Z80Fan]

• 

Mentre contemplo se cominciare a "riscriverlo" in C++, ho pensato che sarebbe stato carino parlarvi del mio SuperKernel!

Ebbene si, sto scrivendo un sistema operativo! :dance:
(come metà della gente qui dentro :lol:)

L'idea è di un paio di anni fa, quando, per dar pace a tutte quelle idee che mi frullavano in testa, decisi di iniziare a scrivere un sistema operativo, inizialmente aiutato da un mio amico, che poi dovette lasciare per un bel po' il progetto, non prima però di avermi tirato fuori una bella libreria per gestire il FAT32.

L'idea di partenza era di fare un tipico clone linux, in modo da portare successivamente le varie applicazioni senza riscriverle; proseguendo lo sviluppo è diventato chiaro che io volessi fare le cose a ModoMio©, e quindi l'obiettivo finale ora è quello di fare un sistema operativo modulare, in modo da poterlo configurare incastrandoci dentro i vari moduli per personalizzare la funzionalità. Molto spazio sarà dato alle librerie, in modo da fornire un'interfaccia uniforme per le applicazioni, e possibilmente per i driver.

Quindi, la domanda eterna: monolitico o microkernel?
Beh, sempre per il ModoMio©, non ne ho idea!
Ovviamente, poichè devo farlo PiùMeglio™, ho pensato un bel po' su, e son venuto fuori con questa idea: un minikernel in kernel mode, e un monolitico modulare in user mode.
Che roba è??
Il contrario di Windows NT, e cioè: invece di fare un microkernel e portarlo in kernel mode, prendo un monolitico e lo porto in user mode. :ugeek:
Il monolitico in user mode è formato da una parte fissa, e da moduli, in parte simili a delle librerie dinamiche, che vengono caricati e inglobati in questo processo user mode (che può anche avere dei thread). Ovvero: i tipici "server" di un microkernel sono inglobati in un unico spazio virtuale, e possono chiamarsi senza passare dal sistema di messaggi.

L'unico problema sono i driver, almeno nell'architettura x86: come sapete di base supporta l' I/O isolato, però non permette di usare le istruzioni in/out dall'user land senza usare quella stupidata dell'hardware task switching (che tra l'altro non è supportato in AMD64, o x86_64, il quale alla fine deve prendere il posto dell'x86). Se i dispositivi fossero mappati in memoria, sarebbe solo questione di mappare nello spazio virtuale del driver (in user mode), e tutto funzionerebbe.
Poichè non voglio per nessun motivo portare codice non fidato in kernel mode, ho pensato a un compromesso: per le periferiche "legacy" e sempre presenti (tastiera, mouse PS/2, PIC, PPT, PCI etc...), i driver saranno inseriti nel minikernel e fatti funzionare da li; uno potrebbe compilarsi altri driver in kernel mode (perchè l'interfaccia è la stessa dell'user mode), però se si rompe son cavoli suoi.
Per tutti gli altri driver, si potranno generare dei messaggi destinati al minikernel, con indicate delle operazioni da compiere, che siano essi input, output, attendi tot tempo etc. Internamente si può spawnare un nuovo kernel thread che eseguirà queste operazioni, per poi tornare i risultati o gli errori al processo driver.
Ovviamente non tutti i programmi possono generare tali messaggi, solo i driver.


Ok, va bene la teoria, ma la pratica ??
In pratica non c'è nulla di tutto questo!
Attualmente il kernel si avvia (caricato da grub), il che è un buon inizio.
Configura il processore, setta le tabelle degli interrupt, la gdt etc., può avviare la paginazione, ha un sistema di allocazione della memoria di blocchi di dimensione variabile (cioè malloc()), ha un sistema per gestire i cosidetti "device" (cioè una prima idea di separazione dei moduli, che non penso sarà usato come modello definitivo, magari forse solo a uso interno), può gestire un framebuffer VESA, e può visualizzare testo sia nella solita modalità caratteri 80x25, oppure disegnando in modalità grafica.
Nei sorgenti ci sono anche la vecchia implementazione della FAT(12), che è stata lasciata da parte, driver per floppy e vga che non hanno mai funzionato (quello vga un pochino), e un accenno di virtual file system, con terminologie e idee prese leggendo informazioni su Linux, ma che non ha attualmente nessuna funzionalità, perchè ho scoperto che forse era meglio fare la gestione della memoria prima del filesystem!

Qui il progetto su SourceForge:
http://sourceforge.net/projects/superkernel/

E qui l'iniziale thread su Hardware Upgrade; è una bella lettura per chi ha un paio di orette libere.
http://www.hwupgrade.it/forum/showthread.php?t=2112102

Ora sto sistemando i sorgenti per programmare anche il minikernel in C++, perchè i vantaggi superano il piccolo lavoro supplementare necessario per supportarlo.
Spero di poter fare un nuovo commit prima possibile.

E' tutto per ora, ditemi cosa ne pensate e se volete maggiori informazioni!

[TheKaneB]

• 

E' tutto per ora, ditemi cosa ne pensate e se volete maggiori informazioni!

Sei sicuro? :-D

In una discussione da bar ti direi "figo, stai facendo un sistema operativo? Micidiale!", ma in una discussione da NSA ti direi:

1- L'architettura del monolitico in Usermode esiste già (cercati L4/Linux e anche Usermode Linux)
2- L'architettura suddetta è una PorcataAbominevole®, si usa soltanto per migrare dei processi legacy, dipendenti da un vecchio kernel monolitico, su una struttura basata su microkernel. In alternativa può essere usata come sistema di virtualizzazione dei poveri, che condivide tutti gli svantaggi della virtualizzazione (lentezza,  problemi di scalabilità su sistemi SMP, cattiva gestione dell'I/O) e nessuno dei suoi vantaggi (un interrupt gestito male in user mode può fare esplodere l'intera macchina host)
3- Il driver model previsto fa pena: non devono essere i drivers a rompere le scatole al kernel, ma essi dovrebbero registrarsi presso un dispatcher che provvederà a diramare le richieste in base alle "classi di servizio" richieste. In caso di interrupt o syscall, il kernel provvederà a riconoscere la classe di servizio (DMA, VFS, Network, Multimedia, ecc...) e ad inoltrare la richiesta direttamente al driver interessato (che si sarà registrato precedentemente). In questo modo ogni driver avrà almeno un thread, tale thread sarà in wait per un messaggio del kernel (un banale semaforo su una coda di messaggi) e il kernel provvederà a svegliarlo pushando un messaggio sulla coda e sbloccando il relativo semaforo (e rischedulando).

Ho in mente un driver model molto particolare, che sto sviluppando nella mia testa e che in teoria dovrebbe risolvere in modo efficiente il problema dei driver in user space. Si basa sul concetto di "attore", cioè un fantoccio in kernel mode che possiede i meccanismi per interagire con l'hardware (un attore per il bus PCI, uno per il bus AGP, uno per la RS232, ecc...) ma non le policies.
Il driver in User Mode si occupa di scrivere il "copione" (il protocollo di comandi necessari per compiere una determinata operazione) e comunica questo copione al suo attore corrispondente.
Un driver può a sua volta registrarsi come attore. In tal caso girerà sempre in User Mode.

Tale architettura si presta chiaramente ad una modellazione ad oggetti, ed è pensata infatti per tale tipo di implementazione. Tuttavia il mio scopo era implementarlo in Objective Pascal (o similare) e non in C++. Comunque visto che mi hai stuzzicato, posterò qualcosa di concreto più in là :-)

[TheKaneB]

• 

Il problema di Modula-2 è che gli unici compilatori che ho trovato sono per Amiga e non vengono sviluppati più da 15 anni...

Se trovi qualcosa di moderno che supporta ARM e x86_64 fammi un fischio :-)

[TheKaneB]

• 

gnu modula-2 ed opencm3 sono sviluppati e mantenuti

http://www.nongnu.org/gm2/download.html

ci sono i source per GCC 4.1.x
mi toccherebbe mantenere una vecchia toolchain basata su gcc 4.1 per poter utilizzare questo frontend... vediamo un po' che si può fare...

OpenCM3 invece sembra un pelo più aggiornato, ma la release 1.5 fatta dopo 9 anni dalla 1.4 e con un changelog scarsetto, mi fanno pensare ad un progetto morto o semi-morto... Ecco perchè mi ero buttato su FreePascalCompiler, più che altro per la sicurezza di avere un compilatore supportato ed aggiornato di continuo...

[Z80Fan]

• 

1- L'architettura del monolitico in Usermode esiste già (cercati L4/Linux e anche Usermode Linux)

Non ho mica detto che è una cosa nuova e innovativa. In secondo luogo, per essere più chiaro, l'architettura mia non è

Codice: [Seleziona]

applicazioni
userkernel
--------------
minikernelma è

Codice: [Seleziona]

applicazioni - userkernel
--------------
minikernelQuindi l'userkernel è come un'altra applicazione per il minikernel (con alcuni compromessi, ovvio), e le applicazioni lo vedono come un fornitore di servizi.
I driver poi sono processi separati, non inclusi nell'userkernel.

2- L'architettura suddetta è una PorcataAbominevole®, si usa soltanto per migrare dei processi legacy, dipendenti da un vecchio kernel monolitico, su una struttura basata su microkernel.

Tralasciando la virtualizzazione dei poveri, non ho capito gli svantaggi di questa architettura.

3- Il driver model previsto fa pena: non devono essere i drivers a rompere le scatole al kernel, ma essi dovrebbero registrarsi presso un dispatcher che provvederà a diramare le richieste in base alle "classi di servizio" richieste. In caso di interrupt o syscall, il kernel provvederà a riconoscere la classe di servizio (DMA, VFS, Network, Multimedia, ecc...) e ad inoltrare la richiesta direttamente al driver interessato (che si sarà registrato precedentemente). In questo modo ogni driver avrà almeno un thread, tale thread sarà in wait per un messaggio del kernel (un banale semaforo su una coda di messaggi) e il kernel provvederà a svegliarlo pushando un messaggio sulla coda e sbloccando il relativo semaforo (e rischedulando).

Che è quello che voglio fare io. Pensavi forse che i drivers stessero in un loop per chiedere lo stato della periferica?
Io ti ho descritto come voglio fare per superare il fatto che non posso fare operazioni di I/O dall'user mode, quindi le devo far fare al minikernel.

Ho in mente un driver model molto particolare, che sto sviluppando nella mia testa e che in teoria dovrebbe risolvere in modo efficiente il problema dei driver in user space. Si basa sul concetto di "attore", cioè un fantoccio in kernel mode che possiede i meccanismi per interagire con l'hardware (un attore per il bus PCI, uno per il bus AGP, uno per la RS232, ecc...) ma non le policies.
Il driver in User Mode si occupa di scrivere il "copione" (il protocollo di comandi necessari per compiere una determinata operazione) e comunica questo copione al suo attore corrispondente.
Un driver può a sua volta registrarsi come attore. In tal caso girerà sempre in User Mode.

Similmente a come voglio fare io!
Nel primo post ho descritto solo l'accesso alle porte di I/O, forse avrei dovuto parlare un po' più in generale. Diciamo che quello che ho descritto è un attore che opera sulle porte di I/O e riceve le richieste ("copioni") dai driver che hanno necessità di fare operazioni specifiche sulla periferica di loro competenza, che non possono fare attraverso altri attori (appunto PCI, AGP etc., che erano le "periferiche legacy e sempre presenti" di cui parlavo).

Tale architettura si presta chiaramente ad una modellazione ad oggetti, ed è pensata infatti per tale tipo di implementazione.

Proprio per questo ho voluto cominciare a usare il C++, usare gli oggetti porta troppi vantaggi rispetto a quelle poche cose che è necessario implementare.

[cdimauro]

• 

Non farti sentire da Torvalds... :lol:

@dsar: c'è qualche motivo per cui non apprezzi / ti piaccia FreePascal? Fra gli eredi del Pascal dopo quelli di casa Borland è fra i più gettonati e disponibile per parecchie piattaforme (persino per il GameBoy Advance, se non ricordo male).

[Z80Fan]

• 

Pian pianino, ho fatto delle modifiche: ora il kernel compila in C++ tranquillamente (ci sono ancora tutti i warning delle conversioni puntatore->intero, ma li sistemerò prima o poi, si tratta di fare qualche cast).
Gli oggetti funzionano tranquillamente, possono essere anche globali e del codice aggiuntivo si preoccupa di chiamare i costruttori e i distruttori.

Ho fatto una classe ostream, e istanziato un oggetto kout.

Ora sto lavorando su un blocco chiamato virtual memory manager, che gestisce i vari spazi virtuali; mi serve per poter gestire i moduli caricati all'avvio: avrò uno spazio virtuale per il kernel, dove mapperò (probabilmente partendo dalla fine della memoria) il modulo.
Ovviamente si riutilizza poi per gestire gli spazi virtuali dei processi.

[Z80Fan]

• 

Ho un problema da proporvi:
Stiamo migliorando il codice, "riscrivendolo" a oggetti. Fino a adesso abbiamo creato la classe Device, e creato la classe Keyboard che eredita da Device. Mentre scrivevo la classe Keyboard, ho pensato di creare una classe anche per rappresentare una ISR (Interrupt Service Routine), per poter usare gli oggetti nella gestione degli interrupt. Ho quindi creato la classe virtuale GenericISR che dispone di un metodo handle().

Fino a qui, tutto bene. Ora c'è un dettaglio delicato da discutere:
Prendendo sempre Keyboard come esempio: inizialmente, avevo fatto derivare Keyboard sia da Device, sia da GenericISR (con ereditarietà multipla). Però, pensandoci bene, lei è-una Device, e ha-una ISR. Quindi GenericISR sarebbe un membro di Keyboard.

Ma non posso usare direttamente GenericISR, perchè è virtuale pura. Dovrei creare una classe tipo KeyboardISR, e usare quella come membro di Keyboard.
Il programmatore del driver dovrebbe fare una "doppia" fatica (perchè deve creare due classi), ma vabbè, lo deve fare una volta sola...

Problema ultimo: la ISR, per essere un qualche modo utile, dovrebbe poter accedere ai dati di Keyboard. Ora però l'handler è in una classe diversa!
Bisognerebbe passare a KeyboardISR il puntatore this a Keyboard, e poi rendere KeyboardISR una friend di Keyboard, o creare metodi per accedere ai dati, che però potrebbero potenzialmente essere usati dall'esterno, cosa che non si desidera...

Pensate che stia facendo un gran casino? Io penso di si!
Avete qualche idea di come impostare la faccenda? Questa parte è abbastanza essenziale, quindi bisogna pensarla bene prima di continuare.

[Z80Fan]

• 

Data la moltitudine di device che ci saranno ti consiglio di creare una classe Device e una classe DeviceFrames che conterrà la lista dei device type presenti nel kernel (non so se conosi la tecnica).

Probabilmente ho già una cosa simile: ho i vari "Device" e poi un DeviceManager che contiene la lista dei device che vengono registrati.

Le classi IS le devi organizzare come single-inheritance (gerarchico), l'object composition HAS è safe usarlo con il multiple inheritance bloccato ad un livello.

Si, alla fine "Keyboard" (o qualsiasi altro device) non sarà più virtuale, quindi non c'è problema nell'usare ereditarietà multipla.

In ogni caso l'object composition è una tecnica alternativa di encapsulation all'inheritance, quindi ciò che dici tu non si può fare (il composed object non può vedere in alcun modo gli state di chi lo possiede).

Infatti. A dire il vero, il fatto che la classe "interna" debba poter vedere l'"esterna" mi è venuto in mente mentre scrivevo il post, quindi lo ho scritto lo stesso, anche se non mi piaceva per niente.

E' meglio organizzarlo come independent component del kernel (un servizio) in cui tu registri i Device (ecco che qui la classe DeviceFrames ti viene in aiuto). Mettere l'handler come componente della classe device la vedo problematica come soluzione, anche perché per gli usi futuri che farai degli ISR ti servirebbe osservare gli state anche di altri device

Quindi, se ho capito bene, dici di: mettere un metodo di handling nel Device (o inserendolo come funzione virtuale in Device e gestire un'ereditarietà singola, o come virtuale pura in GenericISR e eredità multipla Device+GenericISR); il device che ha bisogno di gestire un interrupt si registra; Il DeviceFrames (o Manager, quel che sia), al momento dell'interrupt, chiama il device che si è registrato per quel IRQ?

Se intendi questo, è proprio quello che volevo fare.

[Z80Fan]

• 

Eccomi, scusa ma nei giorni precedenti avevo da fare.

No, non ti conviene mettere in alcun modo quegli oggetti in relazione, perché poi trovi difficoltà a gestire casi come per esempio più device nello stesso interrupt,

Non ho sentito casi di periferiche diverse sullo stesso IRQ number; ma anche in questa evenienza, quando una periferica si registra per un certo IRQ, la segno in un vettore insieme a tutte le periferiche che si son registrate in precedenza (per quel IRQ number); quando avviene un interrupt, attivo le diverse routine in sequenza finchè non mi trovo una routine che mi dice che l'interrupt era di una sua periferica e lo ha gestito.
Dovrò si scorrere le routine in sequenza, ma non mi aspetto di avere più di 2-3 device contemporaneamente mappati a uno stesso IRQ.

In un ipotetico sistema dove tutte le periferiche condividono un bus e hanno una sola linea di interrupt (potenzialmente PCI o USB? non lo so), conviene molto di più creare un Device "bus master", e gli altri Device dedicati a ogni periferica si registrano a lui (in qualche modo).

Il problema è che l'interrupt handler dovrebbe avere certi gradi di libertà sui device, non sottostare ai device.

Ma scusa, ogni handler è specifico per ogni periferica; l'handler del controller SATA è specifico solo per il Device "sata_controller", come l'handler per la tastiera è specifico solo per il Device "keyboard".
Se per "interrupt handler" intendi la primissima routine che viene chiamata al momento di un interrupt: quella è già indipendente, ed è quella che controlla quale IRQ è scattato e richiama gli handler nei Device che si sono registrati per quel determinato IRQ durante la loro inizializzazione.

Come ho detto prima conviene che gestisci l'interrupt handler come un componente indipendente del kernel in cui registri i device. Ogni interrupt handler all'interno del componente ha un DeviceFrame con tutti i device che dipendono da quell'interrupt.
Le comunicazioni tra device ed interrupt handler avvengono con un metodo Signal o Notify (scegli tu) del device, in cui (come parametro di output) comunica quello che deve comunicare all'interrupt handler.

A proposito di polling dato che con gli interrupt li userai tantissimo conviene che gestisci il tuo design OOP sugli interrupt in maniera diversa. Creare una classe KernelEvent (ti servirà parecchio in futuro) da cui derivare poi InterruptEvent. I device la comunicazione a segnali la gestiranno tramite InterruptEvent dichiarandone una propria, per esempio InterruptEventKeyboard (per la tastiera), che in più avrà i flagset o quel che sia che serviranno all'interrupt handler della tastiera.

Il tuo componente per la gestione degli interrupt handler dovrà solo interpretare gli InterruptEvent dei vari device registrati.

Quello che mi sfugge (ed è il motivo per il quale non riesco a comprendere pienamente la tua tecnica) è: dov'è che viene messo il codice dell'handler? Banalmente: dov'è che leggo la porta della tastiera per leggere il tasto premuto?
Nell' InterruptEventKeyboard? Quindi lo scrittore deve predisporre 2 classi, ok. Però l'InterruptEventKeyboard poi come fa ad accedere ai dati di Keyboard (per registrare nel buffer il tasto premuto ad esempio) ?

[Z80Fan]

• 

Non c'eri ai tempi di Windows 95 che non sapeva gestire gli IRQ condivisi?

Si, ma avevo 4 anni .

Qui sono stato poco chiaro io intendo che non è il device che deve stabilire la comunicazione, ma qualcun altro.
Che l'handler sia specifico per ogni periferica è chiaro, io intendevo che chi gestisce l'interrupt deve essere uno solo.

Ho già una singola unità che mi gestisce gli interrupt; il mio problema non è di architettura, ma semplicemente come organizzare i metodi all'interno degli oggetti.

Su FreeBSD la componente del kernel che gestisce gli interrupt è un framework basato sui bus ed i resource, che sono molto generici. Questo permette di separare i dettagli dell'architettura dalla periferica e dal tipo di comunicazione (pci, usb, etc).

Questo è una buona cosa, vedrò anche io di fare una cosa simile.

Quando scrivi un driver su freebsd, l'interrupt handler lo scrivi tu ma poi viene gestito dal framework del bus:
http://www.freebsd.org/cgi/man.cgi?query=bus_setup_intr

int BUS_SETUP_INTR(device_t dev, device_t child, struct resource *irq, int flags, driver_filter_t *filter, driver_intr_t *ithread, void *arg, void **cookiep);

con BUS_ALLOC_RESOURCE crei e riservi una risorsa interrupt e dopo gli assegni l'handler con il parametro driver_intr_t *ithread, la comunicazione verrà gestita dal bus manager.

Ecco, con quella funzione colleghi un device, un handler e un IRQ assieme, e se il mio kernel fosse in C, sarebbe come avrei fatto: un puntatore al device, uno alla funzione che fa da handler, e un'indicazione per l'IRQ che desidero. Non c'è nessun problema, perchè quando la funzione ha il puntatore al device, può fare quello che vuole.
Ma io sto scrivendo in C++, e voglio avere un sistema a oggetti. Se facessi in quel modo (avendo un oggetto device, un oggetto intHandler e il numero dell'irq), dovrei mettere i dati interni del device come pubblici, in modo che l'oggetto intHandler possa accedervi; ciò però non permette al device di proteggere i suoi dati da codice esterno che con lui non ha nulla a che fare. Non posso neanche mettere delle funzioni get/set perchè non devono poter essere usate da tutti, ma solo da intHandler. Se gli oggetti fossero separati, dovrei almeno dichiarare intHandler come friend di device, ma ciò non mi entusiasma molto. La seconda opzione era quella di creare un singolo oggetto che eredita sia da device sia da intHandler, così i dati interni di device si possono accedere da intHandler (o meglio, dal metodo handle() che viene richiamato dal gestore centrale degli interrupt quando si è verificato l'interrupt richiesto).

Io sono newbie sul fronte sistema operativi, ho letto qualche libro ma non ho mai implementato nulla di serio.

Non ti preoccupare, sei stato lo stesso di grande aiuto.

Secondo me dovresti basarti su qualche driver model esistente,

Questa discussione mi ha spinto a cercare più informazioni, possibilmente degli schemi. Di FreeBSD ho trovato poco, però ho trovato dei documenti che spiegano l'I/O kit di MacOS X e su Windows. Ho dato un'occhiata anche a WDF, che da un esempio di driver base non sembrava male, ma non mi piace il fatto che hanno progettato un sistema object-oriented e poi gli hanno dato un'interfaccia in C. D'accordo che volevano prendere la maggioranza dei programmatori, ma non penso sarebbe stato un trauma per i programmatori C imparare quelle 4 cose di C++ necessarie per scrivere il driver.

magari quello che ti piace di più ed ha il più basso rapporto pregi/difetti

Forse volevi dire "il più alto rapporto pregi/difetti" .

[cdimauro]

• 

Ho dato un'occhiata anche a WDF, che da un esempio di driver base non sembrava male, ma non mi piace il fatto che hanno progettato un sistema object-oriented e poi gli hanno dato un'interfaccia in C. D'accordo che volevano prendere la maggioranza dei programmatori, ma non penso sarebbe stato un trauma per i programmatori C imparare quelle 4 cose di C++ necessarie per scrivere il driver.

Perché non c'è solo il C++. Un'interfaccia "C" è utilizzata come "lingua franca" per esporre API "consumabili" da tutti gli altri linguaggi.

Se, invece, definisci un'interfaccia C++ per esporre le tue API, queste saranno "consumabili" da ben pochi linguaggi.

[Z80Fan]

• 

Perché non c'è solo il C++. Un'interfaccia "C" è utilizzata come "lingua franca" per esporre API "consumabili" da tutti gli altri linguaggi.

Se, invece, definisci un'interfaccia C++ per esporre le tue API, queste saranno "consumabili" da ben pochi linguaggi.

Ora non voglio iniziare un'altro discorso su quale linguaggio è il più figo, ma in cosa li vorresti scrivere dei Device Driver?

[cdimauro]

• 

Delphi o FreePascal.

[TheKaneB]

• 

Delphi o FreePascal.

:clap:  :banana-linedance: