[C] Programmare un Sistema Operativo

[M4rk191]

Originariamente inviato da cionci

Non si può. Le estensioni dell'asm inline del GCC sono diverse da quelle del compilatore Microsoft.

Z80Fan: l'asm per forza di cose l'hai studiato per un assemblatore specifico. Esistono due grandi famiglie di assemblatori x86: quelli con la sintassi Intel e quelli con la sintassi AT&T.
La differenza principale, ma non la sola, sta nell'ordine in cui vengono presentati gli operandi.
In quello Intel:

Opcode Destinazione Sorgente

In quello AT&T:

Opcode Sorgente Destinazione

L'assembly inline del GCC è di tipo AT&T, quello inline del compilatore MS è di tipo Intel. Esistono anche assemblatori che supportano entrambi i formati (NASM).

Ne approfitto, ancora, per chiedere un'altra cosa

Quando le istruzioni C vengono tradotte in Assembly, il compilatore, utilizza solo istruzioni del set x86 comuni ai processori Intel, AMD, VIA, oppure utilizza i set d'istruzione relativi alla macchina in uso es. SSE4?

Giuro che la smetto con le domande

[cionci]

Originariamente inviato da M4rk191

Sarei curioso di vedere come è implementata la chiamata di sistema per l'accesso ai file di un SO UNIX, secondo voi la trovo se cerco nei sorgenti XNU/BSD?

Certo che la trovi.

[M4rk191]

Originariamente inviato da cionci

Certo che la trovi.

Intendo dire: tra tutti i file, come faccio a trovare quello/i giusto/i?
EDIT:
Sto cercando nei sorgenti di XNU e non riesco a trovare la chiamata di sistema.

[cionci]

Originariamente inviato da M4rk191

Quando le istruzioni C vengono tradotte in Assembly, il compilatore, utilizza solo istruzioni del set x86 comuni ai processori Intel, AMD, VIA, oppure utilizza i set d'istruzione relativi alla macchina in uso es. SSE4?

Dipende dalle opzioni che gli dai
Dai un occhio all'opzione -S e -march del compialtore GCC.

[Z80Fan]

Originariamente inviato da M4rk191

Riguardo alle estensioni era solo una curiosità, legata al fatto che, il kernel Linux ha bisogno di diverse modifiche per poter essere compilato, ad esempio, dal compilatore Intel (e non MS ).

Sarei curioso di vedere come è implementata la chiamata di sistema per l'accesso ai file di un SO UNIX, secondo voi la trovo se cerco nei sorgenti XNU/BSD?

Sicuramente la trovi, ma è molto più compliato: penso che la syscall prima faccia un controllo sulla validità del path, poi i permessi, poi chiama il filesystem adatto che a sua volta richiama il device giusto...

Originariamente inviato da M4rk191

Intendo dire: tra tutti i file, come faccio a trovare quello/i giusto/i?

A tentativi Probabilmente saranno tra le parti specifiche per l'architettura e si chiamerà syscall.c o simile.

Originariamente inviato da cionci

Z80Fan: l'asm per forza di cose l'hai studiato per un assemblatore specifico. Esistono due grandi famiglie di assemblatori x86: quelli con la sintassi Intel e quelli con la sintassi AT&T.
La differenza principale, ma non la sola, sta nell'ordine in cui vengono presentati gli operandi.
In quello Intel:
Opcode Destinazione Sorgente
In quello AT&T:
Opcode Sorgente Destinazione
L'assembly inline del GCC è di tipo AT&T, quello inline del compilatore MS è di tipo Intel. Esistono anche assemblatori che supportano entrambi i formati (NASM).

Infatti io parlavo del C, dove ho imparato su libri che non preferivano un certo compilatore ad un altro, quindi a livello di C c'è una buona portabilità.
Lo so anch'io che ci sono due famiglie di pensiero, infatti mi sono corretto subito:

Originariamente inviato da Z80Fan

Si ho scritto male, volevo dire che si può portare tranquillamente riscrivendo però le parti con l'assembly inline. Grazie

[M4rk191]

Originariamente inviato da cionci

Dipende dalle opzioni che gli dai
Dai un occhio all'opzione -S e -march del compialtore GCC.

lo farò

Per il momento ho trovato un file open.c, però dando una rapida occhiata, sembra che chiami proprio la funzione open, quindi o chiama ricorsivamente la funziona stessa, oppure la funzione è definita in un altro file.

Ecco il codice:

CUT

E' quello giusto secondo voi?
EDIT: Quasi sicuramente non è il file giusto, continuo a cercare.

[Z80Fan]

Originariamente inviato da M4rk191

lo farò

Per il momento ho trovato un file open.c, però dando una rapida occhiata, sembra che chiami proprio la funzione open, quindi o chiama ricorsivamente la funziona stessa, oppure la funzione è definita in un altro file.

Ecco il codice:

CUT

E' quello giusto secondo voi?
EDIT: Quasi sicuramente non è il file giusto, continuo a cercare.

Infatti non è quello giusto, sembra un normale programma per fare dei benchmarks, probabilmente usa open per aprire un file per generare un log...

[Rikiji]

Originariamente inviato da Z80Fan

Ah si mi son dimenticato di scrivere che ho inserito la nuova versione del kernel!

Novità nella 0.02a: il dma e il floppy funzionano bene (avevo cominciato anche una specie di cache associativa per le tracce del floppy, ma ora è temporaneamente disabilitata e incompleta perchè non era strettamente necessaria per lo sviluppo dei due componenti).

Il prossimo passo sarà portare la FAT12, cominciare a pensare al multitasking e implementare le funzioni di memory management già proposte da Rikiji

Bene!
Mettiamo ora su un server git per rendere più facile a tutti contribuire?

[Z80Fan]

Originariamente inviato da Rikiji

Bene!
Mettiamo ora su un server git per rendere più facile a tutti contribuire?

Non so bene come funziona un server git, le modifiche vengono aggiunte automaticamente o devono essere approvate? Perchè preferirei che i contributi passassero prima da me, giusto per controllare che rispettino le mie linee guida, per poter discutere con lo sviluppatore a proposito di alcune scelte fatte e anche per imparare un po'

Rikiji: Sto sviluppando la versione 0.02b e ho incluso il tuo "memory management", ho rinominato le tue 2 funzioni in kmallocPage e kfreePage, giusto per evitare conflitti se poi definiamo le kmalloc(long dimensione) ecc...

[Rikiji]

Originariamente inviato da Z80Fan

Non so bene come funziona un server git, le modifiche vengono aggiunte automaticamente o devono essere approvate? Perchè preferirei che i contributi passassero prima da me, giusto per controllare che rispettino le mie linee guida, per poter discutere con lo sviluppatore a proposito di alcune scelte fatte e anche per imparare un po'

Rikiji: Sto sviluppando la versione 0.02b e ho incluso il tuo "memory management", ho rinominato le tue 2 funzioni in kmallocPage e kfreePage, giusto per evitare conflitti se poi definiamo le kmalloc(long dimensione) ecc...

Si può usare sourceforge http://sourceforge.net/apps/trac/sourceforge/wiki/Git
Credo si possa tenere un branch "dev" aperto a una decina di persone e uno "revised" dove puoi scrivere solo tu, se vuoi ricontrollare tutto quello che viene inserito prima di inserirlo in "revised"...( ad esempio)
Si quelle sono solo le funzioni di allocazione della pagina fisica, puoi chiamarle anche allocphypage e freephypage per essere ancora più esplicito

[Z80Fan]

Originariamente inviato da Rikiji

Si può usare sourceforge http://sourceforge.net/apps/trac/sourceforge/wiki/Git
Credo si possa tenere un branch "dev" aperto a una decina di persone e uno "revised" dove puoi scrivere solo tu, se vuoi ricontrollare tutto quello che viene inserito prima di inserirlo in "revised"...( ad esempio)
Si quelle sono solo le funzioni di allocazione della pagina fisica, puoi chiamarle anche allocphypage e freephypage per essere ancora più esplicito

Capito... si cmq quindi non è aperto a chiunque l'aggiunta di modifiche, giusto? perchè questo anche mi interessava. Buona l'idea del dev e revised.
Tu hai già esperienza con questo tipo di strumenti? sapresti creare un account li a sourceforge?

Grazie anche per il suggerimento per le funzioni.

[Z80Fan]

Sarebbe utile se qualcuno si studiasse il capitolo 16 del manuale per il programmatore del '386:

http://z80fan.altervista.org/i386-pr...al.pdf.tar.bz2

Il capitolo in questione è "Mixing 16 and 32 bit code", e ci tornerà utile più avanti quando dovremmo implementare il driver VESA 3, poichè questo standard ha un (limitato) supporto per la modalità protetta, e ci farebbe comodo senza dover entrare nella modalità unreal o essere limitati a scegliere la modalità video all'avvio.

Stato della versione 0.02b:
Ho sistemato i file in apposite cartelle, così abbiamo più sezioni ordinate; adattato anche il makefile.
Scritti dei #define per i bit della gdt e idt.
Stò facendo:
- portare la fat dal programma linux stand-alone al kernel, convertire il C++ in C e aggiungere la lettura di file più grandi di 512 byte.
- finire la cache delle tracce del floppy

[cdimauro]

Originariamente inviato da Z80Fan

Sarebbe utile se qualcuno si studiasse il capitolo 16 del manuale per il programmatore del '386:

http://z80fan.altervista.org/i386-pr...al.pdf.tar.bz2

Il capitolo in questione è "Mixing 16 and 32 bit code", e ci tornerà utile più avanti quando dovremmo implementare il driver VESA 3, poichè questo standard ha un (limitato) supporto per la modalità protetta, e ci farebbe comodo senza dover entrare nella modalità unreal o essere limitati a scegliere la modalità video all'avvio.

Dovresti dirmi cos'è che esattamente t'interessa sapere. Insomma, qual è (o quali sono) il problema da risolvere per il driver VESA in rapporto all'esecuzione del codice in modalità protetta.

[Z80Fan]

Originariamente inviato da cdimauro

Dovresti dirmi cos'è che esattamente t'interessa sapere. Insomma, qual è (o quali sono) il problema da risolvere per il driver VESA in rapporto all'esecuzione del codice in modalità protetta.

Molto semplice: il driver VBE (Vesa Bios Extension) è un programma che si trova in ogni scheda video, e all'avvio si registra sull'interrupt 10h. Attraverso questo interrupt si possono eseguire tutte le funzioni messe a disposizione dallo standard vesa 3 (o almeno 2). Il problema è che queste funzioni sono fatte per lavorare in modalità reale (l'ultimo standard è del '98), e quindi sono scritte a 16-bit assumendo le funzioni tipiche dei registri di segmento ecc... C'è anche una limitata possibilità di chiamare queste funzioni dal codice protetto a 32 bit, ma non vale per tutte le funzioni e solo per quelle per cambiare la palette e poco altro. Quindi, dopo essere chiamati da grub ed essere già in modalità protetta, dovremo inizializzare cmq la gdt, idt e varie, quando dobbiamo inizializzare il video, mostriamo un menu (sempre protetta), verifichiamo la scelta, quindi copiamo una routine scritta a 16 bit (il kernel è caricato sopra il megabyte) nella parte bassa della memoria, ci portiamo in modalità unreal, disattiviamo gli interrupt (!!!), impostiamo attraverso l'int 10h tutto quello che ci serve e infine torniamo in modalità protetta. Da qui ora abbiamo il linear framebuffer che è solo una locazione particolare della memoria dove possiamo scrivere in qualsiasi modalità.
Ora sono in Windows (dopo tutto questo lavoro mi rilasso con una partita a Mercenari ), quando torno in Ubuntu ti fornisco alcuni siti che mostrano megli queste problematiche.

[cdimauro]

Ho capito. Quindi hai bisogno di chiamare l'int 10h dalla modalità protetta per lasciar sbrigare al driver VESA alcune cose.

Se non ho capito male, il primo MB di memoria è disponibile per lavorare in modalità reale.

Va bene, passami qualche link che butto un occhio e vedo cosa mi viene in mente (anche se pensavo già di utilizzare i registri PCI per vedere un po' dov'era mappata la memoria video, in modo da indirizzare l'intero framebuffer linearmente in modalità protetta).

[Z80Fan]

Originariamente inviato da cdimauro

Ho capito. Quindi hai bisogno di chiamare l'int 10h dalla modalità protetta per lasciar sbrigare al driver VESA alcune cose.

Se non ho capito male, il primo MB di memoria è disponibile per lavorare in modalità reale.

Va bene, passami qualche link che butto un occhio e vedo cosa mi viene in mente (anche se pensavo già di utilizzare i registri PCI per vedere un po' dov'era mappata la memoria video, in modo da indirizzare l'intero framebuffer linearmente in modalità protetta).

Esatto. Nel primo megabyte a partire da 0 ci sono dei buffer per il floppy, ma se facciamo tutto prima di inizializzarli non c'è problema. L'indirizzo del framebuffer si ottiene da una di quelle funzioni dell' int 10h, e dopo aver abilitato il linear frame buffer si ha un blocco di memoria lineare indirizzabile dalla modalità protetta (sennò nella modalità normale dobbiamo switchare una pagina di memoria da 64k). Visto che dici di saper lavorare col pci, che ne dici di scrivere un driver per inizializzare il controller, le periferiche, e quello che serve?
http://wiki.osdev.org/Getting_VBE_Mode_Info
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions
(in quest'ultimo in fondo trovi anche le specifiche per i vari standard ( prendi solo il 3 e al massimo il 2)

http://wiki.osdev.org/VGA_Hardware
Questo è se qualcuno vuole scrivere un driver VGA prima del VESA.

[cdimauro]

Originariamente inviato da Z80Fan

Esatto. Nel primo megabyte a partire da 0 ci sono dei buffer per il floppy, ma se facciamo tutto prima di inizializzarli non c'è problema. L'indirizzo del framebuffer si ottiene da una di quelle funzioni dell' int 10h, e dopo aver abilitato il linear frame buffer si ha un blocco di memoria lineare indirizzabile dalla modalità protetta (sennò nella modalità normale dobbiamo switchare una pagina di memoria da 64k).

Così è molto più facile.

Visto che dici di saper lavorare col pci, che ne dici di scrivere un driver per inizializzare il controller, le periferiche, e quello che serve?

Ho già un mio progetto a cui sto lavorando (anche in questo momento ), e poi onestamente se dovessi lavorare a un s.o. (ma dovrei clonarmi prima per trovare il tempo ) me lo farei da zero e sicuramente non Unix/POSIX-compliant (il nome ce l'ho già: Py. O.S. ).

http://wiki.osdev.org/Getting_VBE_Mode_Info
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions
(in quest'ultimo in fondo trovi anche le specifiche per i vari standard ( prendi solo il 3 e al massimo il 2)

http://wiki.osdev.org/VGA_Hardware
Questo è se qualcuno vuole scrivere un driver VGA prima del VESA.

Me li leggo appena posso e ti faccio sapere.

[Z80Fan]

Originariamente inviato da cdimauro

e poi onestamente se dovessi lavorare a un s.o. (ma dovrei clonarmi prima per trovare il tempo ) me lo farei da zero e sicuramente non Unix/POSIX-compliant (il nome ce l'ho già: Py. O.S. ).

Fammi indovinare, AmigaOS-compliant e scritto in python?

[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!

[khelidan1980]

Originariamente inviato da cdimauro

Ho già un mio progetto a cui sto lavorando (anche in questo momento ), e poi onestamente se dovessi lavorare a un s.o. (ma dovrei clonarmi prima per trovare il tempo ) me lo farei da zero e sicuramente non Unix/POSIX-compliant (il nome ce l'ho già: Py. O.S. ).

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++