[C] Programmare un Sistema Operativo

[sprik]

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]

Originariamente inviato da Ryuzaki_Eru

Si vede che non conosci cdimauro

Cos'è, ha una brutta reputazione?

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]

Originariamente inviato da sprik

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!

Facevi parte del team di ItaliOS? Ci saresti di grande aiuto!!!

[vhost87]

Originariamente inviato da Ryuzaki_Eru

Si vede che non conosci cdimauro

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

[sprik]

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]

Originariamente inviato da michele.broggi

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

Beh, è cmq un buon OS... Amiga Forever! (Anche se preferisco lo ZX Spectrum)

Originariamente inviato da sprik

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]

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]

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

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

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 veramente enorme, ma credo che reimplamentare 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?

[Z80Fan]

Originariamente inviato da M4rk191

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

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

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

1- Semplicemente perchè ho trovato che i sorgenti di Linux sono veramente complessi e un po' disordinati 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]

Originariamente inviato da Z80Fan

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

In tal caso prendete ispirazione dal Workbench (nelle ultime versioni, però).

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.

Originariamente inviato da Z80Fan

Cos'è, ha una brutta reputazione?

Anche.

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.

Originariamente inviato da michele.broggi

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

Già. Con qualche aggiornamento, però.

Originariamente inviato da Z80Fan

Beh, è cmq un buon OS... Amiga Forever! (Anche se preferisco lo ZX Spectrum)

Vabbé, con quel nick non poteva essere altrimenti.

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

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

[Ryuzaki_Eru]

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.

[vhost87]

Originariamente inviato da Ryuzaki_Eru

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

[Z80Fan]

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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)

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

Vabbé, con quel nick non poteva essere altrimenti.
Tanto lo sai che gli spectrumisti hanno preso sempre mazzate dai commodiariani.
E comunque, il mio C128 aveva sia l'8510 (erede del 6510) che lo Z80.

Nooo non ricominciamo !!!!
Io sono troppo giovane per quel periodo, ma mi sembra che gli spectrummisti non sfigurassero troppo
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 )

Originariamente inviato da Ryuzaki_Eru

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]

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]

complimenti all'autore del thread

[ot]
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
[/ot]

[Ryuzaki_Eru]

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]

Originariamente inviato da Ryuzaki_Eru

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.

Originariamente inviato da michele.broggi

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 ) e mi diverto pure (in modo diverso: astraendo e trovando soluzioni anche "belle" a vedersi).

Originariamente inviato da Z80Fan

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

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 !!!!
Io sono troppo giovane per quel periodo, ma mi sembra che gli spectrummisti non sfigurassero troppo

Dipende da quel che c'era da fare (vedi anche il link del confronto fra C64 e Spectrum, all'inizio dell'articolo).

A parte lo Z80 (è italiano lo sapevi?),

Sì, qualcosina la so.

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.

Originariamente inviato da Giullo

complimenti all'autore del thread

[ot]
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.

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
[/ot]

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]

Originariamente inviato da Z80Fan

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]

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

[Z80Fan]

Scorrere più in basso per leggere gli aggiornamenti

Originariamente inviato da Ryuzaki_Eru

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

Originariamente inviato da Ryuzaki_Eru

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

Originariamente inviato da cdimauro

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.

Tranquillo, anche io non vedo bene i socket come file...

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

Dipende da quel che c'era da fare (vedi anche il link del confronto fra C64 e Spectrum, all'inizio dell'articolo).

Sì, qualcosina la so.

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 )

Originariamente inviato da cdimauro

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

Megaquotone intergalattico

Originariamente inviato da zulutown

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.

Originariamente inviato da Rikiji

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.