[C] Programmare un Sistema Operativo [Archivio]

Z80Fan

26-12-2009, 11:27

[EDIT: Questa presentazione è un po' vecchia e non rispecchia gli sviluppi fatti (ce ne sono stati alcuni molto importanti), per i sorgenti aggiornati scorrere un po' in giù questo post.]

Salve a tutti !

Io e un mio amico stiamo scrivendo un kernel che dovrebbe essere compatibile a livello di API con Linux. Ovviamente non intendiamo sviluppare tutte le Api subito, ma almeno quelle base per poter avere almeno bash, poi ci sarà tempo per ampliare ;)
Lo stato attuale del Kernel è questo:

Si avvia da un floppy :D (tramite grub)
Ha il supporto per gli interrupt base (timer, keyb)
Ha una piccola libreria per gestire lo schermo (ancora in modo testo 80x25)
Supporto per il floppy impostato (ci sono ancora dei dettagli da sistemare, qualche controllo in più sugli errori e aggiungere il supporto DMA ISA) (la periferica peggiore che abbia mai programmato :D ) [EDIT: Ho deciso di tralasciare il floppy per via della sua difficoltà di programmazione, vedere pag. 10]

Non ancora inclusa nel kernel ma programmata e testata separatamente è una libreria per la gestione della FAT12 praticamente finita (basta aggiungere una funzione per caricare in un buffer file più grandi di un settore, e al massimo il supporto per i nomi lunghi) [EDIT: Inclusa e funzionate]

Il sistema di sviluppo è GNU/Linux (Ubuntu ma non è importante), con compilatore gcc, utility make e assemblatore nasm.

Gli obiettivi per la versione 1.0 sono i seguenti:

Supporto alle API di base POSIX e che permettano di far eseguire qualche programma standard GNU (es. Bash, gcc, ...)
Supporto all'hardware di base del pc ( floppy, PIC, APIC, PCI, HDD, DMA, qualche altra sigla :D ...)
Supporto alle modalità video VESA
Tutta l'infrastruttura per avere un kernel "modulare"
Completo supporto alla specifica "multiboot"

Il kernel sarà di tipo "modulare": all' avvio il bootloader caricherà un kernel minimale che successivamente caricherà i moduli vari per gestire il sistema ( filesystem, video, network, ecc).
TUTTI i moduli lavoreranno in User Mode, l'unico pezzo che sarà in kernel mode sarà un piccolo kernel (volevo evitare il termine "microkernel" per non generare confusione ;) ), non accessibile direttamente dalle applicazioni, che verrà chiamato dai moduli sovrastanti per gestire operazioni privilegiate. Oltre a ciò gestirà il multitasking (quindi scheduler e quello che gli và dietro) e la gestione della memoria. Tutto il resto sarà in user mode, le chiamate di sistema non causeranno un switch perchè il gestore degli interrupt sarà anch'esso in user mode. Così si assicura una buona protezione.
Tutto ciò sembra un microkernel, ma, una volta che i moduli sono stati caricati e gli indirizzi delle funzioni sono stati inseriti in apposite tabelle, diventa di fatto un kernel monolitico, solo che lavora in user mode; poi si può sempre attuare qualche modifica e farlo diventare una specie di microkernel "orientato alle procedure" (come tra l'altro è, in misura minore, il kernel linux, che ha dei punti dove può essere interrotto)

La richiesta che faccio in questo forum è se qualcuno ha informazioni sull' hardware PC, tutorial, datasheet, pezzi di codice, esperienza diretta, per favore me lo faccia sapere, possibilmente qui sul forum cosicchè (è scritto giusto?) altri possano beneficiarne.

Se qualcuno ha voglia di contribuire alla codifica, posso dargli un compito specifico da portare avanti.

Spero di essere stato chiaro e di non essermi dilungato troppo :D
Saluti!

--- Download versione attuale: ---
Pagina su SourceForge dove poter scaricare i sorgenti aggiornati e le immagini disco (https://sourceforge.net/projects/superkernel/)

Versione 0.06: (in git corrisponde al branch cpp_conv)
- Tradotta gran parte del codice in C++
- Nuovi sistemi per gestione dispositivi e interrupt orientati agli oggetti

Versione 0.05:
- Ho dimenticato di aggiornare il post e ora non ricordo più cosa ho fatto... :stordita:

Versione 0.04d3:
- Allocatore delle memoria completato

Versione 0.04d:
- Migliorato gestione della memoria:
- Paginazione funzionante
- Allocatore di pagine funzionante anche sotto paginazione
- Funzione per aggiungere pagine nuove allo spazio virtuale del kernel
- Allocatore di blocchi di dimensione arbitraria (kmalloc)
- Ora il kernel gira tutto in modalità paginata !

Versione 0.04c:
- Migliorato il supporto alle modalità video VESA
- Cominciata paginazione

Versione 0.04b:
- Sistemato supporto LFN della FAT12
- Inserita una sottospecie di shell

Versione 0.04a:
- Inserito supporto (incompleto) per VGA (non Vesa) 640x480x16 e 320x200x256

Versione 0.04:
- Inserito supporto RamDisk
- Inserito Device Manager
- Cominciato il parsing della tabella Multiboot
- Cominciato a gestire la modalità video VESA

Versione 0.03a:
- Implementato lettura da filesystem FAT12

cionci

26-12-2009, 14:22

Molto interessante, complimenti.

Se tutto gira in user mode ti risulterà quindi facile anche testare i vari moduli direttamente sul sistema di produzione. Bello...

Rikiji

27-12-2009, 15:23

Bello, anzi bellissimo!
Se mai pubblicherete il sorgente ci giocherò un po' di sicuro.
Non posso dirvi purtroppo "contribuirò allo sviluppo" perchè non ho tempo libero a sufficienza al momento per entrare in un progetto del genere, ma dalle funzionalità che hai descritto siete partiti bene :)

Ryuzaki_Eru

28-12-2009, 13:50

Parteciperei volentieri nel tempo libero, ma le poche conoscenze di C che avevo sono chissà dove nel mio cervello :D

Z80Fan

28-12-2009, 16:20

Ragazzi grazie per tutti i complimenti!
Ho aggiunto il link per scaricare la prima versione del kernel.
Come è scritto nel README all'interno, è ancora sotto sviluppo e carente in molte parti, ma sono fiducioso nelle mie capacità ;)
Fatemi sapere cosa ne pensate!

Bye Bye!

Ryuzaki_Eru

28-12-2009, 19:27

Ma non avevi detto che era in C? A me sembra scritto in C++.

khalhell

28-12-2009, 20:27

Complimenti per il lavoro, specialmente le risposte agli errori con la parolaccia finale, fantastica!;)

Tommo

28-12-2009, 20:38

Ero partito come "no ancora un altro nabbo che vuole programmare il nuovo linux" :asd:
Ma invece vedo che avete messo su un bel progetto coi piedi per terra, molto interessante :D
A capire qualcosa di system programming sarebbe stato bello aiutare...

PS: ma non è un lavoro immane andare oltre la scrittina che lampeggia su schermo nero?

Kralizek

28-12-2009, 20:56

chiamate DanieleC88!!!

ndakota

29-12-2009, 00:56

Ma non avevi detto che era in C? A me sembra scritto in C++.

I due file in /fat sono .cpp, tutti gli altri in /kernel sono .c. E lui parlava del kernel.

Z80Fan

29-12-2009, 08:18

Ma non avevi detto che era in C? A me sembra scritto in C++.
I due file in /fat sono .cpp, tutti gli altri in /kernel sono .c. E lui parlava del kernel.
Come dice ndakota, i file del kernel vero e proprio sono in C, ma lo stile di programmazione (sempre del kernel) è cmq orientato al c++ (p.es i commenti // e la dichiarazione di un "oggetto" struttura senza precederlo con "struct", cioè scrivo "my_struct myvariabile;" invece di "struct my_struct myvariabile", e dichiaro la variabile iteratore di un for all'interno del for stesso; tutte cose vietate nel C se non nel C99 )

Complimenti per il lavoro, specialmente le risposte agli errori con la parolaccia finale, fantastica!;)
Questo perchè non mi sono ancora "espresso" pienamente nella scrittura dei commenti, poi vedrai che robe! :Prrr:

PS: ma non è un lavoro immane andare oltre la scrittina che lampeggia su schermo nero?
Sicuramente :sofico: ma sono fiducioso nelle nostre capacità e (semmai il progetto prenda piede) nella possibilità di interessare alcuni programmatori Linux. Se poi a nessuno interesserà, me lo terrò per me come sistemino da usare su computer scrausi ;)

clockover

29-12-2009, 09:24

Sottoscrivo il thread perchè voglio seguire la cosa.... mi interessa

zulutown

29-12-2009, 09:29

capisco a livello educativo fare una piccola prova.. per imparare.

ma poi sinceramente non condivido per nulla il "proseguire" negli sviluppi quando già esistono un milione di OS opensource che non aspettano altro che nuovi volenterosi programmatori

Z80Fan

29-12-2009, 11:51

Sottoscrivo il thread perchè voglio seguire la cosa.... mi interessa
Grazie!

capisco a livello educativo fare una piccola prova.. per imparare.

ma poi sinceramente non condivido per nulla il "proseguire" negli sviluppi quando già esistono un milione di OS opensource che non aspettano altro che nuovi volenterosi programmatori
Non posso che essere d'accordo con te.
Ma la mia idea di proseguire nel progetto è data da molti miei pensieri nati sopratutto da questi punti:
- Vedo sempre le cose in grande (grandissimo)
- I sorgenti di Linux sono veramente complicati allo stato attuale.
- Il kernel monolitico tutto in kernel mode è un'architettura vecchia, e con i vari moduli anche non-free (nVidia?), c'è il rischio di codice pericoloso.
- Avevo molte idee di come si fosse potuto scrivere
- Volevo fare in modo che Linux prendesse piede come OS, convincendo gli sviluppatori a mettersi d'accordo e creare degli standard che potessero veramente creare una totale compatibilità tra distro e una piattaforma uniforme su cui scrivere driver per incentivare anche gli sviluppatori di hardware (perchè senza driver non si và da nessuna parte)
Mettendo tutto ciò assieme, ho pensato "un codice è meglio di 1000 parole (:D), perchè non comincio a scrivere del codice per dare un'idea agli sviluppatori veramente bravi?"
L'idea finale è di creare un sistema operativo base, parecchio commentato e documentato, consistente in kernel, applicazioni di utilità, una shell e una primitiva interfaccia grafica, tutto senza eccessive funzionalità ma funzionante e con la base pronta, diciamo il "framework", e spedirlo a qualcuno di rilevante nella Linux Foundation (Torvalds?), per vedere se possa essere accettato.

Questa è la mia visione. Non siamo più negli "anni della rivoluzione", una persona non può più rivoluzionare il mondo. Tutto ciò può rimanere un sogno di un ragazzo che programma nel tempo libero, o può diventare una realtà di decine, centinaia, migliaia, milioni di persone. A voi la scelta.

(Tu mi dirai: "ma se loro sono programmatori veramente bravi, non ci avranno già pensato?" E io risponderò "Boh")

(caspita che poeta :sborone: , ma va là, programmiamo per divertirci! :Prrr: )

(Come vedi Tommo, l'idea di partenza era tutt'altro che con i piedi per terra ;) )

PS: so che esistono altri os open source, sono partito con linux perchè è quello il mio target; è anche vero che molti altri os open source rimangono a un livello base di funzionalità, pochi sono veramente seri (Haiku?).

Ryuzaki_Eru

29-12-2009, 12:40

Complimenti per il lavoro, specialmente le risposte agli errori con la parolaccia finale, fantastica!;)

:confused: :confused:

I due file in /fat sono .cpp, tutti gli altri in /kernel sono .c. E lui parlava del kernel.

E' stata la prima cartella che ho avuto per le mani, poi sono dovuto uscire ;)

Z80Fan

29-12-2009, 12:54

:confused: :confused:

Riga 97 del file main.c :Prrr:

Ryuzaki_Eru

29-12-2009, 13:00

C'era un main? :asd:
Ho guardato solo la cartella fat, al più presto guarderò gli altri file. Di sicuro c'è che ora dovrò trovare il tempo per rinfrescare e incrementare le mie conoscenze di C, la cosa mi stuzzica non poco :D

blackgin

29-12-2009, 13:05

Buone le idee e bellissimo progetto

Z80Fan

29-12-2009, 13:09

Buone le idee e bellissimo progetto
Grazie!

clockover

29-12-2009, 13:28

Riga 97 del file main.c :Prrr:

Io le metterei in dialetto! :D :D

A parte gli scherzi, sto studiando da qualche mese Sistemi Operativi e vederne nascere da zero uno è un'opportunità per me di imparare!

Z80Fan

29-12-2009, 13:47

Io le metterei in dialetto! :D :D

A parte gli scherzi, sto studiando da qualche mese Sistemi Operativi e vederne nascere da zero uno è un'opportunità per me di imparare!

Ah Ah! :rotfl:

Cmq sei il benvenuto! Chiedi pure qualsiasi cosa. :)

Rikiji

29-12-2009, 13:57

Z80Fan

29-12-2009, 14:05

Bello! Sto dando un'occhiata al codice... perdonami se farò qualche domanda ovvia :)

se non sbaglio guardando negli header ELF il kernel viene copiato in 0x100000 no..? grub passa in qualche modo la dimensione dell'immagine copiata o c'è un modo per recuperarla, così da sapere a che indirizzo fare riferimento per la memoria da utilizzare? ( 0x100000 + kernel size?)

Penso sia all'interno della tabella multiboot passata da GRUB,
http://en.wikipedia.org/wiki/Multiboot_Specification
Dai un'occhiata alla specifica, io la ho passata velocemente qualche tempo fa, ma non ci sono rimasto troppo su perchè dovevo seguire un altro tutorial, e mi sembra di ricordare che passa molte (troppe :D) informazioni.
Cmq nessuna domanda ovvia (anzi, mi hai fatto tornare in mente una cosa) e come dico a tutti sei il benvenuto ;)

P.S. controlla anche il file link.ld per vedere la mappa di memoria

SaintTDI

29-12-2009, 14:05

rispondo solo per farti tanti complimenti per il progetto che stai facendo :) purtroppo non ho l'esperienza adatta in C per aiutarti... ma magari mi leggo l'evoluzione del thread!

complimenti! ;)

Z80Fan

29-12-2009, 14:06

rispondo solo per farti tanti complimenti per il progetto che stai facendo :) purtroppo non ho l'esperienza adatta in C per aiutarti... ma magari mi leggo l'evoluzione del thread!

complimenti! ;)

Grazie! Avere così molti sostenitori mi commuove :cry: ;)

Dom77

29-12-2009, 14:16

You have my virtual support :yeah:

Rikiji

29-12-2009, 14:52

Ho scritto una semplicissima implementazione di un memory manager per il tuo kernel :)
Dimensione delle pagine fissa a 4KB, traccia delle pagine allocate e non tramite la bitmap kmeminfo.bitmap. Dalla tabella multiboot di grub ho rimediato oltre alle dimensioni della memoria tutta un'altra serie di informazioni che al momento non ho approfondito :)

In questo archivio trovi il source completo http://rikiji.it/data/kernel.tar.gz
nuovi file: kmalloc.c, kmalloc.h multiboot.h (preso da gnu.org)
editati: main.c, Makefile
il resto è intatto.

Queste sono le funzionalità che ho aggiunto, ho scritto il tutto mentre pranzavo quindi non aspettatevi chissà che virtuosismi :D
#include <kmalloc.h>

int kmalloc_init (unsigned long lower, unsigned long upper) {
kmeminfo.lo_mem = lower;
kmeminfo.hi_mem = upper;
}

/* TODO:
* locks!
* different page size con buddy system?
* ho dato per scontato che gli indirizzi siano unsigned long */

void * kmalloc () {

int page;
unsigned long mask = 1;

page = first_free_page();
if ( page < 0)
return NULL;
else {
/* set page */
mask = mask << (page%sizeof(unsigned long));
#ifdef DEBUG_KMEM
printf("%d\n",kmeminfo.bitmap[(int)(page/sizeof(unsigned long))]);
#endif
kmeminfo.bitmap[(int)(page/sizeof(unsigned long))] = kmeminfo.bitmap[(int)(page/sizeof(unsigned long))] | mask;
return (void *) GETPAGE(page);
}
}

void kfree (void * p) {

int page;
unsigned long mask = 1;

page = GETINDEX( (unsigned long) p);
mask = mask << (page%sizeof(unsigned long));
mask = ~mask;
#ifdef DEBUG_KMEM
printf("%d\n",kmeminfo.bitmap[(int)(page/sizeof(unsigned long))]);
printf ("mask: %x\n",mask);
printf("zero: %d\n",kmeminfo.bitmap[0]);
#endif
kmeminfo.bitmap[(int)(page/sizeof(unsigned long))] = kmeminfo.bitmap[(int)(page/sizeof(unsigned long))] & mask;
#ifdef DEBUG_KMEM
printf("zero: %d\n",kmeminfo.bitmap[0]);
#endif
}

int first_free_page() {

int i,k = 0;
unsigned long u;

#ifdef DEBUG_KMEM
printf("bitmap 0: %d\n",kmeminfo.bitmap[0]);
#endif
for (i=0;i<BITMAPSIZE;i++) {
if (~(kmeminfo.bitmap[i])) {
/* free page found, dig to find bit */
u = kmeminfo.bitmap[i];
while (u & 1) {
u = u >> 1;
k++;
}
return i*sizeof(unsigned long) + k;
}
}
return -1;
}

#define PAGESIZE 4096
#define PAGENUMBER 15625
#define GETPAGE(p) ( p*PAGESIZE + kmeminfo.lo_mem )
#define GETINDEX(i) ( (i - kmeminfo.lo_mem) / PAGESIZE )
#define BITMAPSIZE PAGENUMBER/sizeof(unsigned long)
#define NULL ((void *)0)

struct kmemory_info {

unsigned long bitmap[ BITMAPSIZE ];
unsigned long lo_mem;
unsigned long hi_mem;

} kmeminfo;

int kmalloc_init (unsigned long lower, unsigned long upper);
void * kmalloc ();
void kfree(void * p);
int first_free_page();

/* TO FIX */
#define KERNEL_SIZE 2000000

Ah si e in start.asm ho aggiunto
stublet:
EXTERN cmain ; start of our kernel
push ebx
push eax
call cmain
jmp $

zulutown

29-12-2009, 18:16

PS: so che esistono altri os open source, sono partito con linux perchè è quello il mio target; è anche vero che molti altri os open source rimangono a un livello base di funzionalità, pochi sono veramente seri (Haiku?).

secondo me guardarti po' più di altri sistemi operativi.. se vuoi far un micro-kernel in ambito ultra-didattico.. c'è già minix...
poi per non parlare dell'infinità di altri OS oltre linux: openbsd, freebsd, opensolaris, haiku, reactos, hurd ecc

a mio parere cmq linux ha il vantaggio di aver un grande supporto hardware quindi pur essendo programmato "male" avrà la meglio su altri OS open.

cmq secondo me al giorno d'oggi non è molto utile passare troppo tempo sull'OS per come era concepito un tempo

dedicarti a cose un po' più "moderne" magari? os distribuiti su cloud computing? virtualizzazione distribuita?

Z80Fan

29-12-2009, 18:50

Ho scritto una semplicissima implementazione di un memory manager per il tuo kernel :)
Dimensione delle pagine fissa a 4KB, traccia delle pagine allocate e non tramite la bitmap kmeminfo.bitmap. Dalla tabella multiboot di grub ho rimediato oltre alle dimensioni della memoria tutta un'altra serie di informazioni che al momento non ho approfondito :)

In questo archivio trovi il source completo http://rikiji.it/data/kernel.tar.gz
nuovi file: kmalloc.c, kmalloc.h multiboot.h (preso da gnu.org)
editati: main.c, Makefile
il resto è intatto.

Queste sono le funzionalità che ho aggiunto, ho scritto il tutto mentre pranzavo quindi non aspettatevi chissà che virtuosismi :D

:sbavvv:
Se lo hai scritto mentre pranzavi, non immagino cosa tu riesca a scrivere mentre sei al bagno! :D

Sicuramente notevole, ne prendo nota. Attualmente cerco di concludere la versione 0.02 inserendo il supporto al floppy e al dma, il memory managing sarà sicuramente l'obiettivo della versione 0.03. Nel frattempo potresti perfezionarlo e testarlo un po', magari continui nella lettura del multiboot.
Una nota: tu hai assunto che gli indirizzi fossero unsigned long. Io vorrei fare in modo di assegnare sempre variabili a variabili con tipo di dato uguale, anche se il C permette diversamente. Questo per assicurare una corretta compatibilità con qualsiasi piattaforma (anche se ho notato che in x86 e amd64 (piattaforme principali) gli indirizzi corrispondono a unsigned long). Direi che il kernel si dovrebbe compilare idealmente con 0 warning (idealmente ovviamente :D ). Scusa ma voglio essere precisino, visto che i sistemi Unix-like si riconoscono anche dagli exploit causati da buffer overflow ;) Passanto il codice mi sembra potresti sostituire "unsigned long" con "void *", giusto per avere sempre la dimensione corretta, o vuoi che creo un #define pointer con il tipo di dato adatto all'architettura come ho fatto con byte, word ecc?

Per le 2 istruzioni in start.asm: stai inserendo nello stack i 2 parametri per la funzione cmain? Pensavo che grub li avesse già messi nello stack e quindi non sono andato a controllare. Cmq kernel patchato da subito per queste.

Avviso a chi invia codice
Non vi arrabbiate mica se opero alcune modifiche "estetiche" al listato? Non sò, ma la sintassi K&R proprio non mi va giù... ;)

Z80Fan

29-12-2009, 19:23

secondo me guardarti po' più di altri sistemi operativi.. se vuoi far un micro-kernel in ambito ultra-didattico.. c'è già minix...
poi per non parlare dell'infinità di altri OS oltre linux: openbsd, freebsd, opensolaris, haiku, reactos, hurd ecc

a mio parere cmq linux ha il vantaggio di aver un grande supporto hardware quindi pur essendo programmato "male" avrà la meglio su altri OS open.

cmq secondo me al giorno d'oggi non è molto utile passare troppo tempo sull'OS per come era concepito un tempo

dedicarti a cose un po' più "moderne" magari? os distribuiti su cloud computing? virtualizzazione distribuita?

Ah già, i vari *bsd, me ne ero dimenticato (grave mancanza!) :D
Per Minix, gli ho dato un'occhiata (per vedere come implementava il floppy), devo dire che mi sembra *abbastanza* leggibile, magari lo rileggerò per calmare le curiosità su altri argomenti. Il fatto che non lo uso troppo è che non voglio un microKernel, ma un kernel che, nonostante lavori in user mode e abbia diversi moduli, sia monolitico (si, diciamo che potrebbe essere un impasto tra le due scuole di pensiero, per questo Minix non lo butto completamente via)
Hurd la stessa cosa, solo che qui, a distanza di 18 anni, mi sembra non ci sia manco una versione definitiva :D gli darò un'occhiata. Mi informerò più su haiku, perchè BeOS mi sembra interessante nel modo in cui gestisce la multimedia. ReactOS invece lo scarto perchè volevo implementare un kernel POSIX e Linux-compatibile.

Per le cose più moderne: non riesco a leggere dal floppy e già mi vuoi far partire col networking? :D
Devo dire che non ho molte conoscenze in materia, ma non sono ancora convinto di questi OS che fanno uso massiccio di Internet, penso sarà molto presente in futuro, ma allo stato attuale, quando ancora molti paesi anche industrializzati hanno connessioni non molto avanzate e non diffuse sul territorio (Italia in testa), un buon vecchio OS tutto incluso in un unico hd va sempre bene ;)
Adesso la butto lì, ma visto la struttura *fortemente* modulare di questo progetto, non dovrebbe essere difficile scrivere nuovi moduli che creino le interfacce adeguate al cloud computing...

zulutown

29-12-2009, 19:51

Devo dire che non ho molte conoscenze in materia, ma non sono ancora convinto di questi OS che fanno uso massiccio di Internet, penso sarà molto presente in futuro, ma allo stato attuale, quando ancora molti paesi anche industrializzati hanno connessioni non molto avanzate e non diffuse sul territorio (Italia in testa), un buon vecchio OS tutto incluso in un unico hd va sempre bene ;)
Adesso la butto lì, ma visto la struttura *fortemente* modulare di questo progetto, non dovrebbe essere difficile scrivere nuovi moduli che creino le interfacce adeguate al cloud computing...

Ciao, non sto parlando di virtualizzazione, cloud computing per il desktop.

Se vuoi far un OS per il mondo desktop il successo del tuo OS non dipende da quanto tu hai scritto bene il codice, ma da quanti dispositii hardware supporti.
E questo comporta che linux e win siano quasi imbattibili.

Sto parlando dell'ambito server/enterprise dove ormai si virtualizza tutto, e quindi il tuo OS gira su macchine virtuali con hardware virtuale (= pochi sbattimenti a scrivere driver)

al giorno d'oggi quello che conta è fare applicazioni e software che "scala" facilmente.. aggiungendo o togliendo potenza di calcolo che puoi comprare tramite cloud computing ad esempio..

Z80Fan

29-12-2009, 20:10

Ciao, non sto parlando di virtualizzazione, cloud computing per il desktop.

Se vuoi far un OS per il mondo desktop il successo del tuo OS non dipende da quanto tu hai scritto bene il codice, ma da quanti dispositii hardware supporti.
E questo comporta che linux e win siano quasi imbattibili.

Sto parlando dell'ambito server/enterprise dove ormai si virtualizza tutto, e quindi il tuo OS gira su macchine virtuali con hardware virtuale (= pochi sbattimenti a scrivere driver)

al giorno d'oggi quello che conta è fare applicazioni e software che "scala" facilmente.. aggiungendo o togliendo potenza di calcolo che puoi comprare tramite cloud computing ad esempio..

Ok, ho capito cosa intendi.
Devo dire che questo progetto era nato come un OS desktop, facilmente personalizzabile e su cui si potessero scrivere facilmente i driver (ero ben conscio del supporto hardware ;) )
L'idea dell'ambito server non è male. Ma come ho detto anche prima, l'importante è concludere il kernellino che lavora in kernel mode, cioè le parti comuni dello scheduler e della gestione memoria. Tutto il resto può essere riscritto dal cliente o fatto riscrivere su richiesta per un determinato hardware; nel caso che porti della virtualizzazione in questo caso il driver diventerebbe un semplice wrapper alle funzioni della macchina virtuale. Non sò quali architetture vengono emulate da tali macchine, ma se fosse un proc x86, sarebbe velocissimo il porting, abbastanza veloce quanto è l'eliminazione di eventuali parti del pc-ibm residue e della riscrittura dei semplici driver. A questo punto tutte le applicazioni gireranno non modificate, dato che l'ABI è comune.
Direi che il sistema è abbastanza flessibile da poter essere scritto per girare sulle GPU moderne e prendere vantaggio dell'elevato parallelismo :D

Rikiji

29-12-2009, 21:33

:sbavvv:
Se lo hai scritto mentre pranzavi, non immagino cosa tu riesca a scrivere mentre sei al bagno! :D

Sicuramente notevole, ne prendo nota. Attualmente cerco di concludere la versione 0.02 inserendo il supporto al floppy e al dma, il memory managing sarà sicuramente l'obiettivo della versione 0.03. Nel frattempo potresti perfezionarlo e testarlo un po', magari continui nella lettura del multiboot.
Una nota: tu hai assunto che gli indirizzi fossero unsigned long. Io vorrei fare in modo di assegnare sempre variabili a variabili con tipo di dato uguale, anche se il C permette diversamente. Questo per assicurare una corretta compatibilità con qualsiasi piattaforma (anche se ho notato che in x86 e amd64 (piattaforme principali) gli indirizzi corrispondono a unsigned long). Direi che il kernel si dovrebbe compilare idealmente con 0 warning (idealmente ovviamente :D ). Scusa ma voglio essere precisino, visto che i sistemi Unix-like si riconoscono anche dagli exploit causati da buffer overflow ;) Passanto il codice mi sembra potresti sostituire "unsigned long" con "void *", giusto per avere sempre la dimensione corretta, o vuoi che creo un #define pointer con il tipo di dato adatto all'architettura come ho fatto con byte, word ecc?

Per le 2 istruzioni in start.asm: stai inserendo nello stack i 2 parametri per la funzione cmain? Pensavo che grub li avesse già messi nello stack e quindi non sono andato a controllare. Cmq kernel patchato da subito per queste.

Avviso a chi invia codice
Non vi arrabbiate mica se opero alcune modifiche "estetiche" al listato? Non sò, ma la sintassi K&R proprio non mi va giù... ;)

Indenta come vuoi :D
Esatto le push sono proprio per gli argomenti del main!

Appena ho un attimo di tempo posso implementare i segmenti di dimensione variabile con un algoritmo first-fit, ad esempio. Prima però meglio scrivere i semafori, così se mai ci sarà preemption non bisogna rifare tutta la kmalloc :)

Per gli indirizzi si non è una soluzione proprio pulita, ma lì non si può mettere void * perchè poi l'indirizzo viene sommato, e non è corretto e non compila.
La prossima volta che metto mano al codice vedo come fare, altrimenti potresti proprio usare una #define dipendente dall'architettura.

cdimauro

30-12-2009, 08:31

- Volevo fare in modo che Linux prendesse piede come OS
Pessima intenzione. Desisti da quest'idea: sei ancora in tempo! :fagiano:
[...]
(Tu mi dirai: "ma se loro sono programmatori veramente bravi, non ci avranno già pensato?" E io risponderò "Boh")
Io rispondo come fece (forse) qualcuno 2mila anni fa: "tu l'hai detto". :O
PS: so che esistono altri os open source, sono partito con linux perchè è quello il mio target; è anche vero che molti altri os open source rimangono a un livello base di funzionalità, pochi sono veramente seri (Haiku?).
Cambia target, che è meglio. :)
Una nota: tu hai assunto che gli indirizzi fossero unsigned long. Io vorrei fare in modo di assegnare sempre variabili a variabili con tipo di dato uguale, anche se il C permette diversamente. Questo per assicurare una corretta compatibilità con qualsiasi piattaforma (anche se ho notato che in x86 e amd64 (piattaforme principali) gli indirizzi corrispondono a unsigned long). Direi che il kernel si dovrebbe compilare idealmente con 0 warning (idealmente ovviamente :D ). Scusa ma voglio essere precisino, visto che i sistemi Unix-like si riconoscono anche dagli exploit causati da buffer overflow ;) Passanto il codice mi sembra potresti sostituire "unsigned long" con "void *", giusto per avere sempre la dimensione corretta, o vuoi che creo un #define pointer con il tipo di dato adatto all'architettura come ho fatto con byte, word ecc?
Molto meglio. Definisci un file include del tipo platform.h dove metti gli opportuni #define a seconda dell'architettura per int8, uint8, ecc.

Possibilmente definisci pure un intptr e/o un uintptr come intero avente la stessa dimensione di un puntatore. E' un tipo di dato molto utile.
Hurd la stessa cosa, solo che qui, a distanza di 18 anni, mi sembra non ci sia manco una versione definitiva :D gli darò un'occhiata.
Lascialo perdere. Sono passati più di 25 anni da quando è iniziato, e hanno appena rilasciato un'alpha. E' un progetto sostanzialmente morto.
Mi informerò più su haiku, perchè BeOS mi sembra interessante nel modo in cui gestisce la multimedia.
Haiku promette bene, come il vecchio e buon BeOS.
ReactOS invece lo scarto perchè volevo implementare un kernel POSIX e Linux-compatibile.
Questo è un vero peccato, perché purtroppo noto che la tendenza moderna è di realizzare "nuovi" s.o., che però rimangono sempre Unix-like, con tutte le idiosincrasie che si porta dietro questo pezzo d'antiquariato da quarant'anni a questa parte.

Nessuno che si metta in gioco per pensare a s.o. realmente nuovi / innovativi. Sembra che se non c'è Unix/POSIX di mezzo non si possano classificare come s.o....
Appena ho un attimo di tempo posso implementare i segmenti di dimensione variabile con un algoritmo first-fit, ad esempio. Prima però meglio scrivere i semafori, così se mai ci sarà preemption non bisogna rifare tutta la kmalloc :)
La preemption l'aveva persino il vecchio AmigaOS: non implementarla sarebbe un crimine contro l'umanità. :D
Per gli indirizzi si non è una soluzione proprio pulita, ma lì non si può mettere void * perchè poi l'indirizzo viene sommato, e non è corretto e non compila.
La prossima volta che metto mano al codice vedo come fare, altrimenti potresti proprio usare una #define dipendente dall'architettura.
Esatto. Altrimenti sarebbe un inferno poi.

E meglio anche non assumere la presenza di pagine di 4KB. Anzi, se non si assume nemmeno la presenza obbligatoria della paginazione, è anche meglio: si può pensare di far girare il s.o. anche su miliardi di sistemi embedded.

D'altra parte se si manterrà leggero, sarà molto appetibile su questo fronte.

zulutown

30-12-2009, 09:06

Non sò quali architetture vengono emulate da tali macchine, ma se fosse un proc x86, sarebbe velocissimo il porting,

Mi vorresti dire che riavvi "fisicamente" una macchina hardware ogni volta che provi una modifica al tuo OS? :)

cionci

30-12-2009, 09:25

Ahi ahi...usa una macchina virtuale, ti semplificherà notevolmente il lavoro. Tra l'altro puoi tranquillamente fare il boot da floppy.

Z80Fan

30-12-2009, 12:21

Appena ho un attimo di tempo posso implementare i segmenti di dimensione variabile con un algoritmo first-fit, ad esempio. Prima però meglio scrivere i semafori, così se mai ci sarà preemption non bisogna rifare tutta la kmalloc :)
Beh, il preemption era sottointeso :D Purtoppo così com'è adesso il kernel è da riscrivere in varie parti che non assumono il multitasking (p.es il floppy o il timer), e direi che si dovrebbe anche cominciare a separare user e kernel mode, ma volevo lasciare queste operazioni a dopo aver implementato il floppy e la fat (almeno in lettura), in modo che abbia un senso avere l'user mode dove caricarci i moduli. Superato l'ostacolo di quel maledetto controller floppy e di quel ancor più maledetto controller DMA (a 4.7 7 Mhz !!!), il lavoro dovrebbe procedere un pochino più velocemente.

Per gli indirizzi si non è una soluzione proprio pulita, ma lì non si può mettere void * perchè poi l'indirizzo viene sommato, e non è corretto e non compila.
La prossima volta che metto mano al codice vedo come fare, altrimenti potresti proprio usare una #define dipendente dall'architettura.
Molto meglio. Definisci un file include del tipo platform.h dove metti gli opportuni #define a seconda dell'architettura per int8, uint8, ecc.
Possibilmente definisci pure un intptr e/o un uintptr come intero avente la stessa dimensione di un puntatore. E' un tipo di dato molto utile.
Ah non avevo notato la somma. Si quindi l'idea del #define è la più adatta.
Va bene se metto il tipo pointer definito come (in questo caso) unsigned long?
Per cdimauro: intptr e uintptr li intendi rispettivamente signed long e unsigned long? Perchè non vedo il motivo per avere un indirizzo col segno, a parte se deve essere ritornato da una funzione che usa valori fittizzi per indicare degli errori (p.es -1), è in questo caso che intendi?

Pessima intenzione. Desisti da quest'idea: sei ancora in tempo! :fagiano:
Nooo :D Secondo me non è completamente da buttare via, ma è che ormai è diventato troppo vecchio, la sua struttura totalmente monolitica in kernel mode è superata. Oltre a una reingegnerizzazione e riscrittura serve anche poi una politica di sviluppo. Bisogna mettere d'accordo gli sviluppatori e costruire non solo un kernel, ma anche un completo sistema operativo basato su standard unificati che siano compatibili tra tutte le distribuzioni. Un esempio: GNOME e KDE. I due maggiori desktop manager nel mondo Linux, e tra loro completamente incompatibili. Se si riuscisse a mettere d'accordo gli sviluppatori e si scrivesse un sistema unificato tipo le GTK, per gestire gli oggetti a schermo in modo più specifico del X server, rimarrebbero cmq i 2 diversi desktop manager, ognuno con la sua grafica e disposizione dell'interfaccia, solo che sotto lavorano ugualmente e una applicazione scritta per uno funziona tranquillamente con l'altro senza installare librerie aggiuntive (che spesso non si integrano bene)

Questo è un vero peccato, perché purtroppo noto che la tendenza moderna è di realizzare "nuovi" s.o., che però rimangono sempre Unix-like, con tutte le idiosincrasie che si porta dietro questo pezzo d'antiquariato da quarant'anni a questa parte.
Nessuno che si metta in gioco per pensare a s.o. realmente nuovi / innovativi. Sembra che se non c'è Unix/POSIX di mezzo non si possano classificare come s.o....
Posso concordare con te in molti parti, ma in altrettante posso essere discorde: il concetto di tutto-è-un-file và molto bene in diversi campi, ad esempio puoi montare un file binario come se fosse un floppy e scriverci sopra i diversi file (lo uso per scrivere il kernel aggiornato sull'immagine floppy della VM); in altri è poco utile se non fastidioso (es. scheda video: se è un frame buffer è un conto, ma se devi passarle dei comandi opengl?)
Un altro fatto che non mi piace è il filesystem: troppe cartelle e troppi diversi posti dove può finire un file ( /bin, /usr/bin, /usr/local/bin ... ), certo può essere magnifico per la protezione, ma una pena tremenda in altri casi. I programmi sono sparsi in giro (eseguibile in /bin o altre, configurazioni in /etc o nella home di ciascuno, dati vari in altre...), bisognerebbe fare come GoboLinux, ma senza arrivare a cambiare i nomi (la cartella dei programmi può tranquillamente restare /bin invece di /programs).
Diciamo che possiamo tranquillamente scrivere un OS che usa ABI diverse o cartelle diverse, l'importante è provvedere delle librerie che permettano di simulare il vecchio environment finchè le applicazioni non sono riscritte per la nuova interfaccia.
Una cosa carina (sempre in ambito desktop) è fare come MacOS: una cartella che contiene tutto il programma con annessi i suoi file (immagini, suoni ecc). I file di configurazione possono andare nella home sotto un'apposita cartella ~/configs.
E meglio anche non assumere la presenza di pagine di 4KB. Anzi, se non si assume nemmeno la presenza obbligatoria della paginazione, è anche meglio: si può pensare di far girare il s.o. anche su miliardi di sistemi embedded.
Mi stuzzica il mercato embedded... Penso che tutto cmq si possa rifare alla modularità (ancora :D), togli i moduli che non vuoi e hai un kernel piccino. Se poi si mette qualche punto di preemption (come linux) si può ottenere un kernel soft-realtime. A gennaio inizierò un corso di PLC, magari approfondirò le mie conoscenze in materia

Mi vorresti dire che riavvi "fisicamente" una macchina hardware ogni volta che provi una modifica al tuo OS? :)
Noo, mi sembrava ovvio :D Attualmente uso QEMU. Intendevo che non sapevo se le macchine virtuali usate in ambito server emulassero l'x86, che ne sò, magari simulano l'Itanium (dubito visto lo scarso successo) o qualche altra arch più performante o più diffusa nei server. Certo che se rimane x86 è un vantaggio :D.

cdimauro

30-12-2009, 13:53

Beh, il preemption era sottointeso :D Purtoppo così com'è adesso il kernel è da riscrivere in varie parti che non assumono il multitasking (p.es il floppy o il timer), e direi che si dovrebbe anche cominciare a separare user e kernel mode, ma volevo lasciare queste operazioni a dopo aver implementato il floppy e la fat (almeno in lettura), in modo che abbia un senso avere l'user mode dove caricarci i moduli. Superato l'ostacolo di quel maledetto controller floppy e di quel ancor più maledetto controller DMA (a 4.7 7 Mhz !!!), il lavoro dovrebbe procedere un pochino più velocemente.
Ti consiglio di dedicarti alla preemption già da adesso, così evitereai di dover rimettere mano a codice già testato e funzionante.
Ah non avevo notato la somma. Si quindi l'idea del #define è la più adatta.
Va bene se metto il tipo pointer definito come (in questo caso) unsigned long?
Per cdimauro: intptr e uintptr li intendi rispettivamente signed long e unsigned long? Perchè non vedo il motivo per avere un indirizzo col segno, a parte se deve essere ritornato da una funzione che usa valori fittizzi per indicare degli errori (p.es -1), è in questo caso che intendi?
Intendo un campo che convenzionalmente viene chiamato come "tag". Utile a buttarci dentro o un intero (che può essere con o senza segno, appunto) o un puntatore. Dipende dall'uso che ne viene fatto.
Nooo :D Secondo me non è completamente da buttare via,
Tutto no, ok.
ma è che ormai è diventato troppo vecchio, la sua struttura totalmente monolitica in kernel mode è superata. Oltre a una reingegnerizzazione e riscrittura serve anche poi una politica di sviluppo. Bisogna mettere d'accordo gli sviluppatori e costruire non solo un kernel, ma anche un completo sistema operativo basato su standard unificati che siano compatibili tra tutte le distribuzioni. Un esempio: GNOME e KDE. I due maggiori desktop manager nel mondo Linux, e tra loro completamente incompatibili. Se si riuscisse a mettere d'accordo gli sviluppatori e si scrivesse un sistema unificato tipo le GTK, per gestire gli oggetti a schermo in modo più specifico del X server, rimarrebbero cmq i 2 diversi desktop manager, ognuno con la sua grafica e disposizione dell'interfaccia, solo che sotto lavorano ugualmente e una applicazione scritta per uno funziona tranquillamente con l'altro senza installare librerie aggiuntive (che spesso non si integrano bene)
Capisco il tuo scopo, ma mi pare difficile da realizzare.

Poi, per favore, non parlarmi di GTK. :Puke:
Posso concordare con te in molti parti, ma in altrettante posso essere discorde: il concetto di tutto-è-un-file và molto bene in diversi campi, ad esempio puoi montare un file binario come se fosse un floppy e scriverci sopra i diversi file (lo uso per scrivere il kernel aggiornato sull'immagine floppy della VM); in altri è poco utile se non fastidioso (es. scheda video: se è un frame buffer è un conto, ma se devi passarle dei comandi opengl?)
File e cartelle. Puoi vederli come file? Non mi pare. Perché esiste un comando mkdir? ;)
Un altro fatto che non mi piace è il filesystem: troppe cartelle e troppi diversi posti dove può finire un file ( /bin, /usr/bin, /usr/local/bin ... ), certo può essere magnifico per la protezione, ma una pena tremenda in altri casi. I programmi sono sparsi in giro (eseguibile in /bin o altre, configurazioni in /etc o nella home di ciascuno, dati vari in altre...), bisognerebbe fare come GoboLinux, ma senza arrivare a cambiare i nomi (la cartella dei programmi può tranquillamente restare /bin invece di /programs).
Diciamo che possiamo tranquillamente scrivere un OS che usa ABI diverse o cartelle diverse, l'importante è provvedere delle librerie che permettano di simulare il vecchio environment finchè le applicazioni non sono riscritte per la nuova interfaccia.
Una cosa carina (sempre in ambito desktop) è fare come MacOS: una cartella che contiene tutto il programma con annessi i suoi file (immagini, suoni ecc). I file di configurazione possono andare nella home sotto un'apposita cartella ~/configs.
Vedi? Tutti esempi di cose che non vanno bene, perché s'è diffuso un certo modello...

Mai sentito parlare dei VOLUME di AmigaOS? Questa è innovazione. ;)
Mi stuzzica il mercato embedded... Penso che tutto cmq si possa rifare alla modularità (ancora :D), togli i moduli che non vuoi e hai un kernel piccino. Se poi si mette qualche punto di preemption (come linux) si può ottenere un kernel soft-realtime. A gennaio inizierò un corso di PLC, magari approfondirò le mie conoscenze in materia
Passa subito al preemption, che è meglio. ;)
Noo, mi sembrava ovvio :D Attualmente uso QEMU. Intendevo che non sapevo se le macchine virtuali usate in ambito server emulassero l'x86, che ne sò, magari simulano l'Itanium (dubito visto lo scarso successo) o qualche altra arch più performante o più diffusa nei server. Certo che se rimane x86 è un vantaggio :D.
QEMU può emulare le ISA di altre CPU. Ma non è ancora molto sviluppato.

Z80Fan

30-12-2009, 14:09

Intendo un campo che convenzionalmente viene chiamato come "tag". Utile a buttarci dentro o un intero (che può essere con o senza segno, appunto) o un puntatore. Dipende dall'uso che ne viene fatto.

Mmh ok.

Capisco il tuo scopo, ma mi pare difficile da realizzare.
Se i programmatori non vogliono mettersi d'accordo, ce lo faremo noi il desktop manager :D

Poi, per favore, non parlarmi di GTK. :Puke:
Concordo :D

File e cartelle. Puoi vederli come file? Non mi pare. Perché esiste un comando mkdir? ;)
Mi sembra di aver letto (so quale documento, se vuoi una certezza ci cercherò dentro perchè è molto lungo) che in Linux si può aprire una cartella come file, per modificare direttamente le directory entry, ma non era consigliato e non ricordo i limiti imposti a questa operazione.

Mai sentito parlare dei VOLUME di AmigaOS? Questa è innovazione. ;)
Sembri molto informato su AmigaOS, mi interessa. Potresti spiegarmi questi Volume?

Ryuzaki_Eru

30-12-2009, 14:10

[QUOTE=Z80Fan;30259508
Sembri molto informato su AmigaOS, mi interessa. Potresti spiegarmi questi Volume?[/QUOTE]

Si vede che non conosci cdimauro :asd:

Comunque io ne ho approfittato per rispolverare il Deitel. Ora me lo divoro (visto che ho un pò di tempo).

sprik

30-12-2009, 14:35

molto interessante, qualche annetto fa avevo iniziato a scrivere un modulo Vesa per ItaliOS, solo che poi il progetto si è spento...vediamo se riesco a trovare i vecchi appunti ed a provare qualcosina...un po' di minima grafica a 640x480 l'avevo fatta, devo andare a ripescare tutto!

Z80Fan

30-12-2009, 14:38

Si vede che non conosci cdimauro :asd:
Cos'è, ha una brutta reputazione? :D

Cmq, cdimauro, ho dato un'occhiata ai Volume, interessante ma utile solo in un sistema come Windows che separa i dispositivi di memorizzazione in diverse unità. In questo caso *nix è più efficente perchè permette di montare un dispositivo in qualsiasi posizione, facendo credere alle applicazioni che sia tutto sulla stessa unità. E' utile ad esempio in un laboratorio di scuola: nei computer ci sono solo i file di "boot" (o al massimo tutti i file di sistema se la lan è lenta), e nel server centrale ce la home di ogni utente, che anche se cambia computer si trova tutto come era prima; adesso a scuola abbiamo solo un drive sul server (Z: ), se cambiamo computer perdiamo tutte le impostazioni e i file che sono sul desktop (si, basterebbe stare attenti, ma vuoi mettere la comodità di trovarti pure lo sfondo uguale? o più seriamente, ho personalizzato Dev-C++ sul mio computer, quelle volte che devo usarne un altro mi tocca risistemarlo.)
Per simulare i Volume in *nix basterebbe fare in modo che, oltre a montare il dispositivo nella posizione predefinita (metti /media/cdrom0 o /mnt/cdrom0), crei anche un link simbolico con il nome del supporto (quindi inserendo un disco nominato "Lavoro", avrò /media/cdrom0 e /media/Lavoro). Tra l'altro questo succede già qui in Ubuntu con qualsiasi supporto, e penso con qualsiasi distro. Infatti i miei disci sono montati come /media/Riserva e /media/dati. Se dovessi creare una rete e mettere i dati di "Riserva" in un disco remoto, basterebbe montare questo disco remoto nella stessa posizione e riavrei tutto come prima.

Più interessanti sono gli assigns, ma anche in questo caso si possono simulare o come variabili d'ambiente ( $BIN/firefox ) o come link simbolici ( /links/bin, /links/lib ... come fa GoboLinux). La cartella "/links" potrebbe essere anche un file system virtuale (come /proc) in modo che ogni volta che un programma accede alla cartella il systema fornisca il path più appropriato per quel programma (ad esempio un programma utente avrebbe /links/bin che punta a /bin o /usr/bin, un programma root punterà a /sbin).

Z80Fan

30-12-2009, 14:40

vhost87

30-12-2009, 14:44

Si vede che non conosci cdimauro :asd:

Vero! Alla domanda: che OS vorresti? Risponde solo AmigaOS :D

sprik

30-12-2009, 14:48

Non ci sono arrivato ad entrare, perchè quando mi sono proposto per il modulo VESA, il progetto era sul finire perchè i principali progettisti non avevano tempo, infatti ci ho lavoricchiato poco, il tempo di cambiare la modalità video e passare a quella protetta per maggiori risoluzioni, algoritmi di rastrellizzazione di linee e qualche altra componente di base...poi essendo che il progetto si è fermato, mi sono fermato anche io.

Z80Fan

30-12-2009, 14:53

Vero! Alla domanda: che OS vorresti? Risponde solo AmigaOS :D
:D:D Beh, è cmq un buon OS... Amiga Forever! (Anche se preferisco lo ZX Spectrum)

Non ci sono arrivato ad entrare, perchè quando mi sono proposto per il modulo VESA, il progetto era sul finire perchè i principali progettisti non avevano tempo, infatti ci ho lavoricchiato poco, il tempo di cambiare la modalità video e passare a quella protetta per maggiori risoluzioni, algoritmi di rastrellizzazione di linee e qualche altra componente di base...poi essendo che il progetto si è fermato, mi sono fermato anche io.

E' cmq una buona cosa! Ti sarei molto grato se ci fornissi i sorgenti e se li ampliassi per ottenere maggiori risoluzioni ecc...
Sarebbe utile una libreria per disegnare forme e testo, così almeno ci liberiamo di quel dannato modo video 80x25 che con tutti i messaggi di debug finisce subito ;)

sprik

30-12-2009, 15:14

devo fare una bella ricerca nei backup 2006/2007, vediamo cosa ritrovo...così se ne ho il tempo magari lo completo e lo provo prima di dartelo

M4rk191

30-12-2009, 15:26

Z80Fan

30-12-2009, 15:46

Molto interessante come progetto, anche se sembra molto difficile da realizzare.

Sono abbastanza ignorante, quindi prendi quello che scrivo considerando la mia ignoranza :D

Perché non hai considerato l'idea di reimplementare le parti indispensabili del kernel Linux (intendo, per un funzionamento minimale), riguardanti la parte indipendente dalla piattaforma?
Il kernel di per se è una cosa assurda :eek: veramente enorme, ma credo che reimplementare solo una minima parte del kernel (ammesso che riesca a capire il funzionamento dei moduli) sia meno complicato che scrivere da zero un SO.

Per il FileSystem, invece come intendi fare?

E per la portabilità? Il kernel Linux utilizza le estensioni GNU e per questo, a meno di modifiche necessità dei compilatori della GCC per essere compilato. Intendi utilizzarle anche tu?
E davanti alla tua ignoranza rispondo con grandi paroloni :sofico:

1- Semplicemente perchè ho trovato che i sorgenti di Linux sono veramente complessi e un po' disordinati :D Diciamo che avrei dovuto prima capire come funzionava attualmente, poi capire su che parti intervenire e quindi riscriverle. Visto che avevo già in mente come si potesse scrivere, ho deciso di saltare le parti precedenti e scrivere subito del mio codice, che potevo facilmente capire e facilmente spiegare ad altri, fatto esattamente come volevo io. I moduli di Linux sono una buona cosa, ma volevo portare la modularizzazione anche più in là di come non faccia Linux. I suoi moduli non sono neanche troppo complicati, se qualche programmatore linux si interessasse non troverebbe difficoltà a adattarli; o al massimo saremo in grado di adattarli noi.

2- FileSystem: Se intendi per filesystem: Ext, fat, ntfs... in primo luogo useremo la fat12 perchè il sistema attualmente fà il boot da floppy, poi sistemeremo il VFS (virtual file system, in terminologia linux) che consente di avere un'interfaccia unica per il sistema e il VFS si preoccupa di caricare i moduli con le varie implementazioni dei filesystem.
Se invece per filesystem intendi dire la disposizione delle cartelle di sistema (/bin, /etc, /usr, /var ...), io proporrei la via di GoboLinux (controlla wikipedia), ma cmq meno estremamente, conservando i nomi originali delle cartelle.

3- Portabilità: penso tu stia parlando della portabilità delle applicazioni, in questo caso il sistema sarà posix-compatibile quindi i programmi e le utilità GNU si compileranno senza problemi. GCC non avrà bisogno di modifiche perchè noi useremo il formato file eseguibili ELF, l'unica cosa che dovremo scrivere (o ricompilare) saranno le librerie dinamiche (quelle in /lib con estensione .so), che forniscono alle applicazioni le stesse funzioni, ma sotto lavorano diversamente in base al kernel e al sistema operativo. (Anche Windows ha una modalità che può eseguire applicazioni unix appunto avendo le librerie apposta per windows, anche se la cosa è più complicata di così)

Chiedimi pure se qualcosa non ti è chiaro, sono felice di dare informazioni sul mio lavoro :)

cdimauro

30-12-2009, 19:53

Mmh ok.
Tranquillo che il modo di usarlo si trova. ;)
Se i programmatori non vogliono mettersi d'accordo, ce lo faremo noi il desktop manager :D
In tal caso prendete ispirazione dal Workbench (http://en.wikipedia.org/wiki/AmigaOS#Workbench) (nelle ultime versioni, però). :cool:
Mi sembra di aver letto (so quale documento, se vuoi una certezza ci cercherò dentro perchè è molto lungo) che in Linux si può aprire una cartella come file, per modificare direttamente le directory entry, ma non era consigliato e non ricordo i limiti imposti a questa operazione.
Sì, ma non è questo il punto. E' chiaro che qualunque oggetto, sia esso file o cartella, occuperà dello spazio su disco, per cui tale spazio lo si può vedere come un singolo file e farci delle operazioni (il che sarebbe da criminali, perché ogni filesystem gestisce quei dati in maniera completamente diversamente).

Ma ogni oggetto ha un comportamento diverso. Tant'è che, appunto, le cartelle le crei con mkdir e non con touch. Serve, insomma, una specializzazione precisa a seconda del tipo di oggetto che stai manipolando.

Ridurre tutto alla metafora del file è una forzatura enorme che costringe a operazioni innaturali per gestire qualunque cosa.

Giusto per fare un esempio completamente diverso, se devo gestire l'audio, per me non ha senso farlo tramite un apposito file "speciale" (come viene detto in gergo; che poi se si deve far ricorso a file "speciali", tanto vale trattarli direttamente come casi a se stante). Meglio avere delle apposite API che mi permettono di controllare con precisione quello che voglio ottenere. D'altra parte uno stream audio ha delle caratteristiche peculiari che lo differenziano da un file di testo.

Non so se mi sono spiegato.
Sembri molto informato su AmigaOS, mi interessa. Potresti spiegarmi questi Volume?
Ne parlo dopo.
Cos'è, ha una brutta reputazione? :D
Anche. :D
Cmq, cdimauro, ho dato un'occhiata ai Volume, interessante ma utile solo in un sistema come Windows che separa i dispositivi di memorizzazione in diverse unità. In questo caso *nix è più efficente perchè permette di montare un dispositivo in qualsiasi posizione, facendo credere alle applicazioni che sia tutto sulla stessa unità. E' utile ad esempio in un laboratorio di scuola: nei computer ci sono solo i file di "boot" (o al massimo tutti i file di sistema se la lan è lenta), e nel server centrale ce la home di ogni utente, che anche se cambia computer si trova tutto come era prima; adesso a scuola abbiamo solo un drive sul server (Z: ), se cambiamo computer perdiamo tutte le impostazioni e i file che sono sul desktop (si, basterebbe stare attenti, ma vuoi mettere la comodità di trovarti pure lo sfondo uguale? o più seriamente, ho personalizzato Dev-C++ sul mio computer, quelle volte che devo usarne un altro mi tocca risistemarlo.)
Per simulare i Volume in *nix basterebbe fare in modo che, oltre a montare il dispositivo nella posizione predefinita (metti /media/cdrom0 o /mnt/cdrom0), crei anche un link simbolico con il nome del supporto (quindi inserendo un disco nominato "Lavoro", avrò /media/cdrom0 e /media/Lavoro). Tra l'altro questo succede già qui in Ubuntu con qualsiasi supporto, e penso con qualsiasi distro. Infatti i miei disci sono montati come /media/Riserva e /media/dati. Se dovessi creare una rete e mettere i dati di "Riserva" in un disco remoto, basterebbe montare questo disco remoto nella stessa posizione e riavrei tutto come prima.

Più interessanti sono gli assigns, ma anche in questo caso si possono simulare o come variabili d'ambiente ( $BIN/firefox ) o come link simbolici ( /links/bin, /links/lib ... come fa GoboLinux). La cartella "/links" potrebbe essere anche un file system virtuale (come /proc) in modo che ogni volta che un programma accede alla cartella il systema fornisca il path più appropriato per quel programma (ad esempio un programma utente avrebbe /links/bin che punta a /bin o /usr/bin, un programma root punterà a /sbin).
Ecco, in AmigaOS volumi e assign sono visti allo stesso modo (con un nome che finisce coi ":"), ma sono cose diverse.

Col primo si implementano meccanismi che consentono di identificare un preciso "mezzo", e difatti si fa largo (e obbligatorio) uso delle "etichette" assegnabili ai dischi (ma che nei vari s.o. non vengono utilizzati: si tratta soltanto di un'informazione addizionale utile a fini mnemonici all'utente). Tant'è che si possono referenziare dei dischi non presenti, e il s.o. chiederà poi, in maniera trasparente all'applicazione, di inserire il giusto disco per accedere alle informazioni richieste, occupandosi di gestire lock su file et similia.
E' il sistema utilizzato dai giochi che giravano facendo uso del s.o. (normalmente il s.o. veniva barbaramente ucciso per prendere possesso di tutte le risorse della macchina), che permetteva loro di poter girare su qualunque media (floppy, hard disk, cd-rom, e... futuri). Ovviamente rispettando le linee guida dello sviluppo.

Gli assign erano comodissimi per referenziare particolari risorse, assegnando loro un preciso nome, appunto. Nome a cui potevano essere attribuiti più percorsi / file. Era il classico esempio dei comandi (C: era il "volume" dedicato allo scopo), ma l'esempio migliore era rappresentato dai font, che spesso erano distribuiti su più dischi / media.

Io li trovo ancora oggi dei meccanismi utili e comodi, ma soprattutto intuitivi anche per un utente non smaliziato (che non deve andar dietro a link simbolici sparsi sul filesystem, oppure alle famigerate variabili d'ambiente). Soprattutto erano strumenti del tutto trasparenti a livello applicativo.
Vero! Alla domanda: che OS vorresti? Risponde solo AmigaOS :D
Già. Con qualche aggiornamento, però.
:D:D Beh, è cmq un buon OS... Amiga Forever! (Anche se preferisco lo ZX Spectrum)
Vabbé, con quel nick non poteva essere altrimenti. :D

Tanto lo sai che gli spectrumisti hanno preso sempre mazzate dai commodiariani. :O

E comunque, il mio C128 aveva sia l'8510 (erede del 6510) che lo Z80. :cool:

Ryuzaki_Eru

30-12-2009, 20:32

vhost87

30-12-2009, 20:47

Z80Fan

30-12-2009, 21:08

Sì, ma non è questo il punto. E' chiaro che qualunque oggetto, sia esso file o cartella, occuperà dello spazio su disco, per cui tale spazio lo si può vedere come un singolo file e farci delle operazioni (il che sarebbe da criminali, perché ogni filesystem gestisce quei dati in maniera completamente diversamente).
Certo sono d'accordo con te.

Ridurre tutto alla metafora del file è una forzatura enorme che costringe a operazioni innaturali per gestire qualunque cosa.
"Enorme" e "innaturali" forse è un po' troppo eccessivo, sopratutto perchè la difficoltà arriva in particolari e circoscritti campi (vedi dopo)

Giusto per fare un esempio completamente diverso, se devo gestire l'audio, per me non ha senso farlo tramite un apposito file "speciale" (come viene detto in gergo; che poi se si deve far ricorso a file "speciali", tanto vale trattarli direttamente come casi a se stante). Meglio avere delle apposite API che mi permettono di controllare con precisione quello che voglio ottenere. D'altra parte uno stream audio ha delle caratteristiche peculiari che lo differenziano da un file di testo.
Non so se mi sono spiegato.
Si si ho capito cosa intendi, l'audio e video sono le cose meno adatte a un'interfaccia di questo tipo (le immagini statiche ancora ancora). L'audio in particolare, in quanto è un flusso continuo di dati, e per usarlo con questo tipo di interfaccia sarebbe da inviare dati o in modalità carattere (molto pesante come trasferimento), o come blocco (carico un blocco di suono e il driver mi lancia un segnale quando ha finito). I file speciali sono cmq un'interfaccia di basso livello, un metodo per accedere "direttamente" all'hardware, le librerie che ci stanno sopra pensano a prendere i dati e decomprimerli/mixarli/filtrarli per poi passare i dati raw alla periferica, o più tipicamente a un driver che stà sotto. Oppure puoi fare un driver a cui ti colleghi mediante una pipe e gli passi i dati in quel modo, con una pipe separata per i comandi (come fà l' FTP con 2 connessioni). Tutto ciò è cmq ancora nascosto agli occhi del programmatore di applicazioni, e sopratutto è indipendente dal kernel.
Il kernel deve solo gestire i processi e l'allocazione di memoria, gestire le priorità e regolare l'accesso diretto all'hardware ai moduli sovrastanti.
Un modo era appunto quello dei file, che dall'user mode passavano i dati in kernel mode. Diciamo che nel nostro, in cui anche i driver sono in user, usare le pipe è molto più efficente.

Ecco, in AmigaOS volumi e assign sono visti allo stesso modo (con un nome che finisce coi ":"), ma sono cose diverse.
[...]

Molto interessante. Non sapevo che potessero indicare molteplici cartelle/file. In questo caso sono più flessibili di un link. Cmq tu dici
"che non deve andar dietro a link simbolici sparsi sul filesystem", io infatti ho proposto di avere una cartella centralizzata in cui avere i link a diverse zone del sistema, quindi invece di SYS: avrai /links/bin (o quello che è). E' cmq indipendente dall'applicativo. Cmq penso che tutto ciò sia ancora legato al filesystem, quindi al momento attuale non ci interessa troppo. E' solo una questione di gestione del path. Quando svilupperemo il VFS lì potremo inserirci tutto quello che vogliamo

Vabbé, con quel nick non poteva essere altrimenti. :D
Tanto lo sai che gli spectrumisti hanno preso sempre mazzate dai commodiariani. :O
E comunque, il mio C128 aveva sia l'8510 (erede del 6510) che lo Z80. :cool:
Nooo non ricominciamo !!!! :D
Io sono troppo giovane per quel periodo, ma mi sembra che gli spectrummisti non sfigurassero troppo :D
A parte lo Z80 (è italiano lo sapevi?), lo spectrum mi piace anche perchè ha un design pulito e ordinato (tranne per la memoria video ;)), e perchè il basic era vermente avanti (si potevano creare stream di dati, roba che solo il c++ si vantava di avere ;))

A volte penso che nascere in quest'epoca informatica non sia una cosa poi cosi positiva.
E' vero, all'epoca non c'era l'immensa mole di informazioni che abbiamo oggi e non c'era nemmeno internet come la conosciamo oggi, però il lato positivo è impagabile: ci si doveva fare le ossa e sbattere la testa per forza se volevi imparare e fare qualcosa.
Darei tutto quello che ho per poter nascere 30 anni fa.
Quoto anch'io.

Ryuzaki_Eru

30-12-2009, 22:33

Anche perchè, non dimentichiamo (e parlo come persona che *non* ha vissuto in quell'epoca): accendevi il pc e potevi fare due cose

1)caricavi i giochini
2)leggevi il manuale e iniziavi a programmare.

Non c'era molta scelta.

Giullo

30-12-2009, 23:04

complimenti all'autore del thread :)

per quelli che rimpiangono i vecchi tempi della scena, c'era sicuramente molto entusiasmo e "ingenuità", il 90% degli scambi avveniva via lettere, il modem era un lusso per pochi (e se non boxavi o avevi qualcuno che ti forniva le calling card c'era bisogno di un mutuo per collegarsi) ma era veramente meglio?
onestamente non penso ... forse da quando programmo per lavoro ho perso un pò della "poesia" del pioniere, ma sarebbe difficile rinunciare agli strumenti odierni. e la passione (e la competenza in misura minore) non si comprano certamente su wikipedia :)

Ryuzaki_Eru

31-12-2009, 00:50

Eppure all'epoca anche se non c'erano vivevano benissimo, e hanno creato molto. In ogni caso la questione non è il cosa c'era e il cosa non c'era, ma quanto il fatto che c'era poca scelta e se volevi imparare sbattevi la testa fin quando non svenivi. E si imparava *veramente*. Al giorno d'oggi tutto il contrario. Risultato? Settore inflazionato come nessun altro.

cdimauro

31-12-2009, 07:33

A volte penso che nascere in quest'epoca informatica non sia una cosa poi cosi positiva.
E' vero, all'epoca non c'era l'immensa mole di informazioni che abbiamo oggi e non c'era nemmeno internet come la conosciamo oggi, però il lato positivo è impagabile: ci si doveva fare le ossa e sbattere la testa per forza se volevi imparare e fare qualcosa.
Darei tutto quello che ho per poter nascere 30 anni fa.
come non quotarti...
Io invece sono combattuto. Da una parte ho un bel ricordo perché ho appreso vagonate di informazioni e sperimentavo giocando con l'hardware.

Dall'altra è stato un incubo dover lavorare così a basso livello, quando oggi per risolvere problemi ci sono a disposizione strumenti di altissimo livello che in pochissimo tempo ti permettono di arrivare alla soluzione.

Da programmatore l'unico "comandamento" a cui debbo obbedire è: risolvere i problemi col miglior compromesso possibile. E al momento sono anni e anni che non scrivo codice assembly et similia (al più mi faccio del male la notte lavorando in C :D) e mi diverto pure (in modo diverso: astraendo e trovando soluzioni anche "belle" a vedersi).
"Enorme" e "innaturali" forse è un po' troppo eccessivo, sopratutto perchè la difficoltà arriva in particolari e circoscritti campi (vedi dopo)

Si si ho capito cosa intendi, l'audio e video sono le cose meno adatte a un'interfaccia di questo tipo (le immagini statiche ancora ancora). L'audio in particolare, in quanto è un flusso continuo di dati, e per usarlo con questo tipo di interfaccia sarebbe da inviare dati o in modalità carattere (molto pesante come trasferimento), o come blocco (carico un blocco di suono e il driver mi lancia un segnale quando ha finito). I file speciali sono cmq un'interfaccia di basso livello, un metodo per accedere "direttamente" all'hardware, le librerie che ci stanno sopra pensano a prendere i dati e decomprimerli/mixarli/filtrarli per poi passare i dati raw alla periferica, o più tipicamente a un driver che stà sotto. Oppure puoi fare un driver a cui ti colleghi mediante una pipe e gli passi i dati in quel modo, con una pipe separata per i comandi (come fà l' FTP con 2 connessioni). Tutto ciò è cmq ancora nascosto agli occhi del programmatore di applicazioni, e sopratutto è indipendente dal kernel.
Il kernel deve solo gestire i processi e l'allocazione di memoria, gestire le priorità e regolare l'accesso diretto all'hardware ai moduli sovrastanti.
Un modo era appunto quello dei file, che dall'user mode passavano i dati in kernel mode. Diciamo che nel nostro, in cui anche i driver sono in user, usare le pipe è molto più efficente.
Questo lo so, ma preferisco delle soluzioni adeguate. Se ti dicessi che anche i socket non li vedo bene trattati come singoli file, penso che mi uccideresti. :D
Molto interessante. Non sapevo che potessero indicare molteplici cartelle/file. In questo caso sono più flessibili di un link. Cmq tu dici
"che non deve andar dietro a link simbolici sparsi sul filesystem", io infatti ho proposto di avere una cartella centralizzata in cui avere i link a diverse zone del sistema, quindi invece di SYS: avrai /links/bin (o quello che è). E' cmq indipendente dall'applicativo. Cmq penso che tutto ciò sia ancora legato al filesystem, quindi al momento attuale non ci interessa troppo. E' solo una questione di gestione del path. Quando svilupperemo il VFS lì potremo inserirci tutto quello che vogliamo
Non lo trovo comunque comodo. Coi volumi posso assegnare etichette (comprensibili) senza dover specificare un path. Anzi, non c'è proprio il concetto di path (virtuale): il s.o. potrebbe anche trattare l'accesso a un determinato volume in maniera completamente diversa (delegando al gestore del volume tutta l'interfaccia per estrarre informazioni da esso, ad esempio).

Comunque qui è più che altro una questione filosofica. C'è chi preferisce il paradigma "tutto come gerarchia di cartelle e file", e chi preferisce soluzioni specializzate.
Nooo non ricominciamo !!!! :D
Io sono troppo giovane per quel periodo, ma mi sembra che gli spectrummisti non sfigurassero troppo :D
Dipende da quel che c'era da fare (http://www.appuntidigitali.it/2774/e-piu-veloce-un-6502-a-1mhz-o-uno-z80-a-35mhz/) (vedi anche il link del confronto fra C64 e Spectrum, all'inizio dell'articolo). :fagiano:
A parte lo Z80 (è italiano lo sapevi?),
Sì, qualcosina la so (http://www.appuntidigitali.it/2731/zilog-z80-lanti-6502/). :fiufiu: :p
lo spectrum mi piace anche perchè ha un design pulito e ordinato (tranne per la memoria video ;)), e perchè il basic era vermente avanti (si potevano creare stream di dati, roba che solo il c++ si vantava di avere ;))
Questo non lo ricordo onestamente. Anche perché predilegevo altre macchina. :D
complimenti all'autore del thread :)

per quelli che rimpiangono i vecchi tempi della scena, c'era sicuramente molto entusiasmo e "ingenuità", il 90% degli scambi avveniva via lettere, il modem era un lusso per pochi (e se non boxavi o avevi qualcuno che ti forniva le calling card c'era bisogno di un mutuo per collegarsi)
Bei ricordi. :D
ma era veramente meglio?
onestamente non penso ... forse da quando programmo per lavoro ho perso un pò della "poesia" del pioniere, ma sarebbe difficile rinunciare agli strumenti odierni. e la passione (e la competenza in misura minore) non si comprano certamente su wikipedia :)

Già. Io sono molto combattuto, ma alle comodità odierne proprio non riesco a rinunciare.

L'importante, come dici tu, è affrontare le cose con passione.

zulutown

31-12-2009, 08:37

Ok, ho capito cosa intendi.
Devo dire che questo progetto era nato come un OS desktop, facilmente personalizzabile e su cui si potessero scrivere facilmente i driver (ero ben conscio del supporto hardware ;) )

Facendo la premessa che di programamzione OS ne conosco poco, giusto quello imparato all'università, tu mi sembri preparato e intelligente e mi dà fastidio vedere che perdi tempo nel ri-scoprire la ruota..

Se proprio vuoi far qualcosa a basso livello sugli OS, guarda qualche progetto innovativo di università.

Ad esempio il MIT: http://pdos.csail.mit.edu/

Non che io sia un grande fan del mondo accademico, però vorresti mettere la soddisfazione di ficcare 1000 righe del tuo codice in un progetto uscito dal MIT e finanziato dalla Darpa?

Anche se poi 1 progetto sul 10 del MIT avrà una reale applicazione pratica, ma il tuo CV diventerebbe molto più interessante...

Rikiji

31-12-2009, 09:28

Leggo di obiettivi importanti, ma si sta parlando di un kernel che non ha ancora uno scheduler nè un'astrazione di processo o di file! ;)

Come ho già detto all'inizio io se contribuisco con qualche linea lo faccio perchè mi diverto, senza nessuna pretesa... preferisco giocare così che con la playstation.
Poi il mio codice è GPL, usatelo o buttatelo a vostra discrezione :D

Z80Fan

31-12-2009, 11:13

Scorrere più in basso per leggere gli aggiornamenti

Anche perchè, non dimentichiamo (e parlo come persona che *non* ha vissuto in quell'epoca): accendevi il pc e potevi fare due cose

1)caricavi i giochini
2)leggevi il manuale e iniziavi a programmare.

Non c'era molta scelta.
Oppure dopo aver provato a caricare una cassetta 10 volte senza riuscirci e ad aver provato a programmare un giochino, spegnevi il computer e andavi fuori a giocare :D

Eppure all'epoca anche se non c'erano vivevano benissimo, e hanno creato molto. In ogni caso la questione non è il cosa c'era e il cosa non c'era, ma quanto il fatto che c'era poca scelta e se volevi imparare sbattevi la testa fin quando non svenivi. E si imparava *veramente*. Al giorno d'oggi tutto il contrario. Risultato? Settore inflazionato come nessun altro.
Vero, penso che la diffusione del pc al grande pubblico sia stata una grande cosa, ma anche una brutta: metti un bambino (ragazzo) degli anni '80: si compra il suo bellissimo (e costosissimo :cool: ) Commodore 64, magari anche con un paio di cassette, e comincia a giocare. Poi magari si stufa perchè il gioco era bruttino, fuori piove e non sa cosa fare. Prende il manuale e scrive print "Ciao" e lui gli risponde Ciao. Quindi, se fosse stato un tipo come me avrebbe scritto input a$ print "Ciao", a e così via... si appassionava e diventava un programmatore di quelli veri, a cui piace il proprio lavoro e lo trattano come un'arte. Un ragazzo moderno non ha più queste possibilità, finisce il gioco e... gioca a campo minato.
Qua in classe mia siamo in 2 ad essere appassionati (io e l'altro mio amico che sviluppa l'os) veramente, gli altri si lamentano perchè in sistemi studiamo l'assembly (e siamo in un istituto industriale!). C'è un mio compagno poi, promosso per miracolo penso, che non sa neanche che sistema operativo ha a casa! Forse pensavano che informatica volesse dire "impariamo ad usare Word ed Excel". Non dico che devono programmare in assembly, anche un linguaggio altissimo, metti python o altri, basta che sia data la possibilità.
Cmq concordo con chi dice che è un bene avere gli strumenti moderni, io stesso non sarei in grado di usare Linux solo in interfaccia testo...

Questo lo so, ma preferisco delle soluzioni adeguate. Se ti dicessi che anche i socket non li vedo bene trattati come singoli file, penso che mi uccideresti. :D
Tranquillo, anche io non vedo bene i socket come file...

Non lo trovo comunque comodo. Coi volumi posso assegnare etichette (comprensibili) senza dover specificare un path. Anzi, non c'è proprio il concetto di path (virtuale): il s.o. potrebbe anche trattare l'accesso a un determinato volume in maniera completamente diversa (delegando al gestore del volume tutta l'interfaccia per estrarre informazioni da esso, ad esempio).
Comunque qui è più che altro una questione filosofica. C'è chi preferisce il paradigma "tutto come gerarchia di cartelle e file", e chi preferisce soluzioni specializzate.
Concordo sull'ultima affermazione, forse è perchè io la vedo dal livello basso (fare tutto tramite file così non devo sviluppare 1000 interfaccie diverse), ma tu lo vedi da programmatore di alto livello che vuole avere metodi comodi per ogni diverso oggetto. Cmq ripeto questo è relativo solo ai moduli, attualmente possiamo tralasciare questi dettagli per sviluppare il kernel base.

Dipende da quel che c'era da fare (http://www.appuntidigitali.it/2774/e-piu-veloce-un-6502-a-1mhz-o-uno-z80-a-35mhz/) (vedi anche il link del confronto fra C64 e Spectrum, all'inizio dell'articolo). :fagiano:

Sì, qualcosina la so (http://www.appuntidigitali.it/2731/zilog-z80-lanti-6502/). :fiufiu: :p
Eh eh l'avevo già visto parecchio tempo fà, è lui che mi ha fatto conoscere lo ZX Spectrum (tra l'altro mentre cercavo info sul Commodore 64 :D )

L'importante, come dici tu, è affrontare le cose con passione.
Megaquotone intergalattico

Facendo la premessa che di programamzione OS ne conosco poco, giusto quello imparato all'università, tu mi sembri preparato e intelligente e mi dà fastidio vedere che perdi tempo nel ri-scoprire la ruota..
Se proprio vuoi far qualcosa a basso livello sugli OS, guarda qualche progetto innovativo di università.
Ad esempio il MIT: http://pdos.csail.mit.edu/
Non che io sia un grande fan del mondo accademico, però vorresti mettere la soddisfazione di ficcare 1000 righe del tuo codice in un progetto uscito dal MIT e finanziato dalla Darpa?
Anche se poi 1 progetto sul 10 del MIT avrà una reale applicazione pratica, ma il tuo CV diventerebbe molto più interessante...
Interessante, ma preferirei crearne uno da zero, sia per l'indubbio valore didattico (potrei anche riusarlo per il diploma), sia anche per acquisire il know-how necessario (a scuola li dobbiamo ancora trattare), difficile se bisogna modificare un kernel già esistente fatto da persone veramente esperte. Poi possiamo sempre pubblicarlo in un sito con tanto di documentazione per chiunque volesse imparare questa arte.

Leggo di obiettivi importanti, ma si sta parlando di un kernel che non ha ancora uno scheduler nè un'astrazione di processo o di file! ;)
E' tutta colpa dell' hardware!!! (volevo scrivere un post galattico in cui insultavo tutta l'industria di ibm-compatibili, senza tralasciare gli ingegneri IBM originali e l'intel con la sua maledettissima architettura, ma mi son trattenuto)
Non immagini quanto è difficile interfacciarsi all' hardware di un pc, tutti componenti con interfacce astruse e completamente diverse, vecchie di 20 anni e più (il chip DMA originale era molto più vecchio ed era studiato per l' 8080!!!) Ho dato una veloce occhiata a come interfacciarsi con le schede video VESA (il cui ultimo standard risale al '98, uuuu ), e bisogna o fare tutto in modalità reale con le Bios Extensions (VBE), o fare arzigogoli in modalità protetta per non dover usare la vm86.
Scrivere un sistema operativo è facile, è interfacciarsi con questa cavolo di architettura che è impossibile!!! Per uno studente e la peggior cosa che possa esistere.

Quindi, il prossimo progetto dopo il kernel sarà progettare una nuova architettura hardware, supersemplice e adatta per imparare a scrivere questo genere di applicazioni (ne riparleremo a tempo debito).

Aggiornamenti
Vedendo come si sono evolute le cose, ecco cosa ci serve per il kernel (in ordine di priorità):
- Qualcuno che conosca bene la modalità protetta dal 386 e che sappia bene come impostare i vari segmenti ( che saranno cmq da 0 a 4gb ) settanto tutti i vari flag
- Costruire una mmu un po' più perfezionata (forza Rikiji !)
- Come caricare i file ELF (diciamo delle funzioni che permettano di caricare i diversi segmenti di cui è composto un programma e che permetta di individuare i simboli in modo da poter estrarre gli indirizzi delle funzioni contenute (necessarie pre gestire i moduli e librerie dinamiche)
- Chiamate di sistema (o con gli int o con delle tabelle in cui ci sono gli indirizzi a funzione)
- Semafori, lock e tutto quello che gli va dietro
- Costruire uno scheduler
- Costruire una semplice shell
- Come programmare le schede video VESA (*)

Mi sembra aver delineato abbastanza il percorso, sono accolti suggerimenti

(*) Le schede video Vesa sono veramente delle brutte bestie, per questo lo facciamo alla fine, purtroppo dovremo accontentarci del 80x25 ancora per un po'.
Oppure:
Dopo essere stati caricati da grub ed essere in start.asm, tornare temporaneamente in modalità reale, abilitare una modalità grafica (p es 640x480) e poi tornare in protetta. Da li poi dobbiamo scrivere solo nel framebuffer che si trova ad 0xA0000 se non erro.

Ryuzaki_Eru

31-12-2009, 12:50

Forse pensavano che informatica volesse dire "impariamo ad usare Word ed Excel".

Metà dei miei colleghi di università pensano proprio questo.

Cmq concordo con chi dice che è un bene avere gli strumenti moderni, io stesso non sarei in grado di usare Linux solo in interfaccia testo...

Perchè non sei obbligato ad imparare ad usarla ;)

Comunque per il sistema operativo, la discussione mi affascina sempre più e avrei una voglia matta di prendere in mano un task, ma come conoscenze non ci sono. L'unica conoscenza che sto riprendendo è il C, per il resto prima di poter fare qualcosa di utile chissà quanto tempo ci vorrà.

Z80Fan

31-12-2009, 12:55

Perchè non sei obbligato ad imparare ad usarla ;)
Veramente la so usare, ma non c'ho voglia ;)

Comunque per il sistema operativo, la discussione mi affascina sempre più e avrei una voglia matta di prendere in mano un task, ma come conoscenze non ci sono. L'unica conoscenza che sto riprendendo è il C, per il resto prima di poter fare qualcosa di utile chissà quanto tempo ci vorrà.
Tranquillo non c'è fretta ;) Oppure potresti fare da "ricercatore" trovando informazioni utili su internet.

Ryuzaki_Eru

31-12-2009, 13:05

Veramente la so usare, ma non c'ho voglia ;)

Questo è un altro discorso allora. Avevi scritto che non la sapevi usare ;)

Tranquillo non c'è fretta ;) Oppure potresti fare da "ricercatore" trovando informazioni utili su internet.

Che ruolo di m***a mi hai trovato :D
Comunque fretta non ce nè, ma prima inizio meglio è altrimenti poi trovo il progetto troppo avviato.

khelidan1980

31-12-2009, 14:11

Vero, penso che la diffusione del pc al grande pubblico sia stata una grande cosa, ma anche una brutta: metti un bambino (ragazzo) degli anni '80: si compra il suo bellissimo (e costosissimo :cool: ) Commodore 64, magari anche con un paio di cassette, e comincia a giocare. Poi magari si stufa perchè il gioco era bruttino, fuori piove e non sa cosa fare. Prende il manuale e scrive print "Ciao" e lui gli risponde Ciao. Quindi, se fosse stato un tipo come me avrebbe scritto input a$ print "Ciao", a e così via... si appassionava e diventava un programmatore di quelli veri, a cui piace il proprio lavoro e lo trattano come un'arte. Un ragazzo moderno non ha più queste possibilità, finisce il gioco e... gioca a campo minato.

Te fai questione di epoca ciò che è secondo me,è questione di passione,nulla vietava all'epoca di spegnere il computer ed andar a cazzeggiare in giro,senza dover per forza passare per il campo minato....il fatto è che ogni persona di qualsiasi epoca guarda in modo romantico al tempo che fu...

P.s: indubbiamente qualcosa di migliore nel passato c'era oggettivamente,ad esempio loro avevano i Led Zeppelin e noi i Backstreet Boys :asd:

Z80Fan

31-12-2009, 14:14

Ryuzaki_Eru

31-12-2009, 14:17

Te fai questione di epoca ciò che è secondo me,è questione di passione,nulla vietava all'epoca di spegnere il computer ed andar a cazzeggiare in giro,senza dover per forza passare per il campo minato....il fatto è che ogni persona di qualsiasi epoca guarda in modo romantico al tempo che fu...

E' vero, ma c'era anche una cultura diversa e l'informatica non era come adesso. All'epoca c'era poco da fare:

accendevi il pc a giocavi
accendevi il pc, i giochi non piacevano, ma ti piaceva di più lanciarli e iniziavi con il tuo primo PRINT
uscivi

Ora invece i ragazzi hanno:

adsl
chat
facebook
videogiochi
videogiochi
videogiochi
ecc ecc ecc

di conseguenza mettersi seduti al pc a studiare e scrivere codice non è una cosa molto allettante se non ci si trova dentro. Prima invece eri quasi obbligato a provarla se i giochi non ti piacevano e non sapevi dove andare.

Z80Fan

31-12-2009, 14:19

Ok ragazzi sarebbe interessante continuare questo discorso storico, ma questo non è il posto più adatto ;)

Ryuzaki_Eru

31-12-2009, 14:21

Giusto. Chiuso OT.

cdimauro

31-12-2009, 22:37

- Qualcuno che conosca bene la modalità protetta dal 386 e che sappia bene come impostare i vari segmenti ( che saranno cmq da 0 a 4gb ) settanto tutti i vari flag
Cosa t'interessa sapere?
Dopo essere stati caricati da grub ed essere in start.asm, tornare temporaneamente in modalità reale, abilitare una modalità grafica (p es 640x480) e poi tornare in protetta. Da li poi dobbiamo scrivere solo nel framebuffer che si trova ad 0xA0000 se non erro.
Sì, esatto. E' la strada più semplice.

Z80Fan

31-12-2009, 23:24

Buon Anno a Tutti !!!!
Il mio proposito per l'anno nuovo è finire stò benedetto kernel (oltre a prendere un bel voto in storia ;))

Cosa t'interessa sapere?
Informazioni tecniche non troppe, magari ci puoi scrivere qualche #define in modo da poter passare alla funzione gdt_set_gate dei valori leggibili.

Bisognerà anche definire la mappa della memoria, come è vista da ogni processo.
Ma aspettiamo ancora un po' quando finiranno i festeggiamenti :)

khalhell

31-12-2009, 23:27

Buon Anno a Tutti !!!!
Il mio proposito per l'anno nuovo è finire stò benedetto kernel (oltre a prendere un bel voto in storia ;))

Informazioni tecniche non troppe, magari ci puoi scrivere qualche #define in modo da poter passare alla funzione gdt_set_gate dei valori leggibili.

Bisognerà anche definire la mappa della memoria, come è vista da ogni processo.
Ma aspettiamo ancora un po' quando finiranno i festeggiamenti :)

Cosè siete dietro che programmate anche a capodanno?? ;) io lo farei...

Z80Fan

31-12-2009, 23:30

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

Z80Fan

31-12-2009, 23:32

Cosè siete dietro che programmate anche a capodanno?? ;) io lo farei...

I veri programmatori non hanno bisogno di queste feste "umane" :cool:

cdimauro

01-01-2010, 06:40

Informazioni tecniche non troppe, magari ci puoi scrivere qualche #define in modo da poter passare alla funzione gdt_set_gate dei valori leggibili.

Bisognerà anche definire la mappa della memoria, come è vista da ogni processo.
Ma aspettiamo ancora un po' quando finiranno i festeggiamenti :)
Ho trovato un ottimo tutorial (http://www.osdever.net/bkerndev/Docs/gdt.htm): semplice, e con #define e routine annesse.

Penso che dovrebbe bastarti. Se ci sono delle cose non chiare, chiedi pure.

P.S. Vale anche per la LDT.

Z80Fan

01-01-2010, 10:58

Ho trovato un ottimo tutorial (http://www.osdever.net/bkerndev/Docs/gdt.htm): semplice, e con #define e routine annesse.

Penso che dovrebbe bastarti. Se ci sono delle cose non chiare, chiedi pure.

P.S. Vale anche per la LDT.

Grazie, anche se lo conoscevo già quel tutorial (prova a confrontare il mio listato e quello sul sito ;))
Non ricordavo che spiegasse anche il significato dei bit, parto subito al lavoro!

M4rk191

01-01-2010, 12:34

Z80Fan

01-01-2010, 12:50

Visto che siete esperti ne approfitto per chiedere una cosa a cui penso da ieri.

Nella scrittura del kernel, si può usare la libreria standard del C?
Mi spiego, alcune funzioni (es. fopen) sono implementate sfruttando chiamate di sistema, quindi mi chiedo, è possibile utilizzare comunque queste funzioni, o è necessario, magari, implementare prima delle chiamate di sistema? :mc:

@Z80Fan: Quando parlavo di portabilità, intendevo chiedere, se fai/farai uso di keyword come typeof, che sono appunto estensioni GNU. In sostanza, mi chiedevo, se i sorgenti, potranno essere poi compilati senza modifiche su qualunque compilatore C, oppure se dovranno essere compilato per forza con GCC a meno di modifiche :)

Purtroppo non possiamo usare le librerie nel kernel perchè le librerie non fanno altro che richiamare certe funzioni (appunto le chiamate di sistema) che sono nel kernel, e che dobbiamo scrivere noi; non è che nella fopen c'è tutto il codice per interfacciarsi coi dischi ecc..., la fopen non fa altro che chiamare una syscall apposita che fa la funzione desiderata.

Per la portabilità: attualmente l'unica cosa gcc è l'assembler inline, cmq abbastanza limitato. Io non conosco bene funzioni avanzate del gcc, anche perchè ho studiato da libri che non preferivano un compilatore ad un altro. Quindi penso che si possa portare tranquillamente (ma non vorrai mica compilarlo con il compilatore Microsoft?!? sacrilegio! :D)

cionci

01-01-2010, 14:11

Z80Fan

01-01-2010, 14:15

Non si può. Le estensioni dell'asm inline del GCC sono diverse da quelle del compilatore Microsoft.
Si ho scritto male, volevo dire che si può portare tranquillamente riscrivendo però le parti con l'assembly inline. Grazie ;)

M4rk191

01-01-2010, 14:15

Purtroppo non possiamo usare le librerie nel kernel perchè le librerie non fanno altro che richiamare certe funzioni (appunto le chiamate di sistema) che sono nel kernel, e che dobbiamo scrivere noi; non è che nella fopen c'è tutto il codice per interfacciarsi coi dischi ecc..., la fopen non fa altro che chiamare una syscall apposita che fa la funzione desiderata.

Per la portabilità: attualmente l'unica cosa gcc è l'assembler inline, cmq abbastanza limitato. Io non conosco bene funzioni avanzate del gcc, anche perchè ho studiato da libri che non preferivano un compilatore ad un altro. Quindi penso che si possa portare tranquillamente (ma non vorrai mica compilarlo con il compilatore Microsoft?!? sacrilegio! :D)

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 :asd:).

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?

M4rk191

01-01-2010, 14:19

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 :D

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 :D

cionci

01-01-2010, 14:27

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

01-01-2010, 14:28

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

01-01-2010, 14:29

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

01-01-2010, 14:32

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 :asd:).

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

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:
Si ho scritto male, volevo dire che si può portare tranquillamente riscrivendo però le parti con l'assembly inline. Grazie ;)

M4rk191

01-01-2010, 14:36

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

01-01-2010, 14:55

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

02-01-2010, 08:13

Z80Fan

02-01-2010, 10:12

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

02-01-2010, 10:36

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

02-01-2010, 11:01

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

02-01-2010, 13:38

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

http://z80fan.altervista.org/i386-programmers-reference-manual.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

03-01-2010, 04:42

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

http://z80fan.altervista.org/i386-programmers-reference-manual.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

03-01-2010, 09:56

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

03-01-2010, 10:07

Z80Fan

03-01-2010, 12:39

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

03-01-2010, 13:20

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 :D), e poi onestamente se dovessi lavorare a un s.o. (ma dovrei clonarmi prima per trovare il tempo :asd:) me lo farei da zero e sicuramente non Unix/POSIX-compliant (il nome ce l'ho già: Py. O.S. :fiufiu: :p).
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

03-01-2010, 13:24

e poi onestamente se dovessi lavorare a un s.o. (ma dovrei clonarmi prima per trovare il tempo :asd:) me lo farei da zero e sicuramente non Unix/POSIX-compliant (il nome ce l'ho già: Py. O.S. :fiufiu: :p).
Fammi indovinare, AmigaOS-compliant e scritto in python? :Prrr:

idt_winchip

03-01-2010, 16:12

khelidan1980

03-01-2010, 16:38

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

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

cdimauro

03-01-2010, 16:52

Fammi indovinare, AmigaOS-compliant e scritto in python? :Prrr:
No, AmigaOS non c'entrebbe nulla. Ma per lo più lo scriverei in Python. :D

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).
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. :fiufiu: :D

cdimauro

03-01-2010, 16:59

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 :D).

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

03-01-2010, 17:03

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

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

03-01-2010, 17:21

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

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

cdimauro

03-01-2010, 18:48

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? :D

In verità è da un bel po' che ci rifletto. Finito wpython magari faccio qualche esperimento, se ne ho ancora voglia. :fagiano:
Grande! Non ti sfugge niente! :asd:
Eh basta vedere con cosa è stato fatto il wizard per bertos.. :asd:
Oppure il PyCon.. :asd:
:ciapet:

Dev'essere stata una bella esperienza. :)

M4rk191

03-01-2010, 18:54

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

03-01-2010, 19:14

Scrivere un SO che richiede una VM, non porterebbe a tempi di bootstrap lunghissimi?
Non necessariamente.
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

03-01-2010, 19:16

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

03-01-2010, 19:47

Ciao Z80Fan, ho visto il tuo progetto, leggendo il titolo così entusiasta mi son detto: "eccone un altro" :asd: , 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 :)
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
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.

- 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 :D

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

03-01-2010, 20:01

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

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 :D
lo sai perfettamente che i linguaggi managed sono il futuro anche nel settore dei sistemi operativi :) :D

fero86

03-01-2010, 20:03

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

03-01-2010, 20:07

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 :D

cdimauro

03-01-2010, 20:08

caro Cesare, é inutile che scrivi col tono di quello che ci sta riflettendo per la prima volta :D
lo sai perfettamente che i linguaggi managed sono il futuro anche nel settore dei sistemi operativi :) :D
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. :stordita:
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 :D
Dipende anche dal linguaggio.

fero86

03-01-2010, 20:16

(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

05-01-2010, 12:40

Cose come queste non dovrebbero succedere in un sistema operativo "avanzato" ;)
http://z80fan.altervista.org/immagini/ubuntu-desktop-broken-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.

zulutown

05-01-2010, 13:36

Z80Fan

05-01-2010, 13:42

X non è un OS
Io intendevo Ubuntu, infatti ho anche specificato "server X" ;)

anonimizzato

05-01-2010, 13:58

M4rk191

05-01-2010, 14:06

Z80Fan

05-01-2010, 14:27

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 :D)

Z80Fan

13-01-2010, 17:08

Scrivo solo per dire che il progetto è ancora attivo, ho solo avuto poco tempo per lavorarci in questi giorni per motivi scolastici. Cmq siamo sul buon punto di poter caricare i file dal floppy e questo ci aprirà molte porte interessanti ;)

Ryuzaki_Eru

13-01-2010, 17:34

Non mi dire niente, oggi ho avuto il primo esame :muro:

Mattyfog

13-01-2010, 17:40

complimenti =)

Z80Fan

13-01-2010, 18:12

Dopo questa... non capivo perché non si aggiornavano delle variabili locali per poi scoprire che avevo creato delle variabili locali con lo stesso nome!!! :doh:

complimenti =)
Grazie :)

banryu79

15-01-2010, 14:20

Z80Fan

15-01-2010, 14:28

Maledette ferie :asd:, a momenti mi perdevo il thread...

@Z80Fan
Grazie per aver postato un link con la possibilità di visionare il codice.
Sono un assoluto ignorante in materia di programmazione a basso livello, ma leggo codice C abbastanza da potermi godere il tuo codice e soddisfare così alcune curiosità che ho da parecchio tempo...

In bocca al lupo per il tuo progetto! :)
Grazie mille per l'incoraggiamento :)
Non perderti il prossimo aggiornamento, inserirò il supporto alla fat (maledetto file system...) e da lì in poi si che si faranno le figate :sofico:

Z80Fan

22-01-2010, 17:29

Mi sento quasi in colpa di non aver rilasciato la nuova versione, deludo le aspettative dei lettori del thread :cry:
Cmq la lettura da FAT12 funziona, posso effettuare il listing di una directory, caricare pezzi di file dato il percorso, l'indice di partenza e la dimensione del buffer. Solo che c'è un piccolo bug che non riesco a capire (anche se finisce il file legge ancora byte nulli), e voglio risolverlo prima. Quindi integro tutto nel kernel.

Allego il codice della sola fat (è in c++ ed è un programma stand-alone) se qualcuno volesse dare un'occhiata (mi scuserete sicuramente per il disordine causato dalle molte prove ;) )

74453

EDIT: Bug Risolto !

Mattyfog

22-01-2010, 18:58

grande! ti stimo :P
;)

M4rk191

23-01-2010, 18:44

Z80Fan

23-01-2010, 19:12

Z80Fan, non posso fare a meno di chiederti una cosa:
I file di intestazione come stdio.h, includono prototipi di funzioni che si appoggiano a chiamate di sistema effettuare i loro compiti. Nel file shell.cpp includi proprio questi file di intestazione, di conseguenza, il codice che scrivi funziona finché viene eseguito da un SO. Tu invece stai scrivendo un kernel, che prima o poi dovrai eseguire al di fuori di un SO. A quel punto, se le chiamate di sistema non saranno più disponibili, come faranno a funzionare le tue funzioni (scusa il gioco di parole)? :mc:

Perchè quello è un programma fittizio per provare la lettura della fat. Le funzioni che uso sono infatti cout per visualizzare le robe sullo schermo e il ifstream per simulare il lettore floppy. Adesso che lo ho portato nel kernel ho sostituito i cout con i printf che ho implementato e il floppy reale.

Quanto posto la nuova versione capirai subito, ma purtroppo c'è qualcosa che non va, nel programma stand-alone funzionava, ma nel kernel non produce il listing delle directory, come se fosse tutto a zero. Penso sia un problema del floppy cmq.

wingman87

23-01-2010, 19:55

M4rk191

24-01-2010, 09:19

Perchè quello è un programma fittizio per provare la lettura della fat. Le funzioni che uso sono infatti cout per visualizzare le robe sullo schermo e il ifstream per simulare il lettore floppy. Adesso che lo ho portato nel kernel ho sostituito i cout con i printf che ho implementato e il floppy reale.

Quanto posto la nuova versione capirai subito, ma purtroppo c'è qualcosa che non va, nel programma stand-alone funzionava, ma nel kernel non produce il listing delle directory, come se fosse tutto a zero. Penso sia un problema del floppy cmq.

Allora aspetto la nuova versione :D

Z80Fan

24-01-2010, 10:39

Complimenti per il progetto, volevo chiederti quali libri hai letto prima di cimentarti nell'impresa e a quali documenti fai riferimento durante lo sviluppo.
Grazie per aver reso disponibile il codice

Non ho libri che parlano di sistemi operativi, e anche i documenti sono tutti su internet, non c'è un testo fisso da cui leggere. Tuttavia la base del kernel è stata presa da questo tutorial http://www.osdever.net/bkerndev/index.php . Da questo poi ho aggiunto le altre parti.

Allora aspetto la nuova versione :D
Eh eh, non dovrai aspettare tanto cmq, ho individuato perchè non funzionava, è un problema della cache delle tracce del floppy; non è essenziale per il funzionamento, quindi la ho temporaneamente bypassata, ma spero di riuscire a sistemarla il prima possibile. Purtroppo in questi giorni non sto tanto bene, e non riesco proprio a pensare :D

Rikiji

24-01-2010, 17:40

Adesso che lo ho portato nel kernel ho sostituito i cout con i printf che ho implementato

beh "che hai implementato"... diciamo che l'hai più "trovata" su osdev insieme a tutte le altre routine

Ryuzaki_Eru

24-01-2010, 18:02

beh "che hai implementato"... diciamo che l'hai più "trovata" su osdev insieme a tutte le altre routine

Su su, dettagli :D

M4rk191

24-01-2010, 18:20

Mi sono sempre chiesto come si potesse implementare una funzione come printf, ho trovato un'implementazione nel kernel Linux scritta da Torvalds in persona :asd:

Nei prossimi giorni mi studio il codice cercando di capire come funziona, speriamo di riuscirci :D

Z80Fan

24-01-2010, 19:35

beh "che hai implementato"... diciamo che l'hai più "trovata" su osdev insieme a tutte le altre routine

Se non l'avessi trovata l'avrei dovuta scrivere :D Adesso che ci penso bisognerebbe migliorarla un po' quello printf che usiamo...

Ho aggiunto il link per scaricare la nuova versione, denominata 0.03 "a" poichè priva della cache delle tracce del floppy, che a quanto pare non funziona correttamente.

Z80Fan

26-01-2010, 17:51

Mi serve un aiuto da qualche esperto C:
Ho visto altre volte che si può specificare una funzione in questo modo:
int WINAPI WinMain(...)
A quanto ne so questi permettono di modificare la struttura base della funzione (ad esempio il codice all'inizio e alla fine della funzione) per adattarlo a diverse esigenze. Mi interesserebbe sapere come si fa o al massimo come si chiama questa tecnica perchè mi interesserebbe fare delle funzioni tipo
void INT_HANDLER floppy_irq_handler()
{
...
}
e lui mi fornisce già una base per una funzione che gestisce gli interrupt dove poi io ci metto solo le cose che sono differenti tra una e l'altra

cionci

26-01-2010, 18:02

Purtroppo credo che sia tutto interno al compilatore.

Mi fai un esempio di come definiresti altrimenti la funzione dell'interrupt handler ? Sono un po' arrugginito sugli interrupt handler.

Z80Fan

26-01-2010, 18:11

Purtroppo credo che sia tutto interno al compilatore.

Mi fai un esempio di come definiresti altrimenti la funzione dell'interrupt handler ? Sono un po' arrugginito sugli interrupt handler.

Quando entro in un handler per un interrupt devo fare una cosa del genere
push ds
push es
push fs
push gs
mov ax, 0x10 ; Load the Kernel Data Segment descriptor!
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

per settare il giusto data segment per accedere ai dati del kernel, e quando esco dall'handler devo pop-are i registri e inviare uno speciale codice al PIC (programmable interrupt controller) per dirgli che ho finito di gestire l'interrupt. per l'invio al pic nn c'è problema, quando salvo i registri potrei farlo con una macro e dell'assembler inline, ma non so se poi vado a dar problemi al compilatore che si aspetta che lo stack sia formato in un certo modo e invece io ho inserito dei valori che lui non si aspetta.
Invece in questo modo ( che sembra ho trovato, qualcosa sulle calling conventions e codice di prologo e epilogo ) posso scrivere io direttamente il codice e so esattamente come è fatto lo stack.

(Ho scritto veramente male :D )

cionci

26-01-2010, 18:18

Se non sbaglio i compilatori C permettono di usare una cosa simile a WINAPI per avere delle funzioni senza prologo ed epilogo. Si dovrebbero chiamare naked functions.
Che compilatore usi ?

Z80Fan

26-01-2010, 18:24

Se non sbaglio i compilatori C permettono di usare una cosa simile a WINAPI per avere delle funzioni senza prologo ed epilogo. Si dovrebbero chiamare naked functions.
Che compilatore usi ?

gcc 4.4.1 , sarebbe già interessante come idea perchè mi basterebbe definire la funzione naked e poi proprio all'inizio della funzione fare una macro tipo HANDLER_START e una HANDLER_END con un po' di asm inline per gestire i casi.

cionci

26-01-2010, 18:32

Esatto, però vedo che gli attributi per le funzioni che ti potevano interessare non sono definiti per x86.
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Z80Fan

26-01-2010, 18:43

Esatto, però vedo che gli attributi per le funzioni che ti potevano interessare non sono definiti per x86.
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

azz... che sfiga mostruosa. Anche perchè ora mi viene in mente solo di fare una funzione assembly per ogni funzione C, il che è mooolto brutto... oppure scrivere tutta la funzione solo in assembly, che potrebbe funzionare fino a che il tutto non sale di compessità. Tutto perchè quei maledetti alla Intel non hanno previsto un registro o un modo per ottenere il numero dell'interruzione appena avvenuta, perchè sennò avrei registrato un handler unico per tutti i possibili interrupt e poi smistare da li le richieste alla varie funzioni.

cionci

26-01-2010, 18:46

Prova a guardare comunque se riesci a recuperare la situazione con il prologo ed epilogo standard. In tal caso ti basterebbero le macro.

Z80Fan

26-01-2010, 18:49

Prova a guardare comunque se riesci a recuperare la situazione con il prologo ed epilogo standard. In tal caso ti basterebbero le macro.

Oppure riscrivo il compilatore :D

cionci

26-01-2010, 18:50

Oppure ti scrivi un preprocessore che genera il sorgente assembly ;)

Z80Fan

26-01-2010, 19:03

Non una delle mie migliori idee, ma l'unica che mi è venuta:
uso delle variabili locali per tenere i valori dei vari selettori di segmento invece di pusharli nello stack, così non lo altero per la felicità del compilatore, e metto un po' di asm inline per caricarli all'inizio e salvarli alla fine. Che ne dici?

(questo è solo il caricamento)

word selector_ds
word selector_es
word selector_ss
word selector_gs
word selector_fs

asm volatile (
"mov %%ds, %%ax;"
"mov %%ax, %0;"
"mov %%es, %%ax;"
"mov %%ax, %1;"
/* ecc */

: "=m" (selector_ds), "=m" (selector_es) /* output */
: /* no input */
: "eax" /* clobbered */
);

Z80Fan

26-01-2010, 19:28

Però mi è venuta in mente un' altra cosa: io nel mio kernel non voglio usare la gestione segmentata della memoria (che considero obsoleta), anche per il fatto che c'è solo nell' architettura x86 e non nelle altre, dove però c'è quasi sempre la paginazione. Se io voglio usare solo la paginazione, allora dovrò solamente usare 2 segmenti code e data che coprono tutto lo spazio di indirizzamento, e qualsiasi codice, che sia kernel o applicazione, userà gli stessi selettori; La protezione della memoria e dei permessi saranno rimandati alla paginazione, giusto? Se tutto ciò è corretto, non ho bisogno di salvare i selettori di segmento perchè avranno comunque gli stessi valori. Al massimo dovrò chiedere al kernel di cambiarmi la/le pagine per poter fare le mie cose.

Chiedo consigli.

cdimauro

26-01-2010, 19:56

Z80Fan

26-01-2010, 20:05

Sì, se usi la paginazione puoi utilizzare un modello unico per tutti i processi, e pure per il kernel.

Poi la diversa page table farà il resto (protezione di codice e dati dei singoli processi e del kernel).
Molto bene, quello che pensavo

Personalmente utilizzerei i selettori FS e GS (o anche soltanto uno dei due) facendoli puntare alle strutture del kernel, come fa Windows, in modo da poter immediatamente accedervi (ovviamente soltanto da ring 0) senza bisogno di caricare alcunché.

interessante, ma per usarli bisognerebbe fare un segmento di tipo "data" apposito a cui far "puntare" i selettori giusto? E' interessante ma preferisco non utilizzare per niente i selettori/segmenti, per ottenere la portabilità elevata e poi perchè come ho già detto più volte li odio proprio :D
Potrei simulare il tutto con dei puntatori globali alle varie strutture dati.

cdimauro

26-01-2010, 20:47

interessante, ma per usarli bisognerebbe fare un segmento di tipo "data" apposito a cui far "puntare" i selettori giusto?
Esattamente, e con DPL = 0.
E' interessante ma preferisco non utilizzare per niente i selettori/segmenti, per ottenere la portabilità elevata
Se devi scrivere codice assembly, la portabilità è l'ultimo dei tuoi problemi. :D
e poi perchè come ho già detto più volte li odio proprio :D
Peccato, perché si tratta di una soluzione molto elegante, per certi versi superiore alla paginazione.

Ho in cantiere da mesi un articolo su segmentazione vs paginazione. Prima o poi lo butterò giù per analizzare proprio questi aspetti che, purtroppo, sono spesso trascurati.
Potrei simulare il tutto con dei puntatori globali alle varie strutture dati.
Ma sarebbe meno efficiente di un bel selettore già caricato e a cui basta accedere sfruttando il classico prefisso FS: o GS:. ;)

Z80Fan

26-01-2010, 21:19

Se devi scrivere codice assembly, la portabilità è l'ultimo dei tuoi problemi. :D
Ma io volevo fare in modo di poter scrivere il meno possibile in assembly ;) , proprio perchè voglio ottenere la maggior portabilità.

Peccato, perché si tratta di una soluzione molto elegante, per certi versi superiore alla paginazione.
La segmentazione è utile in alcuni casi, ma io non la vedo del tutto "elegante": prima di tutto perchè ti fornisce un numero limitato di segmenti, quindi se ne vuoi usare di più dovresti dividerti manualmente un segmento in altri segmenti e accederci con una tecnica base-scostamento; non ti permette di rappresentare agevolmente l'indirizzo, perchè devi specificare sia il selettore sia l'offset, un puntatore segmentato in nel 386 occuperebbe 48 bit, dimensione non proprio standard, il che rende i calcoli difficoltosi (non tanto nell'applicazione, quanto al sistema operativo); poi non permette di eseguire agevolmente tutte quelle tecniche proprie della paginazione: "swappare" singoli segmenti dentro e fuori dall'harddisk è possibile, ma con la paginazione puoi anche fare in modo che i byte non siano consecutivi e ri-organizzare le pagine velocemente con semplici algoritmi first-fit e senza bisogno di "deframmentare" in modo da spostare tutti i segmenti all'inizio della memoria ed avere tutto lo spazio libero alla fine. Un'altra cosa che mi viene in mente è l'allocazione della memoria: quando un programma ti chiede un'area di memoria, crei un nuovo segmento e gli passi il nuovo selettore e offset? ma rischi di finire i selettori consentiti; oppure gli allarghi il segmento corrente, ma se poi lui ti fa il delete di un dato che è in mezzo al segmento, non puoi ridimensionarlo di nuovo perchè i dati che sono alla fine del segmento devono rimanere allo stesso offset.
Questi sono i difetti che mi vengono in mente adesso, certo ci sono anche dei vantaggi, ad esempio è più veloce della traduzione delle pagine, perchè tutto il descrittore è già caricato in registri shadow.

Ho in cantiere da mesi un articolo su segmentazione vs paginazione. Prima o poi lo butterò giù per analizzare proprio questi aspetti che, purtroppo, sono spesso trascurati.
Sarei il primo a leggerla ;) visto che mi interesso anche di architettura di processori, sarebbe un'interessante lettura.

Ma sarebbe meno efficiente di un bel selettore già caricato e a cui basta accedere sfruttando il classico prefisso FS: o GS:. ;)
Sempre se lavori in Asm, o se riesci a trovare un modo per dire al compilatore di usare fs e gs, per il resto non è molto utile perchè ti obbliga a rendere più difficile il codice (aggiungere asm inline) per ottenere solo un marginale incremento delle prestazioni (se fossero state 1000 letture è un conto, ma un caricamento di un puntatore è leggero)

cdimauro

27-01-2010, 07:25

Ma io volevo fare in modo di poter scrivere il meno possibile in assembly ;) , proprio perchè voglio ottenere la maggior portabilità.
Io procederei diversamente. Se c'è già una funzione scritta in assembly o che comunque ne fa uso, ha poco senso guardare quante sono le righe scritte in questo linguaggio: in ogni caso la sua portabilità risulta già compromessa.

Per cui cercherei di sfruttare quanto posso dalle peculiarità dell'architettura specifica.
La segmentazione è utile in alcuni casi, ma io non la vedo del tutto "elegante": prima di tutto perchè ti fornisce un numero limitato di segmenti, quindi se ne vuoi usare di più dovresti dividerti manualmente un segmento in altri segmenti e accederci con una tecnica base-scostamento; non ti permette di rappresentare agevolmente l'indirizzo, perchè devi specificare sia il selettore sia l'offset, un puntatore segmentato in nel 386 occuperebbe 48 bit, dimensione non proprio standard, il che rende i calcoli difficoltosi (non tanto nell'applicazione, quanto al sistema operativo); poi non permette di eseguire agevolmente tutte quelle tecniche proprie della paginazione: "swappare" singoli segmenti dentro e fuori dall'harddisk è possibile, ma con la paginazione puoi anche fare in modo che i byte non siano consecutivi e ri-organizzare le pagine velocemente con semplici algoritmi first-fit e senza bisogno di "deframmentare" in modo da spostare tutti i segmenti all'inizio della memoria ed avere tutto lo spazio libero alla fine. Un'altra cosa che mi viene in mente è l'allocazione della memoria: quando un programma ti chiede un'area di memoria, crei un nuovo segmento e gli passi il nuovo selettore e offset? ma rischi di finire i selettori consentiti; oppure gli allarghi il segmento corrente, ma se poi lui ti fa il delete di un dato che è in mezzo al segmento, non puoi ridimensionarlo di nuovo perchè i dati che sono alla fine del segmento devono rimanere allo stesso offset.
Questi sono i difetti che mi vengono in mente adesso, certo ci sono anche dei vantaggi, ad esempio è più veloce della traduzione delle pagine, perchè tutto il descrittore è già caricato in registri shadow.
Sì, hai abbracciato quasi tutti i punti. Ne rimangono fuori alcuni che tratterò assieme a questi.
Sarei il primo a leggerla ;) visto che mi interesso anche di architettura di processori, sarebbe un'interessante lettura.
Passerà ancora un bel po' di tempo.
Sempre se lavori in Asm, o se riesci a trovare un modo per dire al compilatore di usare fs e gs, per il resto non è molto utile perchè ti obbliga a rendere più difficile il codice (aggiungere asm inline) per ottenere solo un marginale incremento delle prestazioni (se fossero state 1000 letture è un conto, ma un caricamento di un puntatore è leggero)
Se devi scrivere codice specifico in assembly lascia perdere. Ma se ti è necessario farvi ricorso, valuta questa possibilità.

Z80Fan

27-01-2010, 19:11

Io procederei diversamente. Se c'è già una funzione scritta in assembly o che comunque ne fa uso, ha poco senso guardare quante sono le righe scritte in questo linguaggio: in ogni caso la sua portabilità risulta già compromessa.
Per cui cercherei di sfruttare quanto posso dalle peculiarità dell'architettura specifica.

Si in effetti hai ragione, gli interrupt sono cmq una cosa specifica di ogni architettura quindi è lecito usare l'assembly. Cmq ho pensato che, attivando la paginazione, potrei avere tutte le tabelle che partono ad un indirizzo virtuale identico, quindi mi basterebbe usare una costante nel codice per riferirmici (non è proprio il massimo cmq ;))

cdimauro

28-01-2010, 09:04

Data la natura del progetto, la sicurezza penso sia l'ultimo dei tuoi problemi, ma considera che la tendenza attuale è implementare roba come l'ASLR (http://en.wikipedia.org/wiki/ASLR).

Z80Fan

28-01-2010, 19:04

Data la natura del progetto, la sicurezza penso sia l'ultimo dei tuoi problemi, ma considera che la tendenza attuale è implementare roba come l'ASLR (http://en.wikipedia.org/wiki/ASLR).

Interessante per il caricamento di un programma o di una libreria in memoria, ma forse un po' troppa roba per il solo kernel, che tanto viene cmq chiamato solo attraverso le chiamate di sistema a interrupt, che quindi può nascondere tutte le sue pagine sia dalla lettura sia dalla scrittura. Si può attuare l' ASLR anche ai moduli per introdurre maggior sicurezza. Ma questo verrà rimandato tutto alle politiche di caricamento del loader.

Z80Fan

30-01-2010, 19:06

Un problema importante affligge lo sviluppo: l' ultima versione del kernel non funziona sulla macchina reale, si riavvia mentre grub lo sta caricando. Sembra proprio non entrare nel kernel, penso si riavvii quando ancora sta eseguendo grub. Penso in un errore nel linking, perchè le versioni precedenti funzionavano tranquillamente. Qualcuno un po' esperto di ELF potrebbe darmi una mano?

khelidan1980

31-01-2010, 12:03

Ho in cantiere da mesi un articolo su segmentazione vs paginazione. Prima o poi lo butterò giù per analizzare proprio questi aspetti che, purtroppo, sono spesso trascurati.

ma lo facciamo o no sto SO in Python? :asd:

DanieleC88

31-01-2010, 14:11

ma lo facciamo o no sto SO in Python? :asd:
A me l'idea era quasi venuta... ma visti i miei precedenti con i sistemi operativi ho deciso di lasciar perdere. :p

DanieleC88

31-01-2010, 14:12

ndakota

31-01-2010, 14:15

A me l'idea era quasi venuta... ma visti i miei precedenti con i sistemi operativi ho deciso di lasciar perdere. :p

Scusate per chi non lo sapesse riporto per completezza :D

http://www.hwupgrade.it/forum/showthread.php?t=474346

:ciapet: :ciapet:

DanieleC88

31-01-2010, 14:16

È arrivato un altro... :mbe:

:D

P.S.: e comunque... ne è passata di acqua sotto i ponti da quando ho aperto quel dannato thread... :p

cdimauro

31-01-2010, 14:19

ma lo facciamo o no sto SO in Python? :asd:
Al momento sono in trattative per portare il mio progetto (o parti di esso, com'è più prevedibile) all'interno del ramo principale di (C)Python. :fagiano:

Z80Fan

31-01-2010, 15:02

Difficile che sia GRUB il problema, cos'hai cambiato che potrebbe determinare un problema simile? Controlla l'entry point del kernel.

ciao ;)

Non ne ho idea :boh: cmq hai ragione grub non c'entra: caricando manualmente dalla shell di grub tutto funziona, e si riavvia solo quando do il comando "boot". Penso sia qualcosa nella tabella multiboot, perchè veramente non fà nulla, quindi penso che grub venga confuso e salti ad una locazione sbagliata.

Edit: La cosa più strana è che all'interno di QEMU tutto funziona correttamente !!!

Scusate per chi non lo sapesse riporto per completezza :D
http://www.hwupgrade.it/forum/showthread.php?t=474346
:ciapet: :ciapet:
Wow non sono l'unico :D (cmq io son partito a 17 anni, almeno ho aspettato di arrivare all' ITIS ;) )

ma lo facciamo o no sto SO in Python? :asd:
Al momento sono in trattative per portare il mio progetto (o parti di esso, com'è più prevedibile) all'interno del ramo principale di (C)Python. :fagiano:

Visto che per Python avete bisogno di una interprete che alla fine fà gli stessi compiti di un kernel, magai questo progetto può risultarvi utile, almeno nelle parti che accedono alle periferiche, o a come si legge dal filesystem.

cdimauro

31-01-2010, 15:51

Indubbiamente. Ma penso che passerà parecchio tempo, semmai ne avrò per dedicarmici.

Anche perché se inizio a lavorare a CPython, dubito che avrò tempo da dedicare ad altro.

Z80Fan

02-02-2010, 18:54

Ho isolato il problema: si tratta dello stack.
Attualmente il linker lo posiziona da 0x105000 a 0x107000, forzandolo a 0xA00000 funziona, ma si blocca cmq dopo qualche chiamata (di funzione). Qualche idea? forse si sovrappone a qualche periferica memory-mapped?

cdimauro

02-02-2010, 20:18

fero86

02-02-2010, 21:02

Visto che per Python avete bisogno di una interprete che alla fine fà gli stessi compiti di un kernel, a mio modesto parere sarebbe inopportuno distribuire il sistema operativo sotto forma di sorgenti Python interpretati al momento dell'esecuzione (per questioni di performances intendo, non necessariamente/non solo di licenza); é vero che il buon programmatore dovrebbe sempre aspettare di sentire il profiler prima di praticare qualunque tipo di ottimizzazione, ma c'é un limite a tutto: un sistema operativo interpretato mi pare eccessivo. probabilmente Python é un ottimo linguaggio anche per la programmazione di sistema (non scherzo) ma prima bisognerebbe avere un'infrastruttura ad hoc costituita da un compilatore JIT, un gestore di memoria dinamica, eccetera. é esattamente quello che hanno fatto per Singularity: Singularity non é scritto in C#, ma in Sing#, una versione ad hoc di C#.

cdimauro

02-02-2010, 22:22

Personalmente pensavo di scrivere le parti critiche (boot loader, gestione della memoria, degli interrupt, JIT, ecc.) in Python, ma di generare poi codice nativo.

Similmente a quello che fa PyPy, in cui tutto il progetto è scritto in una speciale versione di Python (RPython), ma poi è possibile scegliere quale back-end utilizzare (C, LLVM o codice nativo PowerPC) per generare la virtual machine Python, incluso eventualmente il JIT (per x86 al momento).

Per essere chiari: il generatore di VM è scritto interamente in RPython, e il suo output può essere teoricamente di qualunque tipo.

Lo stesso principio è applicabile, a mio avviso, anche a roba come bootloader e kernel del s.o..

La cosa importante è utilizzare Python per sviluppare tutto il codice, scegliendo opportunamente le parti per le quali generare codice nativo, bytecode (o wordcode :D), o lasciare direttamente il sorgente.

Le prestazioni sono sicuramente importanti, ma non vitali. Poi ci sono strumenti come il JIT che permettono di migliorarle sensibilmente.

Comunque al momento le mie sono soltanto idee, che mi trascino da un po' di tempo e per le quali non ho avuto la possibilità di scrivere nemmeno uno spike.

morgoth90

03-02-2010, 17:48

Z80Fan

03-02-2010, 18:07

come setti la posizione dello stack?
io lo setto come prima operazione in questo modo

.set STACKSIZE, 0x4000 # that is, 16k.
.comm stack, STACKSIZE, 32 # reserve 16k stack on a quadword boundary

_loader:
mov $(stack + STACKSIZE), %esp # set up the stack

in questo modo sono sicuro che nessuno mi scriva nello stack

Si anche io lo faccio come prima operazione, appena GRUB mi richiama:

start:
cli ; non servirebbe
mov esp, sys_stack ; This points the stack to our new stack area
jmp stublet

Lo stack è automaticamente gestito dal linker nella zona bss
SECTION .bss
qua:
resb 8192 ; This reserves 8KBytes of memory here
sys_stack:

che è inserita alla fine del kernel:
ENTRY(start)
phys = 0x00100000;
SECTIONS
{
.text phys : AT(phys) {
code = .;
*(.text)
*(.rodata)
. = ALIGN(4096);
}
.data : AT(phys + (data - code))
{
data = .;
*(.data)
. = ALIGN(4096);
}
.bss : AT(phys + (bss - code))
{
bss = .;
*(.bss)
. = ALIGN(4096);
}
end = .;
}

Certo non è la soluzione migliore, ma per il momento è ok, e non ha mai dato problemi. Ho scoperto che QEMU non dà questo errore, ma VirtualBox si (e simula meglio anche la gestione del video). Ci sono però certe volte (cambiando l'indirizzo e assegnandone uno arbitrario) che la macchina (virtuale) semplicemente si blocca e non fà niente, altre in qui viene fuori il Guru Meditation e sono costretto a riavviarla. (Ci sarebbe anche il file di log, ma virtualbox logga veramente troppo ;) )
Sicuri che non c'è qualcosa di standard mappato tra 0x105000 e 0x107000 ? Perchè mi sembra un po' strano che si blocchi addirittura la macchina virtuale (intesa come programma), robe tipo un triple fault o errori seri. Una volta mi si è anche fermato il kernel mostrando un 'eccezione "invalid instruction", quindi presumo che quella zona di memoria venga modificata spudoratamente da qualcosa e mi modifica tutti gli indirizzi di ritorno.

morgoth90

03-02-2010, 18:14

Z80Fan

03-02-2010, 18:20

sei invece sicuro che non sia qualche funzione che sbaglia a scrivere in locazioni sbagliate? a me era capitato che una funzione zappasse l'intera memoria per colpa di una stringa senza terminatore.
altrimenti potrebbe essere un fatto di segmenti o di paginazione (se l'hai abilitata)

Non mi sembra, anche perchè si blocca subito dopo poche chiamate, e in quelle chiamate ci sono funzioni che non sono mai state toccate dalla prima versione. La paginazione non ce la ho, e i segmenti, già grub dovrebbe averci dato 2 segmenti code e data da 4gb con tutti i permessi, poi io nella mia gdt ne creo 2 con le stesse caratteristiche e non li tocco più.
Cmq la mia firma riassume tutto :D

morgoth90

03-02-2010, 18:24

Z80Fan

03-02-2010, 18:38

la idt quindi non l'hai toccata e se si è funzionante? perchè altrimenti è per quello che l'emulatore si incarta quando cerca di eseguire del codice che in realtà sono dati casuali.
potrebbe pure essere quello il problema che genera il tutto, basta una semplice divisione per zero o un problema qualsiasiasi che generi un interrupt

No no tutte le tabelle sono correttamente inizializzate (tranne la paginazione che cmq non è attiva)
La sequenza attuale di avvio è (partendo con interrupt disattivi):
- setto la gdt
- setto il video (semplicemente inizializza la variabile globale dell'inizio della memoria video, questa operazione la ho fatta qui solo perchè mi serviva stampare dei caratteri a schermo a scopo di debug, ma di solito è sempre stata alla fine prima di riattivare gli interrupt)
- setto la idt
- imposto le isr standard per le eccezioni e gli irq da 0 a 15
- imposto il timer (setto la isr e lo programmo a 1khz)
- imposto la tastiera (setto isr)
- riattivo interrupt
- ciclo infinito per vedere una semplice animazione a schermo per verificare che non sia bloccato (questo ovviamente temporaneo, altrimenti ci sarebbe l'installazione di dma, floppy e fat e list della root del floppy)

Attualmente tutto funziona, ma si capisce che non fà niente di utile :D

(Ho provato a causare una divisione per zero e funziona correttamente, cioè mi appare sullo schermo (virtuale) l'eccezione e il kernel và in panic, quindi è corretto; anche prima quando dicevo che mi è apparso "istruzione illegale" intendevo che era il kernel a segnalarmelo, non la vm)

morgoth90

03-02-2010, 18:40

Non credo, perché dovresti impostare tu le periferiche assegnando loro l'indirizzo base (per quelle che lo prevedono).

Potrebbe essere il BIOS che al boot le mappa opportunamente.

L'unica è fare un programmino di scansione delle periferiche per vedere a quale indirizzo sono state assegnate.

Ma prima ancora proverei a smanettare cambiando l'indirizzo base dello stack. Magari prova a dimezzarlo finché non vedi che la situazione è "stabile". Oppure raddoppialo e vedi come si comporta cominciando a utilizzare gli indirizzi alti (> 16MB).
non credo sia questo il problema, a parte la scheda video nessuna periferica usa il DMA di default, inoltre stà già usando la memoria alta, la memoria bassa è quella usata in real mode dal bios che lavora a 16bit e va da 0 a 65KB circa

morgoth90

03-02-2010, 18:45

No no tutte le tabelle sono correttamente inizializzate (tranne la paginazione che cmq non è attiva)
La sequenza attuale di avvio è (partendo con interrupt disattivi):
- setto la gdt
- setto il video (semplicemente inizializza la variabile globale dell'inizio della memoria video, questa operazione la ho fatta qui solo perchè mi serviva stampare dei caratteri a schermo a scopo di debug, ma di solito è sempre stata alla fine prima di riattivare gli interrupt)
- setto la idt
- imposto le isr standard per le eccezioni e gli irq da 0 a 15
- imposto il timer (setto la isr e lo programmo a 1khz)
- imposto la tastiera (setto isr)
- riattivo interrupt
- ciclo infinito per vedere una semplice animazione a schermo per verificare che non sia bloccato (questo ovviamente temporaneo, altrimenti ci sarebbe l'installazione di dma, floppy e fat e list della root del floppy)

Attualmente tutto funziona, ma si capisce che non fà niente di utile :D

(Ho provato a causare una divisione per zero e funziona correttamente, cioè mi appare sullo schermo (virtuale) l'eccezione e il kernel và in panic, quindi è corretto; anche prima quando dicevo che mi è apparso "istruzione illegale" intendevo che era il kernel a segnalarmelo, non la vm)
sei riuscito ad individuare il punto preciso dove inizia a dare segni di errore? trovato quello dovrebbe ristringersi il campo. prova a mettere un while(1); in punti diversi in modo da trovare il punto da cui inizia a far casino

Z80Fan

03-02-2010, 18:55

non credo sia questo il problema, a parte la scheda video nessuna periferica usa il DMA di default, inoltre stà già usando la memoria alta, la memoria bassa è quella usata in real mode dal bios che lavora a 16bit e va da 0 a 65KB circa

se posso fare una precisazione (forse utile), l'unica periferica che ancora adesso usa il DMA standard è solo il lettore floppy (e le vecchie SoundBlaster), e la memoria bassa si estende per 1 MB (cioè quanto la massima memoria indirizzabile da un 8086).

sei riuscito ad individuare il punto preciso dove inizia a dare segni di errore? trovato quello dovrebbe ristringersi il campo. prova a mettere un while(1); in punti diversi in modo da trovare il punto da cui inizia a far casino
Il fatto è che non c'è un punto dove è sbagliato, semplicemente non funziona dopo un tot di chiamate a funzione che non ho contato però. E sembra ancora più random adesso visto che ho dis-commentato il main e gli ho lasciato fare tutto come prima ed è arrivato tranquillamente in fondo (nonostante non fornisca nessun listing della root del floppy, cmq i messaggi di debug indicano che il floppy stà leggendo i settori corretti).

Rettifico: il floppy legge dati errati, e quando visualizzo un report dei dati letti dal mbr mi si colorano anche dei quadratini verdi in giro per lo schermo.
Un'altra cosa è che le funzioni di accesso al floppy sembrano stranamente lunghissime... Posso dedurre solo che lo stack si corrompe in qualche punto.

Z80Fan

03-02-2010, 19:05

Per sbaglio ho fatto partire la macchina virtuale dal hdd virtuale e si è avviato Absolute Linux. Vedendo tutti i messaggi di inizializzazione mi viene una lacrimuccia a pensare quanta strada ho ancora da fare e che sono frenato solo da una stupida architettura che ci dobbiamo portare avanti nonostante tutte le bellissime architetture che esistono al mondo (cito solo la famiglia 68000 e la ARM perchè sono quelle che ho avuto modo di conoscere più approfonditamente e non solo dal nome)
:)

Edit: Festeggio il mio 128° post, il prossimo a 256 :D

Z80Fan

03-02-2010, 20:27

come setti la posizione dello stack?
io lo setto come prima operazione in questo modo

Stai facendo un kernel anche tu? A che stato sei arrivato? è possibile vedere il sorgente?

Z80Fan

03-02-2010, 20:49

Ho ottenuto una pioggia di quadratini verdi.
E poi si è bloccato.
Da ora in poi non mi stupirò più di niente.

DanieleC88

03-02-2010, 21:11

Ho ottenuto una pioggia di quadratini verdi.
E poi si è bloccato.
Da ora in poi non mi stupirò più di niente.
Fu così che ebbe inizio The Matrix. :D

Z80Fan

03-02-2010, 21:27

Fu così che ebbe inizio The Matrix. :D

Tranquilli sono solo io che a quest'ora programmo come un c******e... :(
Cmq penso che oltre a tutto ci sia anche printf / itoa che hanno qualche bug.
Qualcuno riesce a trovarne una versione funzionante, magari estraendola da qualche sorgente (chi ha parlato di Linux e libc ?)

DanieleC88

03-02-2010, 23:39

Io nel mio antico OS ne avevo fatto una versione "pressoché funzionante"... Se la ritrovo te la posto. :D

Per quanto può essere utile, insomma...

EDIT: trovata, ma non è nemmeno completa, accetta solo 4 o 5 formati. Sicuramente la tua è più completa. Se servisse Linux, un link alla versione 1.0 (solo perché le ultime saranno molto più dispersive): http://www.kernel.org/pub/linux/kernel/v1.0/

morgoth90

04-02-2010, 09:29

Stai facendo un kernel anche tu? A che stato sei arrivato? è possibile vedere il sorgente?
certo :D
ecco il link al sito http://tylyos.osdev.it

^TiGeRShArK^

04-02-2010, 11:51

Al momento sono in trattative per portare il mio progetto (o parti di esso, com'è più prevedibile) all'interno del ramo principale di (C)Python. :fagiano:
Good! :D

Z80Fan

04-02-2010, 14:12

Se servisse Linux, un link alla versione 1.0 (solo perché le ultime saranno molto più dispersive): http://www.kernel.org/pub/linux/kernel/v1.0/
Eh eh io avevo scaricato la 0.01 :D

certo :D
ecco il link al sito http://tylyos.osdev.it
Wooo è fighissimo! Hai seguito anche te il tutorial bkerneldev? perchè noto molte somiglianze tra i sorgenti ;)

Ultimissime:
Su QEMU la lettura da floppy funziona, ma il problema allo schermo rimane. Ora mi rimane solo da provare l'ultima versione sulla macchina reale, e in caso poi provare anche Bochs.

morgoth90

04-02-2010, 15:14

bkerneldev? in alcuni punti ho preso spunto da dei tutorials, ad esempio per l'interrupt handler ed il boot da grub

Z80Fan

04-02-2010, 15:16

bkerneldev? in alcuni punti ho preso spunto da dei tutorials, ad esempio per l'interrupt handler ed il boot da grub

http://www.osdever.net/bkerndev/index.php

Io parlavo di questo.

DanieleC88

04-02-2010, 15:40

certo :D
ecco il link al sito http://tylyos.osdev.it
...Elenhost? :stordita:

Z80Fan

04-02-2010, 15:48

...Elenhost? :stordita:

Ha stile :D

Cmq ho scoperto che posso collegare Gdb a Bochs !
Finalmente il "pannello Altair" che mi mancava :yeah:

Z80Fan

04-02-2010, 17:01

Sembra che devo tornare a mettere mano al driver floppy...
QEMU mi ha illuso tutto questo tempo facendomi credere di aver programmato giusto :cry:

Z80Fan

14-02-2010, 10:21

GDB insieme a Bochs non serve a niente (per lo meno posso mettere i break point)
Grazie all'aiuto di ItaliOS stò sistemando il driver floppy
Se faccio partire il kernel dal floppy, mi dà errore nella calibrazione, ma se lo faccio partire dalla chiavetta USB, mi dice calibrazione ok :mbe:
Ho una nuova versione di printf, sprintf e vsprintf prese da nientepopòdimenoche... Linux :D (licenza GPL sempre ti saremo grati :ave: )

In qualsiasi caso non legge correttamente. Oggi sistemerà anche questo punto paragonando i listati di ItaliOS

M4rk191

14-02-2010, 10:29

Z80Fan

14-02-2010, 10:32

Più che altro da Torvalds in persona :D

Linus Torvalds e Richard Stallman sempre vi saremo grati :ave:
:D

Cmq ho appena realizzato una cosa interessante:
Il bit nel comando Specify che indica se usare o meno il DMA, è negato, cioè se è a 0 allora usa il dma! :ncomment:
Confermerò le mie ipotesi alla prossima compilazione.

zulutown

14-02-2010, 12:04

non è il caso di farvi un svn su googlecode?

Z80Fan

14-02-2010, 13:53

non è il caso di farvi un svn su googlecode?

googlecode? :asd:
Al massimo SourceForge :) Ci darò un'occhiata.

News:
Sembra che le macchine virtuali siano coalizzate per farmi impazzire :(
Cmq dove Bochs mi dà illegal instruction, su VirtualBox funziona tutto bene, ed ho anche sistemato quel noioso bug che mi mostrava quadratini verdi :D
Ora mi appresto a provare la macchina reale, speriamo bene !

Z80Fan

19-02-2010, 18:24

Sulle macchine virtuali ora il floppy funziona, ma nella macchina reale non ancora: tutte le inizializzazioni vanno a buon fine, ma legge dati errati.
Visto che da solo ho provato ma ho fallito, copierò tale e quale il driver floppy di ItaliOS e lo sistemerò in C.
Oppure, stò seriamente pensando di lasciar perdere completamente il floppy e farmi caricare inizialmente una specie di "immagine disco" da grub in ram, così ci posso accedere direttamente senza problemi, e poi pian piano implementare tutto ciò che serve per il sistema e in futuro fare i dischi e l'impianto usb.

@Morgoth90
Ho visto che avete inglobato un sistema grafico nel kernel, veramente ben fatto :D

Z80Fan

20-02-2010, 18:39

Il sistema floppy di ItaliOS funziona meno del mio ...

Cmq ora ho deciso: lascio perdere il floppy e mi concentro su tutte quelle altre piccole cose che avrei dovuto fare da tempo (parsing della tabella multiboot, una specie di riga di comando, modalità grafica, mmu, processi... ), usando la tecnica che hanno usato in TylyOS, cioè una "immagine disco" caricata in ram da grub e che io interpreto come un disco vero e proprio (una ram/rom disk).
Così finalmente riusciò a concentrarmi sul serio sul sistema operativo e non solo su questo orribile hardware, e magari riuscirò a ravvivare un po' l'interesse sul forum, visto che ha perso l'entusiasmo che ha avuto nelle prime settimane ;)

Al lavoro!

cdimauro

20-02-2010, 18:52

Z80Fan

20-02-2010, 19:23

AmigaOS RAM Disk (http://en.wikipedia.org/wiki/AmigaOS#RAM_disk):

The AmigaOS also has support for a fixed-capacity recoverable RAM disk, which functions as a standard RAM disk, but can maintain its contents on soft restart. It is commonly called the RAD disk, and it can be used as a boot disk (with boot sector).

:D

Ti sei subito acceso eh? :D
Purtroppo il "mio" Ram disk è meno nobile di quello dell' Amiga, visto che non posso essere sicuro che i dati rimangano dopo un reboot. E non lo uso neanche come boot disk: grub carica dal disco (chiavetta USB) il kernel, poi l'immagine e passa l'indirizzo al kernel.

(PS: Io pensavo che il secondo tipo si chiamasse "Rom" Disk)

cdimauro

20-02-2010, 20:22

No, RAD: è dispositivo del tutto identico a RAM: (la classica ram disk di AmigaOS, che è sostanzialmente un filesystem che risiede in memoria).

L'unica differenza è che sopravvivere al reset, ed essendo un filesystem dotato di boot, è pure bootabile.

P.S. In effetti mi sono tornati in mente i vecchi tempi. :p

morgoth90

26-02-2010, 19:43

zulutown

27-02-2010, 10:03

avete fatto sto repository svn? è il minimo per lavorare in team..

cionci

27-02-2010, 10:05

Io vi prometto che scriverò lo scheduler dei processi. Ancora più avanzato di quello di linux o Windows :D

Z80Fan

27-02-2010, 20:57

avete fatto sto repository svn? è il minimo per lavorare in team..
Non ancora, sono un po' impegnato in questi giorni, ma visto che insisti tanto darò un'occhiata a sourceforge contento? ;)

Io vi prometto che scriverò lo scheduler dei processi. Ancora più avanzato di quello di linux o Windows :D
Uno ancora più "fair" del CFS di Linux :D

A proposito...
Bisogna trovare un nome a questo gioiellino!
Sono aperte le proposte :cool:

CertainDeath

27-02-2010, 21:53

FreeisbetterOS
GeekLinux

Nota speciale: Art Attack WinLinux OS 2010 :D

DanieleC88

27-02-2010, 23:43

Propongo AlphaWinux.

cionci

28-02-2010, 01:00

Uno ancora più "fair" del CFS di Linux :D

Sulla fairness sinceramente non lo so valutare (quelli che tratto attualmente lavorano su pacchetti, sono scheduler per il QoS dei router), ma sicuramente più veloci. Sto lavorando su alcuni scheduler O(1) che garantiscono comunque una buona fairness. Roba che non è stata ancora pubblicata ;)

^TiGeRShArK^

28-02-2010, 01:34

Propongo AlphaWinux.

:asd:

Ryuzaki_Eru

28-02-2010, 01:41

A che punto siete? Non guardo la discussione da un pò.

^TiGeRShArK^

28-02-2010, 01:43

A che punto siete? Non guardo la discussione da un pò.

Hanno finito, stanno varando il progetto Alphawinux "che racchiude il meglio di windows e di linux e fa girare i programmi di tutti e due i sistemi operativi a velocità doppia" (Semicit.) :O

(:asd: )

Mantis-89

28-02-2010, 01:59

ZOS..?

Ryuzaki_Eru

28-02-2010, 02:00

ComOS = Community Operative System.

cdimauro

28-02-2010, 05:17

grazie :D
ora stò lavorando sul loader per gli elf, se tutto va bene i processi saranno pronti fra non molto
Ancora con gli ELF? Ma nessuno pensa di realizzare qualcosa di innovativo? Tutti a riscrivere le stesse cose? :mad:

Z80Fan

28-02-2010, 09:35

FreeisbetterOS
GeekLinux
Nota speciale: Art Attack WinLinux OS 2010 :D
"Unite tutto con abbondante colla vinilica" (cit.) :asd:
Propongo AlphaWinux.
Bello, potrebbe essere un acronimo ricorsivo per "AlphaWinux Is Not UniX" ;)
ZOS..?
Carino, ma un po' anonimo per i miei gusti...
ComOS = Community Operative System.
Bello

Io pensavo a qualcosa di abbastanza identificativo, magari una sigla che suoni bene anche se letta come un'unica parola, e non semplicemente una unione di Windows e Linux. (e non deve per forza finire con OS ;) )

Hanno finito, stanno varando il progetto Alphawinux "che racchiude il meglio di windows e di linux e fa girare i programmi di tutti e due i sistemi operativi a velocità doppia" (Semicit.) :O
(:asd: )
"doppia"? Non sarò contento finchè non andrà il quadruplo :asd:

Sulla fairness sinceramente non lo so valutare (quelli che tratto attualmente lavorano su pacchetti, sono scheduler per il QoS dei router), ma sicuramente più veloci. Sto lavorando su alcuni scheduler O(1) che garantiscono comunque una buona fairness. Roba che non è stata ancora pubblicata ;)
O(1) ???? Bestia...

Ancora con gli ELF? Ma nessuno pensa di realizzare qualcosa di innovativo? Tutti a riscrivere le stesse cose? :mad:
Ok, sei incaricato di scrivere le specifiche per lo CIPALILEFF (Cdimauro's Incredible Python-Amiga-Like Innovative Loadable and Executable File Format) :Prrr:

Un momento per riavviare il computer e vi metto la versione 0.04, vedrete quanta roba ho messo non dovendo più lavorare sul floppy :D

cdimauro

28-02-2010, 09:46

Per me non c'è problema, ma wpython 1.1 lo finisci tu. :D

^TiGeRShArK^

28-02-2010, 10:02

Bello, potrebbe essere un acronimo ricorsivo per "AlphaWinux Is Not UniX" ;)

In realtà era ironico daniele proponendo quel nome. :D

http://www.hwupgrade.it/forum/showthread.php?t=1707247

Leggilo e fatti due risate. :p

Z80Fan

28-02-2010, 10:23

In realtà era ironico daniele proponendo quel nome. :D

http://www.hwupgrade.it/forum/showthread.php?t=1707247

Leggilo e fatti due risate. :p

Azz :asd:

Ora mi cerco sul forum tutti i thread che parlano di fantomatici nuovi sistemi operativi così sono pronto alle battute ;)
EDIT: Lavoro troppo difficile, se conoscete qualche avventuriero in innovativi sistemi operativi avvisatemi ;)
PS: Incredibile ad alphawinux gli avevano fatto anche un logo fighissimo! :eek:

Z80Fan

28-02-2010, 10:48

Ragazzi ho aggiunto la nuovissima versione 0.04 !
I file che trovate in questo archivio non sono ancora completi, devo ancora sistemare una modifica importante al sistema video testuale, la ho messa per mostrarvi le ultimissime novità: il ramdisk e il device menager.

Ditemi cosa ne pensate e cosa da aggiungere/modificare/togliere. :)

C'è anche un problemino con il FAT12, il supporto per i nomi lunghi funziona in parte (l'ultima parte del nome non viene visualizzata correttamente), se qualcuno volesse dare un'occhiata...

CertainDeath

28-02-2010, 11:58

ComOS = Community Operative System è stupendo come nome..

Z80Fan

28-02-2010, 12:17

ComOS = Community Operative System è stupendo come nome..
2 punti per ComOS.

Ryuzaki_Eru

28-02-2010, 12:23

ComOS = Community Operative System è stupendo come nome..

2 punti per ComOS.

Grazie :D

Z80Fan

28-02-2010, 13:36

Se scaricate ora il link della 0.04 trovate una versione compilabile. Ho sistemato il sistema tty.

CertainDeath

28-02-2010, 13:37

Z80 piccola curiosità niubba..
Prevedi anche la creazione di un interfaccia grafica e di un sistema di gestione di pacchetti .deb?

Z80Fan

28-02-2010, 13:42

Z80 piccola curiosità niubba..
Prevedi anche la creazione di un interfaccia grafica e di un sistema di gestione di pacchetti .deb?
Una interfaccia grafica la dobbiamo fare, sennò che sistema operativo moderno è? :D A parte gli scherzi, qualcosa con la grafica la devo fare (e la stò già implementando) per avere più spazio sullo schermo per i messaggi di debug ecc... perchè ora con la modalità testo 80x25 ho veramente poco spazio.
Un sistema con i pacchetti simile ai .deb sarebbe molto utile, ovviamente non possiamo prendere subito i pacchetti .deb già esistenti :)

CertainDeath

28-02-2010, 13:48

ti ho mandato una mail.
Fammi sapere :D

DanieleC88

28-02-2010, 14:14

C'è anche un problemino con il FAT12, il supporto per i nomi lunghi funziona in parte (l'ultima parte del nome non viene visualizzata correttamente), se qualcuno volesse dare un'occhiata...

Mumblemumble, un tempo avevo scritto del codice per gestire un filesystem in FAT12, FAT16 o FAT32, mi pare di ricordare che funzionasse discretamente bene... Devo vedere se riesco a ritrovarlo.

DanieleC88

28-02-2010, 14:17

P.S.: può tornare utile? :D
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx

Z80Fan

28-02-2010, 14:17

Mumblemumble, un tempo avevo scritto del codice per gestire un filesystem in FAT12, FAT16 o FAT32, mi pare di ricordare che funzionasse discretamente bene... Devo vedere se riesco a ritrovarlo.
Molto gentile :)

P.S.: può tornare utile? :D
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
AAAAAH IL NEMICO! :D
Cmq ce lo avevo già quel file ;)

VirtualFlyer

28-02-2010, 15:36

Pur non capendo molto, seguo il 3d e se posso permettermi voto anch'io per ComOs

Kralizek

28-02-2010, 15:38

DanieleC88

28-02-2010, 16:13

ma allora avevi fatto qualcosa :P

Ambe' :O
Sì che avevo fatto qualcosa. :D
Tra l'altro il codice per leggere un filesystem FAT l'avevo scritto in C e poi riscritto in assembler per infilarlo direttamente nel bootloader. Solo a ripensarci mi viene la pelle d'oca. :D

Mantis-89

28-02-2010, 17:00

C'è anche un problemino con il FAT12, il supporto per i nomi lunghi funziona in parte (l'ultima parte del nome non viene visualizzata correttamente), se qualcuno volesse dare un'occhiata...

Mmm, questo mi pare sia un brevetto Microsoft :Prrr: (se ne parlava in una news di qualche mesetto fa)

Ryuzaki_Eru

28-02-2010, 17:09

Ambe' :O
Tra l'altro il codice per leggere un filesystem FAT l'avevo scritto in C e poi riscritto in assembler per infilarlo direttamente nel bootloader. Solo a ripensarci mi viene la pelle d'oca. :D

Piccoli geni crescono[cit.]

Z80Fan

28-02-2010, 18:22

Pur non capendo molto, seguo il 3d e se posso permettermi voto anch'io per ComOs
Grazie :)
3 punti per ComOS
(faccio una battutina: ma non è che assomiglia un po' a Comò o Como OS? ;) )

Mmm, questo mi pare sia un brevetto Microsoft :Prrr: (se ne parlava in una news di qualche mesetto fa)
Ah Aaaah! ecco perchè non mi funziona, la Microsoft mi ha cambiato i sorgenti mentre giocavo in Windows! Tutto torna... :sofico:

Mantis-89

28-02-2010, 18:48

Se ne parla qui (http://www.hwupgrade.it/news/software/microsoft-cita-in-giudizio-tomtom_28198.html)
Cmq ottimo lavoro, la tua è una passione non da poco.

Z80Fan

28-02-2010, 19:01

Se ne parla qui (http://www.hwupgrade.it/news/software/microsoft-cita-in-giudizio-tomtom_28198.html)
Cmq ottimo lavoro, la tua è una passione non da poco.
Praticamente qualsiasi lettore MP3, Macchina Fotografica Digitale, registratori, cellulari, navigatori, dispositivo che memorizza informazioni deve essere ritirato perchè usa il fat32? Allucinante...
Cmq stiamo poco a metterci su l' ext2, che gira anche meglio ;)

M4rk191

28-02-2010, 19:44

Ryuzaki_Eru

28-02-2010, 20:13

Penso proprio di si, quelle parti implementative di basso livello credo vadano scritte in assembly.

Mendocino89

01-03-2010, 07:05

Come altri anche io sto seguendo il thread già da tempo.
ComOS, magari con qualche bel logo stile AlphaWinUx, mi sembra un ottimo nome !
A quando l'interfaccia grafica ???
Magari qualcosa di piu umano da configurare, non come l'X Server !!!:D

Ryuzaki_Eru

01-03-2010, 08:50

Son un genio per quanto riguarda l'ideazione di nomi, dovrei farne un lavoro :sofico:

Z80Fan

01-03-2010, 13:46

Una domanda per soddisfare la mia curiosità:

quali parti del SO è necessario scrivere obbligatoriamente in Assembly?

In particolare mi è venuto in mente che le funzioni della librearia standard, utilizzano chiamate di sistema e mi chiedevo, se le chiamate di sistema dovessero essere scritte per forza in assembly.

Allo stato attuale, le parti che ho dovuto scrivere in assembly sono state poche: il piccolo codice in start.asm che serve semplicemente a chiamare la funzione main in C, e delle funzioncine semplici per impostare i registri hardware del processore. Direi che è d'obbligo l'assembly dove bisogna dare istruzioni specifiche per quel processore. Tutto il resto si scrive tranquillamente in C. Anche le ISR sono in C, quindi per implementare una chiamata a sistema basterebbero poche righe di asm solo per caricare i registri, e poche per estrarli, tutto il resto è puro C.

Come altri anche io sto seguendo il thread già da tempo.
ComOS, magari con qualche bel logo stile AlphaWinUx, mi sembra un ottimo nome !
A quando l'interfaccia grafica ???
Magari qualcosa di piu umano da configurare, non come l'X Server !!!:D
Caspita questo ComOS è molto favorito (anche se non ne sono del tutto convinto)
4 punti per ComOS

L'interfaccia grafica la inserirò dopo aver scritto:
- il modulo vesa
- la libreria di primitive grafiche
- la gestione della memoria
- il file system virtuale
- chiamate di sistema
- il caricamento di programmi
- Moduli caricabili
- la schedulazione dei processi
- tecniche di sincronizzazione
- IPC
- driver per il mouse

:asd:

Sicuramente sarà tutto semplice da configurare, sarà uno degli obiettivi principali dell' intero sistema.