[C] Programmare un Sistema Operativo

[cdimauro]

Originariamente inviato da Z80Fan

Fammi indovinare, AmigaOS-compliant e scritto in python?

No, AmigaOS non c'entrebbe nulla. Ma per lo più lo scriverei in Python.

Per quanto riguarda il driver VESA, ci sono due possibilità.

La prima è mettere nel primo MB di memoria delle apposite routine 8086 per richiamare i servizi int 10h del VESA. L'uso sarebbe il seguente:
- inizializzo un'opportuna zona di memoria coi dati condivisa e accessibile alla routine 8086;
- richiamo una routine per lo switch in real mode (dal protected mode) passandogli l'indirizzo della routine 8086 da eseguire;
- a questo punto viene eseguito il codice 8086 che richiama l'int 10h e memorizza nella zona di memoria "condivisa" i risultati;
- la routine 8086 richiama un'opportuna routine di servizio per il ritorno alla modalità protetta (nel punto successivo alla chiamata).

La seconda possibilità riguarda l'uso di task che gira in modalità Virtual 8086, che si occupa di eseguire il codice 8086 ivi compreso quello per richiamare i servizi VESA. In questo modo si eviterebbe lo switch del processo corrente dalla modalità protetta a quella reale, e poi il viceversa, perché verrebbe gestito tutto in maniera trasparente (e veloce, suppongo) dal processo Virtual 8086 e dal monitor Virtual 8086 (che gira in modalità protetta, ed è necessario per controllare il precedente processo).

Non ho scritto un monitor Virtual 8086, per cui non ti saprei aiutare per questa soluzione, ma in ogni caso preferirei la prima, che è molto più semplice da implementare, per i seguenti motivi:
- il codice per lo switch da e per la modalità reale è già disponibile;
- non devi richiamare in continuazione i servizi VESA (per ottenere l'indirizzo del frame buffer richiami una sola volta l'apposito servizio durante l'inizializzazione del driver; idem se vuoi ottenere l'elenco di tutte le modalità VESA disponibili, che puoi recuperare e inserire in una lista alla partenza del driver; l'impostazione di una modalità VESA la richiami una volta ogni morte di papa, per cui puoi benissimo eseguire lo switch protected <-> real una tantum, quando serve).

Originariamente inviato da idt_winchip

Ho lavorato in una azienda che sviluppa un sistema operativo embedded multipiattaforma opensource, BeRTOS

Quindi hai lavorato per Develer, suppongo. E magari mastichi qualcosina di Python.

[cdimauro]

Originariamente inviato da khelidan1980

io avevo trovato un os scritto in java, jNode,purtroppo ancora non capisco come fanno con le virtual machine(non usavano GCJ o robe simili), a quanto ho capito se ne sono scritta loro, è una barriera d'ingresso troppo alta a mio avviso per scrivere un os a scopo didattico in un linguaggio che non sia C/C++

Mah. A naso non mi sembra così complicato (ormai mi sono fatto le ossa con la VM di Python ).

Una volta realizzata l'apposita VM, penso che la strada dovrebbe essere tutta in discesa. Per lo meno utilizzando il più possibile codice Python.

E sai perché? Perché dopo la VM metterei in piedi una shell interattiva Python che mi permetterebbe di sperimentare pezzi di codice dall'interno dello stesso s.o., senza quindi il classico processo di:
- edita il file;
- compila;
- aggiorna la partizione della macchina virtuale;
- fai partire la macchina virtuale;
- esegui il codice.

Ancora più interessante per me è la possibilità di scrivere facilmente una batteria di test sfruttando dei mock per simulare le parti critiche del s.o..

Insomma, non la vedo una cosa così difficile. Anzi.

[khelidan1980]

Originariamente inviato da cdimauro

Mah. A naso non mi sembra così complicato (ormai mi sono fatto le ossa con la VM di Python ).

Una volta realizzata l'apposita VM, penso che la strada dovrebbe essere tutta in discesa. Per lo meno utilizzando il più possibile codice Python.

E sai perché? Perché dopo la VM metterei in piedi una shell interattiva Python che mi permetterebbe di sperimentare pezzi di codice dall'interno dello stesso s.o., senza quindi il classico processo di:
- edita il file;
- compila;
- aggiorna la partizione della macchina virtuale;
- fai partire la macchina virtuale;
- esegui il codice.

Ancora più interessante per me è la possibilità di scrivere facilmente una batteria di test sfruttando dei mock per simulare le parti critiche del s.o..

Insomma, non la vedo una cosa così difficile. Anzi.

si l'idea è molto stuzzicante sopratutto perche ti permette si usare un linguaggio moderno (python ruby o chi per esso),utilizzare tecniche moderne come il TDD...l'unica cosa è appunto,che prima di partire con l'os,bisogna smazzarsi la macchina virtuale!E non una vm qualsiasi,una che possa essere eseguita in un contesto un po particolare,tipo senza sistema operativo!

[idt_winchip]

Originariamente inviato da cdimauro

Quindi hai lavorato per Develer, suppongo. E magari mastichi qualcosina di Python.

Grande! Non ti sfugge niente!
Eh basta vedere con cosa è stato fatto il wizard per bertos..
Oppure il PyCon..

[cdimauro]

Originariamente inviato da khelidan1980

si l'idea è molto stuzzicante sopratutto perche ti permette si usare un linguaggio moderno (python ruby o chi per esso),utilizzare tecniche moderne come il TDD...l'unica cosa è appunto,che prima di partire con l'os,bisogna smazzarsi la macchina virtuale!E non una vm qualsiasi,una che possa essere eseguita in un contesto un po particolare,tipo senza sistema operativo!

Cheffà, stuzzichi?

In verità è da un bel po' che ci rifletto. Finito wpython magari faccio qualche esperimento, se ne ho ancora voglia.

Originariamente inviato da idt_winchip

Grande! Non ti sfugge niente!
Eh basta vedere con cosa è stato fatto il wizard per bertos..
Oppure il PyCon..

Dev'essere stata una bella esperienza.

[M4rk191]

Scrivere un SO che richiede una VM, non porterebbe a tempi di bootstrap lunghissimi? Il sistema risultante non sarebbe esageratamente lento?

Sicuramente sarà possibile implementare funzionalità avanzate in pochissimo tempo rispetto ai metodi tradizionali, ma le prestazioni?

[cionci]

Originariamente inviato da M4rk191

Scrivere un SO che richiede una VM, non porterebbe a tempi di bootstrap lunghissimi?

Non necessariamente.

Originariamente inviato da M4rk191

Il sistema risultante non sarebbe esageratamente lento?

Sicuramente sarà possibile implementare funzionalità avanzate in pochissimo tempo rispetto ai metodi tradizionali, ma le prestazioni?

Questo è un argomento un po' controverso. Tutte le implementazioni attuali o sono leggere perché con poche funzionalità o sono esageratamente lente.
In teoria con un compilatore JIT le prestazioni potrebbero comunque essere degne. Bisogna vedere come si andrebbe ad integrare l'uso di un compilatore JIT con il kernel. Sicuramente ci sarebbe un overhead non piccolo per il garbage collecting (se implementato) e per le peculiarità del linguaggio usato (un piccolo esempio può essere il bound checking nell'uso dei vettori, sempre presente nei linguaggi di alto livello).
Fra gli altri problemi da gestire ci sarebbe sicuramente la gestione delle eccezioni del linguaggio.

[cdimauro]

Originariamente inviato da M4rk191

Scrivere un SO che richiede una VM, non porterebbe a tempi di bootstrap lunghissimi? Il sistema risultante non sarebbe esageratamente lento?

No, non necessariamente. Prendi il WinUAE, che è un emulatore Amiga: AmigaOS emulato (che, come compito, è molto simile a una virtual machine: preleva opcode di un'architettura diversa da quella nativa, li decodifica, e li esegue uno alla volta) fa il boot in una manciata di secondi...

Sicuramente sarà possibile implementare funzionalità avanzate in pochissimo tempo rispetto ai metodi tradizionali, ma le prestazioni?

Non sono tutto. E comunque con meccanismi come JIT sarebbero decenti.

[Z80Fan]

Originariamente inviato da idt_winchip

Ciao Z80Fan, ho visto il tuo progetto, leggendo il titolo così entusiasta mi son detto: "eccone un altro" , e invece vedo che sei stato bravo.
Ho lavorato in una azienda che sviluppa un sistema operativo embedded multipiattaforma opensource, BeRTOS , ho dato un occhiata al vostro sorgente, per aver fatto tutto da soli siete stati davvero bravi.
Complimenti.
Mi iscrivo al thread perchè sono curioso degli sviluppi, se non avessi fin troppi problemi di tempo mi sarebbe piaciuto contribuire.
Davvero bel progetto, bravi!

Grazie

Originariamente inviato da cdimauro

Per quanto riguarda il driver VESA, ci sono due possibilità.La prima è mettere nel primo MB di memoria delle apposite routine 8086 per richiamare i servizi int 10h del VESA. L'uso sarebbe il seguente:
- inizializzo un'opportuna zona di memoria coi dati condivisa e accessibile alla routine 8086;
- richiamo una routine per lo switch in real mode (dal protected mode) passandogli l'indirizzo della routine 8086 da eseguire;
- a questo punto viene eseguito il codice 8086 che richiama l'int 10h e memorizza nella zona di memoria "condivisa" i risultati;
- la routine 8086 richiama un'opportuna routine di servizio per il ritorno alla modalità protetta (nel punto successivo alla chiamata).

Esatto, era la mia stessa idea

Originariamente inviato da cdimauro

La seconda possibilità riguarda l'uso di task che gira in modalità Virtual 8086, che si occupa di eseguire il codice 8086 ivi compreso quello per richiamare i servizi VESA. In questo modo si eviterebbe lo switch del processo corrente dalla modalità protetta a quella reale, e poi il viceversa, perché verrebbe gestito tutto in maniera trasparente (e veloce, suppongo) dal processo Virtual 8086 e dal monitor Virtual 8086 (che gira in modalità protetta, ed è necessario per controllare il precedente processo).

La vm86 la voglio completamente scartare, sia per la sua non semplicissima implementazione, sia perchè nei sistemi a 64bit non funziona.

Originariamente inviato da cdimauro

- il codice per lo switch da e per la modalità reale è già disponibile;
- non devi richiamare in continuazione i servizi VESA

Esatto. Vedo che quindi non abbiamo altra scelta

Aggiornamento
Mi servirebbero 2 favori:
- Qualcuno che legga velocemente come funziona il caricamento dei moduli da GRUB (la versione 1)
- Qualcuno che sappia leggere ed estrarre informazioni dai file ELF
Per fare ---> Caricamento moduli e inizio framework per kernel modulare

[fero86]

Originariamente inviato da cdimauro

Mah. A naso non mi sembra così complicato (ormai mi sono fatto le ossa con la VM di Python ).

Una volta realizzata l'apposita VM, penso che la strada dovrebbe essere tutta in discesa. Per lo meno utilizzando il più possibile codice Python.

E sai perché? Perché dopo la VM metterei in piedi una shell interattiva Python che mi permetterebbe di sperimentare pezzi di codice dall'interno dello stesso s.o., senza quindi il classico processo di:
- edita il file;
- compila;
- aggiorna la partizione della macchina virtuale;
- fai partire la macchina virtuale;
- esegui il codice.

Ancora più interessante per me è la possibilità di scrivere facilmente una batteria di test sfruttando dei mock per simulare le parti critiche del s.o..

Insomma, non la vedo una cosa così difficile. Anzi.

caro Cesare, é inutile che scrivi col tono di quello che ci sta riflettendo per la prima volta
lo sai perfettamente che i linguaggi managed sono il futuro anche nel settore dei sistemi operativi

[fero86]

Originariamente inviato da khelidan1980

l'unica cosa è appunto,che prima di partire con l'os,bisogna smazzarsi la macchina virtuale!E non una vm qualsiasi,una che possa essere eseguita in un contesto un po particolare,tipo senza sistema operativo!

finalmente un vero microkernel.

[fero86]

Originariamente inviato da cdimauro

Non sono tutto. E comunque con meccanismi come JIT sarebbero decenti.

in teoria mediamente uguali a quelle dei linguaggi compilati in codice nativo visto che alla fine sempre codice nativo vai ad eseguire, ma anche in virtu del fatto che la compilazione JIT si basa su profiling effettivo praticato in maniera automatica e sistematica a runtime.

poi certo, prima di giudicare in queste cose bisogna fare solamente una cosa: provare, vedere, misurare ed infine confrontare. ok, in effetti sono 4

[cdimauro]

Originariamente inviato da fero86

caro Cesare, é inutile che scrivi col tono di quello che ci sta riflettendo per la prima volta
lo sai perfettamente che i linguaggi managed sono il futuro anche nel settore dei sistemi operativi

Questo sì, ne sono più che convinto, ma il mio pallino rimane sempre Python, che pone delle sfide non di poco conto rispetto a C# o Java.

Originariamente inviato da fero86

in teoria mediamente uguali a quelle dei linguaggi compilati in codice nativo visto che alla fine sempre codice nativo vai ad eseguire, ma anche in virtu del fatto che la compilazione JIT si basa su profiling effettivo praticato in maniera automatica e sistematica a runtime.

poi certo, prima di giudicare in queste cose bisogna fare solamente una cosa: provare, vedere, misurare ed infine confrontare. ok, in effetti sono 4

Dipende anche dal linguaggio.

[fero86]

Originariamente inviato da cionci

(un piccolo esempio può essere il bound checking nell'uso dei vettori, sempre presente nei linguaggi di alto livello).

giustissimo, ma non vuol dire che non si possa risolvere. un buon inizio verso la soluzione a mio parere é fare la differenza tra vettore e buffer: chiamiamo vettore un array di dimensioni orientativamente piccole (per es. una dozzina di elementi) usato per scopi logici nel codice del programma, e chiamiamo buffer un array di dimensioni potenzialmente elevate il cui scopo é contenere dati, come ad esempio un'immagine, una sequenza audio o addirittura video (eventualmente tramite file mapping). é chiaro che il vettore deve essere gestito tramite bound checking mentre il buffer deve essere gestito tramite bulk operations efficienti (le stesse usate in NIO di Java).

[Z80Fan]

[OT]
Cose come queste non dovrebbero succedere in un sistema operativo "avanzato"
http://z80fan.altervista.org/immagin...oken-small.png
Possibile causa: il driver proprietario nvidia (lo schermo lampeggiava come se fosse stavo fuori sincronia, quindi presumo un errore nel driver)
Altro: mi sono sparite le icone del desktop ! Forse un bug nel server X.
Altro ancora: certe volte il sistema non risponde più ai comandi del mouse e tastiera, anche se il puntatore si muove correttamente. Sempre un possibile bug di X.
[/OT]

[zulutown]

Originariamente inviato da Z80Fan

[OT]
Cose come queste non dovrebbero succedere in un sistema operativo "avanzato"
http://z80fan.altervista.org/immagin...oken-small.png
Possibile causa: il driver proprietario nvidia (lo schermo lampeggiava come se fosse stavo fuori sincronia, quindi presumo un errore nel driver)
Altro: mi sono sparite le icone del desktop ! Forse un bug nel server X.
Altro ancora: certe volte il sistema non risponde più ai comandi del mouse e tastiera, anche se il puntatore si muove correttamente. Sempre un possibile bug di X.
[/OT]

X non è un OS

[Z80Fan]

Originariamente inviato da zulutown

X non è un OS

Io intendevo Ubuntu, infatti ho anche specificato "server X"

[Sgurbat]

Domanda da ignorante al cubo: come mai generalmente quando si progetta un OS vedo spesso che si usa un linguaggio "vecchio" e non OOP come C?

E' solo per questioni di prestazioni o ci sono anche altri motivi?

Ad esempio perchè non in C++, Java, Python, Ruby ecc.?

Tnx.

[M4rk191]

Originariamente inviato da Sgurbat

Domanda da ignorante al cubo: come mai generalmente quando si progetta un OS vedo spesso che si usa un linguaggio "vecchio" e non OOP come C?

E' solo per questioni di prestazioni o ci sono anche altri motivi?

Ad esempio perchè non in C++, Java, Python, Ruby ecc.?

Tnx.

Java, Python e Ruby necessitano di una VM, se leggi i post di cdimauro, capisci. Il C++ è OOP, ma l'approccio che si intende usare dipende dal programmatore. Riguardo alle prestazioni, non credo ci sia molta differenza, i compilatori sono "maturi" ormai, e il C++ esiste da prima che il linguaggio C divenisse uno standard. Gli altri sapranno darti motivazioni più valide, ma dalla mia ignoranza, questo posso dirti

[Z80Fan]

Originariamente inviato da Sgurbat

Domanda da ignorante al cubo: come mai generalmente quando si progetta un OS vedo spesso che si usa un linguaggio "vecchio" e non OOP come C?

E' solo per questioni di prestazioni o ci sono anche altri motivi?

Ad esempio perchè non in C++, Java, Python, Ruby ecc.?

Tnx.

Come dice M4rk191, Python, Java, Ruby necessitano di una macchina virtuale per girare, in quanto sono linguaggi interpretati (non Java ma è sempre bytecode che deve essere interpretato), quindi bisogna sviluppare una macchina virtuale che è tale e quale un kernel che stiamo sviluppando noi.
Il c++ è compilato, quindi non ha questo problema, ma ha molte particolarità che non vanno bene per la scrittura di un kernel, ti rimando a questa pagina http://wiki.osdev.org/C%2B%2B. Sostanzialmente sono i vari costruttori e distruttori e gli operatori new e delete che necessitano un supporto del sistema operativo, si possono bypassare ma non avevo voglia.
Il C è cmq un'ottima scelta per scrivere un sistema operativo, anzi, è stato fatto apposta per scrivere sistemi operativi (lo hanno inventato per scrivere la primissima versione di Unix, viste le limitazioni del BCPL e del B). Oltre a non avere troppi fronzoli come linguaggio, ti permette di avere un elevato controllo sull'hardware, senza modifiche da parte di un interprete. Cmq un sistema operativo lo puoi scrivere in qualsiasi linguaggio, anche in Basic, basta che hai un compilatore che te lo traduce.

Il nostro kernel sarà scritto in C, ma questo non vuol dire che anche i moduli debbano essere scritti in C. Dopo aver finito il kernel base si può scrivere qualsiasi macchina virtuale Java-Python-Ruby per scrivere i moduli (per la felicità di cdimauro e RyUzAkI )