View Full Version : [C] Programmare un Sistema Operativo
No, è un'istruzione sbagliata (http://www.cs.dartmouth.edu/~sergey/cs108/2009/F00FBug.html).
Se usata correttamente è una compare-and-swap, comunque.
Aaah era questa l'istruzione del F00F ! Sapevo della sua esistenza, ma non ricordavo lo mnemonico.
Sto implementando il vfs, e ovviamente vado a pensare a idee per le system call, non riesco proprio a pensare ad un argomento alla volta :doh:
Cmq, stavo pensando, che invece di usare int o syscall per creare la syscall (appunto), potevo mettere una tabella alla fine dello spazio virtuale, dove il programma può fare una semplice call, e sarà il codice del kernel a preoccuparsi di cambiare ring (o no) per eseguire la syscall. C'è anche il vantaggio che i parametri della funzione possono essere passati sullo stack, perchè si entra nel kernel con ancora lo stack utente. Se poi la syscall ha bisogno di cambiare modalità, si preoccuperà di spostare i dati in una posizione più comoda, fuori dallo stack utente.
; imposta i parametri o nei registri o nello stack
call [tabellaSysCalls + numSysCall]
; risultati o nello stack o nei registri
è utile o solo più complesso?
Ripropongo anche la questione sulla gestione della memoria (#485, #495), e sulla comunicazione tra processi e driver (#465)
morgoth90
19-05-2010, 15:09
Sto implementando il vfs, e ovviamente vado a pensare a idee per le system call, non riesco proprio a pensare ad un argomento alla volta :doh:
Cmq, stavo pensando, che invece di usare int o syscall per creare la syscall (appunto), potevo mettere una tabella alla fine dello spazio virtuale, dove il programma può fare una semplice call, e sarà il codice del kernel a preoccuparsi di cambiare ring (o no) per eseguire la syscall. C'è anche il vantaggio che i parametri della funzione possono essere passati sullo stack, perchè si entra nel kernel con ancora lo stack utente. Se poi la syscall ha bisogno di cambiare modalità, si preoccuperà di spostare i dati in una posizione più comoda, fuori dallo stack utente.
; imposta i parametri o nei registri o nello stack
call [tabellaSysCalls + numSysCall]
; risultati o nello stack o nei registri
è utile o solo più complesso?
sarebbe molto più semplice che butti nello stack del processo i parametri e chiami un int.
in questo modo il kernel riesce a leggerli usando il tss del task, ovviamente puoi fare delle api per fornire alle applicazioni un set di istruzioni base senza dovere riscrivere ogni volta tutto
sarebbe molto più semplice che butti nello stack del processo i parametri e chiami un int.
in questo modo il kernel riesce a leggerli usando il tss del task, ovviamente puoi fare delle api per fornire alle applicazioni un set di istruzioni base senza dovere riscrivere ogni volta tutto
Si, in effetti dal kernel riesco ad accedere a tutto... bon bon.
E' meglio che, nello spazio virtuale delle applicazioni, il kernel occupi indirizzi elevati (es. oltre 3 Gb), oppure indirizzi bassi (p. es. 0x100000) ?
Nel secondo caso sarebbe più semplice perché il kernel ora viene caricato subito sopra il primo megabyte, se mappo le pagine del kernel in identità, non serve che lo re-linko per gli indirizzi superiori. C'è qualche problema con questa soluzione? Stavo anche pensando che in amd64, lo spazio di indirizzi viene diviso in 2 parti, in base che i bit più significativi siano tutti a 0 o tutti a 1. Con la seconda soluzione, a metà dello spazio di un programma avrei un buco, e dovrei gestirlo, mentre nel secondo caso posso avere il kernel che occupa il blocco superiore, e il programma quello inferiore; oppure usare quello inferiore per il kernel e quello superiore per le applicazioni.
(Se non si è ancora capito, io pianifico di portare tutto il kernel all'architettura 64 bit appena possibile e rompere completamente il supporto ai 32, se non per avviarlo ;) )
Ho un'idea pazza: portare il kernel su un'altra architettura, adesso che è ancora semplice e con poche funzioni. Che architettura mi consigliate? Qualcuna dove ci sia già un port di gcc e compagnia, e che sia documentata e facilmente acessibile. Io avevo pensato all'Amiga, così posso usare i vari emulatori.
morgoth90
21-05-2010, 12:34
Ho un'idea pazza: portare il kernel su un'altra architettura, adesso che è ancora semplice e con poche funzioni. Che architettura mi consigliate? Qualcuna dove ci sia già un port di gcc e compagnia, e che sia documentata e facilmente acessibile. Io avevo pensato all'Amiga, così posso usare i vari emulatori.
non so quanto ti conviene per via della poca diffusione, io punterei su arm visto che ultimamente sembra un architettura su cui stanno spingendo molto per via dei vari dispositivi mobili.
non so quanto ti conviene per via della poca diffusione, io punterei su arm visto che ultimamente sembra un architettura su cui stanno spingendo molto per via dei vari dispositivi mobili.
Si, stavo pensando anche ad ARM. Più che altro invece mi interessava la disponibilità di supporti sul quale provare, tipo emulatori ecc...
potrei puntare anche su mips, visto che mi piace come architettura, ed è emulata da QEMU. In futuro potrei anche pensare di costruirmi una board con uno di questi 2 processori, e farci girare il kernel... per il momento ho solo uno Z80 con 32k di ram :D
cdimauro
21-05-2010, 13:41
Potresti anche provare con questo (http://www.appuntidigitali.it/9518/lamiga-rivive-in-minimig/). :fiufiu: :D
Potresti anche provare con questo (http://www.appuntidigitali.it/9518/lamiga-rivive-in-minimig/). :fiufiu: :D
Devo ammetterlo, ci avevo pensato! Ho anche visto che una ditta italiana produce dei pseudo-amiga con i PowerPC da usare con l'AmigaOS 4.
E il nuovo x1000, avrà un PowerPC ? Perchè se non costa un patrimonio, ed è importato in Italia, ci potrei fare un pensierino... Mi piace che qualcuno abbia il coraggio di entrare in questo mondo dominato da x86 !
Oppure, potrei costruire un computerino con un 68000... le conoscenze per crearne uno ce le ho, mi basta trovare i soldi e il processore giusto... avevo anche pensato di costruirmi un processore per conto mio !!! :D
cdimauro
21-05-2010, 14:46
L'x1000 avrà un PowerPC, per cui non sarà un Amiga (http://www.appuntidigitali.it/9907/native-amiga-natami-il-vero-erede-dellamiga/).
Minimig, poi, non costa molto. Secondo me ne vale la pena. Però occhio che non hai né MMU né virtualizzazione (al limite potresti cambiare il 68000 col 68010 per avere quest'ultima).
Questa è bella:
Stavo leggendo il mio libro di sistemi, quando ho visto uno screenshot (nel capitolo "gestione dispositivi") di una finestra di windows Vista dove si mostrava le proprietà dell'adattatore grafico, che era quello di VirtualBox (evidentemente Vista era emulato). La cosa bella e che mostrava l'indirizzo del framebuffer (0xE0000000), quel magico numeretto che tanto ho penato per trovare...
Infatti funziona correttamente, ora provo a fare una prova, per vedere se anche la macchina reale lo setta a quel indirizzo.
Certo non è molto elegante, poichè non è certo il funzionamento su qualsiasi computer, e con altri bootloader, ma per il momento mi accontento :D, almeno da avere l'alta risoluzione in virtualbox dove posso tenere sotto controllo molti messaggi di debug.
cdimauro
23-05-2010, 04:40
OK, ma quell'indirizzo lo devi prendere in maniera programmatica, non perché l'hai visto in uno screenshot. :D
OK, ma quell'indirizzo lo devi prendere in maniera programmatica, non perché l'hai visto in uno screenshot. :D
Infatti ho scritto che non è il massimo ;) Purtroppo anche grub von la patch non fornisce le informazioni correttamente, oggi provo a creare un floppy/chiavetta usb con grub2, che dovrebbe funzionare meglio e implementa la specifica multiboot 2 (che non sapevo esistesse)
Allora, GRUB 2 non ha dato i risultati sperati (non riuscivo a capire come dirgli di mettere la nuova modalità grafica e di passarla anche al kernel), cmq ho completato il terminale grafico, ora lo posso usare per debuggare seriamente :D
http://z80fan.altervista.org/immagini/SK-0.04c-1024x768.png
come potete vedere, lui riconosce i dati del bootloader, ma non li estrae correttamente. Lavorerò anche su quello, in modo da poter evitare l'artificiosità di inserire manualmente l'indirizzo del framebuffer.
(dovrò lavorare pure su un font migliore, visto che questo è molto sproporzionato tra una lettera e l'altra ;) )
cdimauro
23-05-2010, 19:23
Purtroppo una bacchettata devo dartela per forza, perché hai usato l'italiano e non l'inglese (per quanto non mi piaccia proprio come lingua) per le scritte. :stordita:
Purtroppo una bacchettata devo dartela per forza, perché hai usato l'italiano e non l'inglese (per quanto non mi piaccia proprio come lingua) per le scritte. :stordita:
Dai, ho fatto metà e metà, d'altronde, è pur sempre un progetto italiano :D
Cmq, seriamente, fai conto che la maggior parte di questa roba verrà ripetutamente modificata prima della versione 1, quindi c'è tempo per tradurre. (Ovviamente scritte e commenti dovranno per forza essere tradotti quando lo presenterò ufficialmente)
Risolto !!! Semplicemente, passando la tabella che mi passava GRUB, invece che prelevare una dword, prelevavo una word, quindi tutti i dati precedenti venivano sfalsati di 2 byte in meno. Sistemata la variabile, "magicamente" tutti i dati tornarono corretti :D
cdimauro
24-05-2010, 07:08
Dai, ho fatto metà e metà, d'altronde, è pur sempre un progetto italiano :D
Cmq, seriamente, fai conto che la maggior parte di questa roba verrà ripetutamente modificata prima della versione 1, quindi c'è tempo per tradurre. (Ovviamente scritte e commenti dovranno per forza essere tradotti quando lo presenterò ufficialmente)
Te lo dico perché certi progetti sono cominciati così, e poi te li ritrovi ancora oggi, dopo ANNI di sviluppo, sommersi di commenti, ma anche identificatori (!), nella lingua madre di chi li ha scritti. :muro:
Risolto !!! Semplicemente, passando la tabella che mi passava GRUB, invece che prelevare una dword, prelevavo una word, quindi tutti i dati precedenti venivano sfalsati di 2 byte in meno. Sistemata la variabile, "magicamente" tutti i dati tornarono corretti :D
:eek: Ma tu la struttura come l'avevi creata?
Te lo dico perché certi progetti sono cominciati così, e poi te li ritrovi ancora oggi, dopo ANNI di sviluppo, sommersi di commenti, ma anche identificatori (!), nella lingua madre di chi li ha scritti. :muro:
Allora è meglio che procedo subito :D. Per gli identificatori sono quasi a posto, al massimo funzioni antiche con nomi ancora in italiano, o qualche variabile locale, ma per il resto è tutto in inglese.
:eek: Ma tu la struttura come l'avevi creata?
Una stupidata,
word segmentA;
word segmentB;
dword realFctPtr; // puntatore seg+off <-------
word pitch; // bytes per scanline
word Xres;
word Yres;
quella dword lì prima l'avevo scritta word, scioccamente pensando che i segmenti e gli offset sono a 16 bit, ma li si tratta di segmento E offset, quindi una dword :doh: (per essere precisi avrei dovuto scrivere word offset; word segment; )
cdimauro
24-05-2010, 13:19
Quindi hai fatto a manina. Dovresti utilizzare una sorta di traduttore C -> ASM per evitare problemi.
Quindi hai fatto a manina. Dovresti utilizzare una sorta di traduttore C -> ASM per evitare problemi.
Non capisco cosa intendi dire. Quella struttura la ho presa da qui: http://wiki.osdev.org/Getting_VBE_Mode_Info , solo che li veniva indicato un VBE_FAR, che io inizialmente ho tradotto come word. In realtà il VBE_FAR indicava 2 elementi, ognuno di una word, quindi avrei dovuto scrivere "dword". Per via di quell'errore, Xres prendeva il valore di pitch, Yres quello di Xres, Wchar quello di Xres...
(Chiarisco, quella variabile (realFctPtr) non è di nessuna utilità)
cdimauro
24-05-2010, 13:41
Intendevo dire che esistono dei tool di conversione delle struct dal C ad altri linguaggi, fra cui anche l'assembly x86.
Questo ti avrebbe evitato l'errore che hai commesso.
Intendevo dire che esistono dei tool di conversione delle struct dal C ad altri linguaggi, fra cui anche l'assembly x86.
Questo ti avrebbe evitato l'errore che hai commesso.
Ah ok. Guarda cmq che non c'entra l'assembly, è una struttura C ;) (i word e dword sono solo dei #define unsigned short e unsigned int)
cdimauro
24-05-2010, 20:00
Non me n'ero accorto. :stordita:
morgoth90
25-05-2010, 20:35
con una risoluzione del genere bisogna stare però attenti, i refresh dello schermo iniziano a diventare pesantucci
con una risoluzione del genere bisogna stare però attenti, i refresh dello schermo iniziano a diventare pesantucci
Ho fatto una prova stampando molti numeri, non ho notato troppo rallentamento, certo non ai livelli di una console di testo, ma non eccessivo. Con una memcpy ottimizzata si possono ottenere anche maggiori prestazioni.
Nuova versione del kernel, migliorato il supporto al video VESA (con tanto di supporto per modalità video da 16, 24 o 32 bit per pixel !!!) e, novità maggiore, ho scritto qualche codice per entrare in paginazione! è stato abbastanza semplice attivarla, e ha funzionato subito. La prossima versione del kernel, alla quale comincio a lavorare oggi, attiverà la paginazione molto prima, in modo da poter linkare tutto il kernel ad un indirizzo virtuale elevato (tipo 0xF0000000+). Questa disposizione si chiama "Higher Half Kernel" (http://wiki.osdev.org/Higher_Half_Kernel)
Download versione 0.04c (http://z80fan.altervista.org/kernel/SuperKernel-v0.04c.tar.bz2)
(Ho deciso di non allegare anche l'immagine del floppy da provare, visto che non ha niente di speciale dal lato utente rispetto alle altre versioni)
Quindi hai fatto a manina. Dovresti utilizzare una sorta di traduttore C -> ASM per evitare problemi. il C adesso é diventato un linguaggio talmente astruso che sono venuti a chiamarsi in quel modo i compilatori C? :D
a me piacerebbe molto :asd: mi trovi sempre in prima linea quando si combatte per la deprecazione del linguaggio C in favore di tutti quelli che sono venuti dopo (cioé tutti), ma purtroppo il C é ancora il linguaggio di cui si parla di piu nel web: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
ed é pure in crescita!! ha superato Java O_O'' :cry:
é un dannato cancro é!
edit - ora capisco... C é un'iniziale :stordita:
C come Cancro :asd:
cdimauro
02-06-2010, 21:40
Veramente il discorso era un altro, e il termine "traduttore" mi pare appropriato. :stordita:
P.S. Sull'ultima parte ovviamente concordo. :asd:
il C adesso é diventato un linguaggio talmente astruso che sono venuti a chiamarsi in quel modo i compilatori C? :D
a me piacerebbe molto :asd: mi trovi sempre in prima linea quando si combatte per la deprecazione del linguaggio C in favore di tutti quelli che sono venuti dopo (cioé tutti), ma purtroppo il C é ancora il linguaggio di cui si parla di piu nel web: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
ed é pure in crescita!! ha superato Java O_O'' :cry:
é un dannato cancro é!
edit - ora capisco... C é un'iniziale :stordita:
C come Cancro :asd:
Mi sa che non hanno piu' rinnovato il dominio :asd:
Almeno qui da me da 404 not found, e www.tiobe.com risulta acquistabile.
Edit: Preso :D:D ahahah
Riedit: Noooo. Mi e' arrivata la mail dicendo che non me lo possono dare e non mi dicono perche' :cry:
il C adesso é diventato un linguaggio talmente astruso che sono venuti a chiamarsi in quel modo i compilatori C? :D
a me piacerebbe molto :asd: mi trovi sempre in prima linea quando si combatte per la deprecazione del linguaggio C in favore di tutti quelli che sono venuti dopo (cioé tutti), ma purtroppo il C é ancora il linguaggio di cui si parla di piu nel web: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
ed é pure in crescita!! ha superato Java O_O'' :cry:
é un dannato cancro é!
edit - ora capisco... C é un'iniziale :stordita:
C come Cancro :asd:
Più che altro si è ripreso la posizione che Java gli aveva preso qualche tempo fa ;)
Cmq, visto che stiamo parlando di sistemi operativi, al momento non ci sono linguaggi che ti permettono di fare le operazioni di basso livello necessarie alla programmazione di quest'ultimo. Nei linguaggi come Python, Java ecc.. hai bisogno di una macchina virtuale, che essa stessa fa quindi da kernel, e in quel caso la devi per forza programmare con un linguaggio come il C, oppure la devi fare in assembly, e non penso che tu sia un fan dell'assembly ;)
Anche il C++ si può usare, ma ci sono alcuni accorgimenti da tenere presente, e non si possono usare funzionalità troppo "spinte".
http://wiki.osdev.org/Languages
Altri linguaggi utilizzabili sarebbero Pascal e Forth, ma poichè non li conosco non mi esprimo su di loro.
Cmq, visto che stiamo parlando di sistemi operativi, al momento non ci sono linguaggi che ti permettono di fare le operazioni di basso livello necessarie alla programmazione di quest'ultimo.
In realta' ce ne sono, anche se sono meno usati.
Il forth e' stato usato molto soprattutto per dispositivi embedded in quanto si riesce a fare veramente tanto con una memoria molto ridotta. In pochi Kb riesci ad avere sistema operativo E compilatore, usando una manciata di assembler.
Se cerchi in rete trovi diversi esempi a riguardo.
Se hai mai avuto un Mac con processore PowerPC, allora avevi un bios (l'openfirmware) scritto in forth.
Altri esempi "passati" sono Genera, il sistema operativo delle Lisp Machine della Symbolics, scritto appunto in lisp.
http://en.wikipedia.org/wiki/Genera_%28operating_system%29
Il sistema operativo e l'ide fornivano quello che in un desktop normale ci siamo abituati ad avere venti anni dopo.
In generale non e' impossibile scrivere un sistema operativo in qualsiasi linguaggio, ovviamente per certi linguaggi diventa piu' difficile perche' devi fare molto piu' lavoro. Trovi S.O. (amatoriali) nei linguaggi piu' disparati, da smalltalk a java a C#...
Il discorso comunque e' molto articolato e sto andando OT :P
DanieleC88
03-06-2010, 18:06
Trovi S.O. (amatoriali) nei linguaggi piu' disparati, da smalltalk a java a C#...
Be' per C# c'è Singularity che non è così "amatoriale"... :D
Io sono parecchio incuriosito dall'idea di un sistemino operativo in Python, non so se qualcuno ha già fatto qualcosa del genere, dovrò informarmi per bene.
In realta' ce ne sono, anche se sono meno usati.
Il forth e' stato usato molto soprattutto per dispositivi embedded in quanto si riesce a fare veramente tanto con una memoria molto ridotta. In pochi Kb riesci ad avere sistema operativo E compilatore, usando una manciata di assembler.
Se cerchi in rete trovi diversi esempi a riguardo.
Se hai mai avuto un Mac con processore PowerPC, allora avevi un bios (l'openfirmware) scritto in forth.
Altri esempi "passati" sono Genera, il sistema operativo delle Lisp Machine della Symbolics, scritto appunto in lisp.
http://en.wikipedia.org/wiki/Genera_%28operating_system%29
Il sistema operativo e l'ide fornivano quello che in un desktop normale ci siamo abituati ad avere venti anni dopo.
In generale non e' impossibile scrivere un sistema operativo in qualsiasi linguaggio, ovviamente per certi linguaggi diventa piu' difficile perche' devi fare molto piu' lavoro. Trovi S.O. (amatoriali) nei linguaggi piu' disparati, da smalltalk a java a C#...
Il discorso comunque e' molto articolato e sto andando OT :P
Ho dato un'occhiata a Wikipedia a proposito del Forth: interessante, ma non riesco a immaginare un grosso progetto scritto tutto in quel modo (nota: non ho detto che non si può fare). Lisp lo trovo già migliore, solo che ti obbliga a fare tutto con le liste, dovrei cambiare il mio modo di programmare. Interessanti anche le Lisp machines.
Cmq, come dicevo prima, per i linguaggi che necessitano di una macchina virtuale, devi per forza usare qualcosa di più basso livello, che sia solo assembly o c / forth / lisp e assembly. Sarebbe un controsenso alla tua firma avere un linguaggio che necessita di un altro linguaggio per essere operativo ;)
La cosa che mi piace tanto dei linguaggi "managed", è che non servono sistemi di protezione della memoria, perchè viene tutto tracciato dalla macchina virtuale o al momento della compilazione: si potrebbero far girare su processori minuscoli e velocissimi, che azzererebbero l'overhead (anche se piccolo) di una macchina virtuale.
Be' per C# c'è Singularity che non è così "amatoriale"...
Io sono parecchio incuriosito dall'idea di un sistemino operativo in Python, non so se qualcuno ha già fatto qualcosa del genere, dovrò informarmi per bene.
Prometto che, una volta che il kernel sarà operativo, con un piccolo aiutino inserirò la possibilità di scrivere moduli in python :)
demonbl@ck
03-06-2010, 18:50
Se vi serve una mano per scrivere funzioni relativamente semplici che non vadano ad interagire con le periferiche (non sono in grado, sono in terza itis e oltretutto studio java , non c :stordita: ), io ci sono :D
Se vi serve una mano per scrivere funzioni relativamente semplici che non vadano ad interagire con le periferiche (non sono in grado, sono in terza itis e oltretutto studio java , non c :stordita: ), io ci sono :D
Grazie del supporto :)
Come sei messo con i puntatori? e le liste (semplicemente concatenate)? Potresti essere utile per la gestione della memoria...
demonbl@ck
03-06-2010, 19:50
Grazie del supporto :)
Come sei messo con i puntatori? e le liste (semplicemente concatenate)? Potresti essere utile per la gestione della memoria...
In che senso i puntatori?
Le liste ce le ha accennate, ma non le abbiamo ancora fatte.
Cioè so cos'è una lista, ma non le abbiamo mai usate.
Se serve mi scarico qualche tutorial, tanto l'anno prossimo le dobbiamo fare :D
EDIT: ti aggiungo su msn
Ho trovato una cosa che assomiglia ad un sistema operativo scritto in Python:
http://code.google.com/p/cleese/
non ho indagato in profondità, ma sembra solo la macchina virtuale che gira senza un os sotto. può essere interessante cmq.
In che senso i puntatori?
Ah già, in Java non si lavora sporco con i puntatori :asd:
Le liste ce le ha accennate, ma non le abbiamo ancora fatte.
Cioè so cos'è una lista, ma non le abbiamo mai usate.
Se serve mi scarico qualche tutorial, tanto l'anno prossimo le dobbiamo fare :D
Visto che usate Java, probabilmente userete degli oggetti lista già pronti, mi serviva piuttosto che tu sapessi come crearle a mano, con strutture nodo e puntatori di collegamento. Ci sono moltissimi tutorial su internet se vuoi imparare il C, come strutture di base non è differente dal Java (il Java prende la sintassi dal C++ che la prende dal C), e se sei all'itis, farete sicuramente assembly, quindi non sarà difficile capire i puntatori :)
EDIT: ti aggiungo su msn
Aggiunto :) Arriverò in linea appena possibile.
DanieleC88
03-06-2010, 20:13
Ho trovato una cosa che assomiglia ad un sistema operativo scritto in Python:
http://code.google.com/p/cleese/
non ho indagato in profondità, ma sembra solo la macchina virtuale che gira senza un os sotto. può essere interessante cmq.
L'avevo visto anche io, ma è nato nel 2003 e mi pare un po' abbandonato (l'attività segnalata è bassa, e il Wiki è stato piallato a febbraio).
cdimauro
03-06-2010, 20:51
Io sono parecchio incuriosito dall'idea di un sistemino operativo in Python, non so se qualcuno ha già fatto qualcosa del genere, dovrò informarmi per bene.
https://launchpad.net/pycorn
Prometto che, una volta che il kernel sarà operativo, con un piccolo aiutino inserirò la possibilità di scrivere moduli in python :)
Conviene più a te, perché ti sbrigheresti molto prima nel realizzare comandi e applicazioni varie. ;)
Comunque poi vedremo (ma non prometto niente perché sono oberato da impegni).
Ho trovato una cosa che assomiglia ad un sistema operativo scritto in Python:
http://code.google.com/p/cleese/
non ho indagato in profondità, ma sembra solo la macchina virtuale che gira senza un os sotto. può essere interessante cmq.
Qualcos'altro qui: http://tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy , oltre al link poco più sopra.
Comunque attualmente c'è un'implementazione minimale di Python per sistemi embedded che va per la maggiore (c'è qualche sviluppatore ufficiale di CPython che ci lavora), ma non ricordo come si chiama e non sono riuscito a recuperare nulla.
DanieleC88
03-06-2010, 21:14
https://launchpad.net/pycorn
Ma che figata, appena ho tempo me lo spulcio per benino. :D
Grazie Cesare ;)
Ciao, mi intrometto anche se ammetto di non aver letto tutte le pagine (magari in un giorno di penitenza lo farò :D ).
Può darsi che quanto stò per dire sia già stato detto, ma il supporto ai floppy, che comunque mi pare non sia più in lavorazione, è tempo perso, tenendo presente che oggigiorno pochissimi computer moderni hanno il lettore floppy disk e che nel 2011 anche Sony smetterà di produrli. Da qualche parte ho letto che era la sola rimasta a produrli, se cosi fosse tra non molto non ne troverete nemmeno più (io ne farò una scorta da rivendere agli appassionati :fagiano:).
Prometto che, una volta che il kernel sarà operativo, con un piccolo aiutino inserirò la possibilità di scrivere moduli in python :)
Mi permetto di darti del tu.
Occhio a quello che prometti :)
Certamente sarebbe una cosa molto interessante, se dovesse servirti una mano nell'implementazione potrei aiutarti con le C/API, le conosco piuttosto bene.
Vorrei sottolineare che in qualche caso le versioni preinstallate dei linguaggi di programmazione, risultano essere fastidiose quando l'utente vuole installare una versione più recente dello stesso e si trova il conflitto costringendolo, ad esempio, o a smanettare con le variabili d'ambiente o dover richiamare l'interprete usando (nel caso di Python) pythonx (dove x = numero di versione). Non sò poi il tuo target :)
Ciao,
Lex.
Conviene più a te, perché ti sbrigheresti molto prima nel realizzare comandi e applicazioni varie. ;)
Ok, per comandi e applicazioni, ma io intendevo proprio moduli del sistema operativo, come driver, filesystems ecc... :)
Può darsi che quanto stò per dire sia già stato detto, ma il supporto ai floppy, che comunque mi pare non sia più in lavorazione, è tempo perso, tenendo presente che oggigiorno pochissimi computer moderni hanno il lettore floppy disk e che nel 2011 anche Sony smetterà di produrli. Da qualche parte ho letto che era la sola rimasta a produrli, se cosi fosse tra non molto non ne troverete nemmeno più (io ne farò una scorta da rivendere agli appassionati :fagiano:).
Si, il controller floppy ho smesso di cercare di farlo funzionare molto tempo fa, ma non per l'obsolescenza del supporto, ma perchè il controller era complicatissimo da far funzionare!
Purtroppo è l'unica periferica abbastanza semplice da poter usare per accedere a un supporto e caricare file; per usare una semplice chiavetta usb, bisogna prima avere un driver per il bus pci (il controller USB è collegato al PCI), e quindi scrivere il driver usb, differenziando tra i vari standard e modalità di trasferimento. I dischi fissi IDE sono mooolto più semplici da programmare (ho letto un documento tempo addietro), perchè non ti obbligano a lavorare anche con la meccanica del disco (con il floppy bisognava impostare tempistiche di lettura/scrittura, accendere manualmente i motori, e se sgarravi un valore non leggeva nulla!), ma non sono supporti rimovibili. Sui cd-rom non mi esprimo perchè non conosco l'interfaccia.
Cmq ci sono ancora TDK e Verbatim che li producono, se vuoi fare scorta ... ;)
Certamente sarebbe una cosa molto interessante, se dovesse servirti una mano nell'implementazione potrei aiutarti con le C/API, le conosco piuttosto bene.
Sarebbe molto utile, ti farò sapere quando il sistema è sufficientemente operativo :)
Vorrei sottolineare che in qualche caso le versioni preinstallate dei linguaggi di programmazione, risultano essere fastidiose quando l'utente vuole installare una versione più recente dello stesso e si trova il conflitto costringendolo, ad esempio, o a smanettare con le variabili d'ambiente o dover richiamare l'interprete usando (nel caso di Python) pythonx (dove x = numero di versione). Non sò poi il tuo target :)
Se la tua preoccupazione è quella di avere moduli critici dell'os che lavorano solo con una certa versione di un interprete (mettiamo interprete 1.0), ma l'utente vuole installare l'interprete 2.0, diciamo che, con la mia idea, non dovrebbero esserci conflitti: non so se conosci GoboLinux, è una distribuzione Linux, che modifica la disposizione standard del filesystem Unix. Un vantaggio della distinzione è che l'utente può installare diverse versioni di uno stesso programma contemporaneamente, ognuna in una sua cartella, e usare quella che gli fa più comodo per un certo lavoro. C'è anche un collegamento simbolico alla versione "preferita" dell'interprete. Quindi può avere python26 e python3, con un collegamento python che punta ad esempio a python3. In questo caso, possiamo dire all'os di prendere python26 per i moduli che ancora ne hanno bisogno, e lasciare l'utente libero di installare qualsiasi versione.
Cmq, per generalizzare, intendo dire che non devono per forza essere in python i moduli, ma che possono essere scritti in qualsiasi linguaggio anche interpretato; quando il kernel si caricherà il modulo, caricherà anche il suo interprete specificato.
http://wiki.osdev.org/Higher_Half_Kernel
Cosa ne pensate ? I motivi elencati nella pagina vi sembrano appropriati per motivare il caricamento del kernel nella parte alta? Avete esperienza di sistemi operativi che caricano il kernel nella parte bassa della memoria?
Io avevo pensato di lasciare il kernel mappato 1:1 nella parte bassa, e far partire la applicazioni da 0x10000000. Se c'è un buon motivo per caricare il kernel nella parte alta, posso anche cambiare.
grigor91
04-06-2010, 17:00
Visto che usate Java, probabilmente userete degli oggetti lista già pronti, mi serviva piuttosto che tu sapessi come crearle a mano, con strutture nodo e puntatori di collegamento.
Se ti interessa me la cavo bene con puntatori, code, alberi, liste etc..., solo che in questo periodo sono impegnato con gli esami e la tesina.
cdimauro
04-06-2010, 19:39
Ok, per comandi e applicazioni, ma io intendevo proprio moduli del sistema operativo, come driver, filesystems ecc... :)
[...]
Cmq, per generalizzare, intendo dire che non devono per forza essere in python i moduli, ma che possono essere scritti in qualsiasi linguaggio anche interpretato; quando il kernel si caricherà il modulo, caricherà anche il suo interprete specificato.
Mi pare un po' difficile, perché presuppone che parecchie API del kernel e roba come libc siano già funzionanti e utilizzabili.
Si può provare a vedere, invece, di adattare qualche "Python for embedded systems" per scrivere velocemente codice di basso livello.
http://wiki.osdev.org/Higher_Half_Kernel
Cosa ne pensate ? I motivi elencati nella pagina vi sembrano appropriati per motivare il caricamento del kernel nella parte alta? Avete esperienza di sistemi operativi che caricano il kernel nella parte bassa della memoria?
Io avevo pensato di lasciare il kernel mappato 1:1 nella parte bassa, e far partire la applicazioni da 0x10000000. Se c'è un buon motivo per caricare il kernel nella parte alta, posso anche cambiare.
Non vedo particolari vantaggi nell'usare la parte alta della memoria.
Anzi, io userei quella bassa per il kernel, proteggendo però dalla locazione 0 fino a qualche pagina in modo provocare dei segmentation fault, e cercare, quindi, di segnalare la presenza di tentativi di derefenziamento di puntatori nulli (non funzionerà sempre, ma è già qualcosa).
Questa è bella:
Stavo leggendo il mio libro di sistemi, quando ho visto uno screenshot (nel capitolo "gestione dispositivi") di una finestra di windows Vista dove si mostrava le proprietà dell'adattatore grafico, che era quello di VirtualBox (evidentemente Vista era emulato). La cosa bella e che mostrava l'indirizzo del framebuffer (0xE0000000), quel magico numeretto che tanto ho penato per trovare...
Infatti funziona correttamente, ora provo a fare una prova, per vedere se anche la macchina reale lo setta a quel indirizzo.
Certo non è molto elegante, poichè non è certo il funzionamento su qualsiasi computer, e con altri bootloader, ma per il momento mi accontento :D, almeno da avere l'alta risoluzione in virtualbox dove posso tenere sotto controllo molti messaggi di debug.
curiosità, su quale libro hai trovato quello screenshot?
curiosità, su quale libro hai trovato quello screenshot?
Immagine (http://www.loescher.it/Catalogo/Handlers/WorkImageHandler.ashx?WorkImageCode=O_J629)
Scheda (http://www.loescher.it/Catalogo/WorkDetails.aspx?WCode=O_J589&Tab=Catalog)
Volume 2: Sistemi Operativi, seconda edizione.
(non so se sul forum posso mettere più informazioni, in caso contattami tramite messaggio privato)
Oddio. Questo libro è usato in TUTTI gli itis informatici. Anzi, tutti e tre i volumi lo sono :D
Oddio. Sto libro è usato in TUTTI gli itis informatici per sistemi. Anzi, tutti e tre i volumi lo sono :D
2 cause: o sono tanto buoni, o hanno il monopolio (mamma Microsoft insegna :asd: )
Immagine (http://www.loescher.it/Catalogo/Handlers/WorkImageHandler.ashx?WorkImageCode=O_J629)
Scheda (http://www.loescher.it/Catalogo/WorkDetails.aspx?WCode=O_J589&Tab=Catalog)
Volume 2: Sistemi Operativi, seconda edizione.
(non so se sul forum posso mettere più informazioni, in caso contattami tramite messaggio privato)
grazie della risposta. Volevo regalare qualche testo al mio cuginetto, secondo te la collana è valida? Purtroppo gli istituti tecnici della mia zona non offrono percorsi di studio molto validi, quindi necessitano di molta "integrazione".
Grazie in anticipo
grazie della risposta. Volevo regalare qualche testo al mio cuginetto, secondo te la collana è valida? Purtroppo gli istituti tecnici della mia zona non offrono percorsi di studio molto validi, quindi necessitano di molta "integrazione".
Grazie in anticipo
Si, secondo me i testi sono fatti molto bene (non posso dirti del 3 perchè ancora non lo ho), e offrono una buona preparazione, dopo di questi si può passare tranquillamente a testi universitari non troppo spinti :)
Allora, ho sistemato l'allocatore di pagine, e risolto qualche subdolo bug. Ho migliorato le ISR, scrivendole completamente in assembly (al massimo chiamo dall' assembly una funzione complessa C, come ho fatto per la tastiera), invece di usare funzioni C e usare inline assembly per piazzare l'iret.
Poi ho aggiunto un comando alla shell :D "ticks" che ritorna il numero di "tick" dell'orologio dall'avvio del sistema.
Ora devo mettere su tutto l'impianto per mappare le pagine virtuali a quelle fisiche, dopo di che passo alla creazione di un allocatore di memoria tipo malloc().
Accidenti, ne è passato di tempo dall' ultimo post... e da quel tempo non ho più toccato il kernel, in parte per il mio nuovo thread (http://www.hwupgrade.it/forum/showthread.php?t=2209718), in parte per il mio nuovo lavoro.
Voglio cmq assicurare che il progetto non è stato abbandonato e presto ci saranno nuovi aggiornamenti :)
Teo@Unix
03-07-2010, 18:01
è parecchio che vengo a leggere qui di tanto in tanto, complimenti per il progetto e soprattutto per la costanza nel portarlo avanti.
è parecchio che vengo a leggere qui di tanto in tanto, complimenti per il progetto e soprattutto per la costanza nel portarlo avanti.
Grazie :)
E' tempo di release :D !!!
Vi presento a voi la versione 0.04d, ecco una breve lista di innovazioni e i link per scaricare sia i sorgenti sia l'immagine floppy già pronta:
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 !
Sorgenti versione 0.04d (http://z80fan.altervista.org/kernel/SuperKernel-v0.04d.tar.bz2)
Immagine floppy con kernel 0.04d (http://z80fan.altervista.org/kernel/ImmaginiDischi/floppy-grub-kernel-0.04d.tar.bz2)
Ora che abbiamo un allocatore di memoria, si possono cominciare a fare le cose divertenti :D Filesystem, processi, moduli caricabili...
Fatemi sapere cosa ne pensate, se avete idee/suggerimenti/insulti dite pure!
- Una cosa che ho cominciato a pensare: quando si passerà alla versione 0.05 ? Non ho definito bene un piano di sviluppo...
Insieme alla nuova versione, riapro il tema del nome dell' OS, in modo da aprire un server Git con il nome definitivo e sfruttare quel benedetto account SourceForge.
http://sourceforge.net/projects/superkernel/
Insieme alla nuova versione, riapro il tema del nome dell' OS, in modo da aprire un server Git con il nome definitivo e sfruttare quel benedetto account SourceForge.
MyOS? :)
kOS - kool Operating System?:stordita:
kOS - kool Operating System?:stordita:
:D
HWOS :D :D :D :D :D :D :D :D
Continuo a dire che non puoi avere un nome originale senza una funzione o un obiettivo originale :D
Sparo a caso:
-YAOS, Yet Another OS (che spiega tutto) :asd:
-caOS, inventati il significato di ca. Il logo sarebbe tipo quello di Spore (http://fc02.deviantart.net/fs31/f/2008/207/e/b/Spore_Logo_by_hakeryk2.jpg)
-Uno (in onore di PK :asd: ) (ma è già preso per la mia rivoluzionaria IA)
-Mark 0
-MyOS
Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali :read:
DanieleC88
01-10-2010, 01:28
-caOS, inventati il significato di ca.
Eh no, troppo tardi. Quello era il nome che alla fine avevo dato al mio famoso sistema operativo. :Prrr:
:ciapet:
Continuo a dire che non puoi avere un nome originale senza una funzione o un obiettivo originale :D
Sparo a caso:
-YAOS, Yet Another OS (che spiega tutto) :asd:
-caOS, inventati il significato di ca. Il logo sarebbe tipo quello di Spore (http://fc02.deviantart.net/fs31/f/2008/207/e/b/Spore_Logo_by_hakeryk2.jpg)
-Uno (in onore di PK :asd: ) (ma è già preso per la mia rivoluzionaria IA)
-Mark 0
-MyOS
Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali :read:
CaccamOS?
:D :D :D :D :D :D :D :D :D :D :D :D :D :D
http://papoff.altervista.org/immagini/caccamo.jpg
-YAOS, Yet Another OS (che spiega tutto) :asd:
O anche Pinos (pinos is not an os) :cool:
-Uno (in onore di PK :asd: ) (ma è già preso per la mia rivoluzionaria IA)
Poi ovviamente me la compili così la uso come console vero? :O
-Mark 0
Diciamo Mark -1 visto le funzionalità attuali :D
-MyOS
:eek: http://www.myos.org/
Sennò tra nomi di pianeti e quant'altro c'è da sbizzarrirsi, o perchè non animali :read:
Avevo anche pensato a nomi italiani, tipo Leonardos.
(Ovviamente non è necessario metterci OS alla fine, solo se suona bene)
Discutiamo anche di questo: che funzioni vorreste avere implementate in un OS? Sia da lato "utente" (cioè ad esempio sull'interfaccia), sia dal lato "programmatore" (librerie, utilità di programmazione tipo Visual*)...
Scrivete qualsiasi cosa vi passi in mente, non importa quanto strana o complessa ;)
Discutiamo anche di questo: che funzioni vorreste avere implementate in un OS? Sia da lato "utente" (cioè ad esempio sull'interfaccia), sia dal lato "programmatore" (librerie, utilità di programmazione tipo Visual*)...
Scrivete qualsiasi cosa vi passi in mente, non importa quanto strana o complessa ;)
Shell Python.
Dunque... vorrei un file explorer veramente fluido, anche meglio di quello di Mac OS X: qualcosa che riesca a mostrare una gerarchia di folders in una stessa schermata, permettendo di spostare e lavorare sui files di tutti i livelli.
E voglio che tutta l'interfaccia sia pensata per il single click + drag&drop.
Magari falla anche con azioni scriptabili con blocconi visuali trascinabili e configurabili.
Poi ci voglio un "clipboard shelf" che esce fuori quando copi qualcosa, come la barra di mac:
Ctrl+C quindi invece di copiare una sola cosa e rimpazzare la vecchia, si va ad aggiungere alle "note" precedenti: quindi per incollare basta fare doppio click sull'icona col mouse, o premere Ctrl+0...9, o Ctrl+V per la testa della pila.
Non so quante volte avrei pagato oro per una cosa del genere.
Poi ci voglio un supporto al threading avanzato nativo, che espone API basate sul pattern del Task Dispatcher tipo Intel TBB, Poco o JobSwarm.
Poi servirebbe un sottosistema grafico 2D completamente basato sulla scheda video, che offre 3 livelli:
-uno openGL like per disegnare in HW set di dati sui vertici
-uno tipo Quartz/WPF che usa il "parent" per disegnare primitive grafiche come immagini linee e quant'altro.
-il più alto usa il 2° per disegnare finestre standard configurabili da file di dati.
Anche una repository di programmi e SDKs non gestibili a mano ma solo da una routine del SO sarebbe eccellente, riducendo il casino pazzesco dei vecchi SO.
Insomma, l'installer dovrebbe essere parte del sistema operativo, e dovrebbe tenere traccia di tutti i file eseguibili che entrano ed escono.
Un programma non trattato dall'installer non parte.
Poi le applicazioni dovrebbero avere un protocollo stringente di chiamate dal/al SO, il cui rispetto viene validato dall'installer: ad esempio dovrebbero riferire quando hanno finito di accendersi, di caricare, dovrebbero chiedere il permesso quando stanno per iniziare qualcosa di pesante, e notificare quando finiscono.
Allo stesso tempo il SO può notificare il suo stato e aspettarsi che le app facciano qualcosa, come nel caso dello sleep che non sarebbe un dump dello stato della memoria, ma una cosa fatta a mano da ogni applicazione, che salva i dati strettamente necessari su disco.
Con una cosa del genere, si potrebbe anche mettere in sleep selettivamente una sola applicazione pesante e usare il pc per altro :D
Il che ci porta ad aggiungere un terzo stato all'esecuzione delle applicazioni: Attivo, in Background e Congelato.
Ah, OGNI SINGOLA transazione di rete passa attraverso il SO, sennò viene bloccata. E il SO volendo può loggare tutti i dati emessi e ricevuti da un'app.
Quando un'app richiede accesso in scrittura o in lettura, l'installer lo fa presente all'utente.
In sostanza tra questo e la cartella schermata, è del tutto impossibile smanacciare con le applicazioni, sia per l'utente sia per i malintenzionati; inoltre le applicazioni non sono più in posizione di comando sul sistema operativo: essendo ospiti, devono comportarsi educatamente e chiedere permesso :asd:
Sarebbe utilissimo per cose tipo le applicazioni che si aprono all'avvio, che potrebbero essere fatte partire una dopo l'altra sul segnale di "load complete" della precedente, senza intasare il sistema accendendosi tutte assieme (vero windows?).
Oppure per segnalare all'utente "il sistema è sotto carico, vuoi davvero continuare e scrivere sto DVD", o per sapere se un'App è a schermo intero, o se consuma batteria, o se emette suoni, etc.
E tanta tanta altra roba :D
Anche se comprendo che al 99% non arriverai nemmeno vicino a questo tipo di problemi :asd:
Slayer86
01-10-2010, 13:56
Tommo... sei un genio...la maggior parte delle cose che hai scritto non le avevo nemmeno pensate! XD
Certo con un simile sistema sarebbe improponibile il porting di qualsiasi applicazione scritta per altri OS...
Però alcune chicche... come lo stack per il copia incolla :fagiano: sarebbe da proporre agli sviluppatori di qualche DE open...
Tommo... sei un genio...la maggior parte delle cose che hai scritto non le avevo nemmeno pensate! XD
Certo con un simile sistema sarebbe improponibile il porting di qualsiasi applicazione scritta per altri OS...
Però alcune chicche... come lo stack per il copia incolla :fagiano: sarebbe da proporre agli sviluppatori di qualche DE open...
Grazie :D
Comunque spinto dalla gegnalità dell'idea dello stack (che m'è venuta mentre scrivevo tra l'altro) ho guardato su internet come realizzarla... ed esiste già, almeno per Mac:
CopyPaste Pro (http://www.plumamazing.com/mac/copypaste/)
Peccato :asd:
Certo integrata nel SO funzionerebbe meglio.
Comunque i modi per rivoluzionare un SO moderno sarebbero veramente tanti, anche per questo Linux non mi è simpatico: è tutto libero, tutti decidono tutto... e poi sono i primi ad attaccarsi a tradizioni decennali come la riga di comando, server X e compagnia bella.
Poi arriva Apple, che è chiusa e cattiva, e con IOS cambia tutte le carte in tavola :read:
Infatti il 99% delle idee nel mio post zitte zitte vengono dall'architettura di quello :asd:
Forse prima di pensare al nome non sarebbe meglio pensare alle sue funzionalità o al suo obiettivo, e in base ad essi pensare un nome adeguato?
khelidan1980
01-10-2010, 19:51
Grazie :D
Comunque spinto dalla gegnalità dell'idea dello stack (che m'è venuta mentre scrivevo tra l'altro) ho guardato su internet come realizzarla... ed esiste già, almeno per Mac:
CopyPaste Pro (http://www.plumamazing.com/mac/copypaste/)
Peccato :asd:
Se ho capito bene esiste pure per win:
http://bluemars.org/clipx/
;)
cdimauro
01-10-2010, 22:16
Per il nome ecco la soluzione definitiva:
BaldiOS
e non c'è storia: ho anche tonnellate di materiale, pure di merchadising. Roba che Linux può soltanto sognarsi:
http://www.fantasylands.net/news_gallery/anime_robot/baldios/baldios1c.jpg
A parte che Tux finirebbe affettato. :D
blackskop
01-10-2010, 22:34
rockOS
http://biografieonline.it/img/bio/r/Rocco_Siffredi.jpg
:stordita:
Shell Python.
Erà già nei miei piani, visti i precedenti consigli di altri utenti.Dunque... vorrei un file explorer veramente fluido, anche meglio di quello di Mac OS X: qualcosa che riesca a mostrare una gerarchia di folders in una stessa schermata, permettendo di spostare e lavorare sui files di tutti i livelli.
E voglio che tutta l'interfaccia sia pensata per il single click + drag&drop.
Magari falla anche con azioni scriptabili con blocconi visuali trascinabili e configurabili.
Ok.Poi ci voglio un "clipboard shelf" che esce fuori quando copi qualcosa, come la barra di mac:
Ctrl+C quindi invece di copiare una sola cosa e rimpazzare la vecchia, si va ad aggiungere alle "note" precedenti: quindi per incollare basta fare doppio click sull'icona col mouse, o premere Ctrl+0...9, o Ctrl+V per la testa della pila.
Non so quante volte avrei pagato oro per una cosa del genere.Si, è un'idea geniale!Poi ci voglio un supporto al threading avanzato nativo, che espone API basate sul pattern del Task Dispatcher tipo Intel TBB, Poco o JobSwarm.Anche come Grand Central Dispatch? Cmq vedrò quando implementerò lo scheduler.Poi servirebbe un sottosistema grafico 2D completamente basato sulla scheda video, che offre 3 livelli:
-uno openGL like per disegnare in HW set di dati sui vertici
-uno tipo Quartz/WPF che usa il "parent" per disegnare primitive grafiche come immagini linee e quant'altro.
-il più alto usa il 2° per disegnare finestre standard configurabili da file di dati.Mi sembra un buono stack. Cosa intendi dire per "completamente basato sulla scheda video"? Che è studiato per prendere il meglio dalle nuove tecnologie?Anche una repository di programmi e SDKs non gestibili a mano ma solo da una routine del SO sarebbe eccellente, riducendo il casino pazzesco dei vecchi SO.
Insomma, l'installer dovrebbe essere parte del sistema operativo, e dovrebbe tenere traccia di tutti i file eseguibili che entrano ed escono.
Un programma non trattato dall'installer non parte.Capito, come succede su Android no? L'applicazione (o almeno il suo file di installazione) deve definire i servizi che l'applicazione accederà.Poi le applicazioni dovrebbero avere un protocollo stringente di chiamate dal/al SO, il cui rispetto viene validato dall'installer: ad esempio dovrebbero riferire quando hanno finito di accendersi, di caricare, dovrebbero chiedere il permesso quando stanno per iniziare qualcosa di pesante, e notificare quando finiscono.
Allo stesso tempo il SO può notificare il suo stato e aspettarsi che le app facciano qualcosa, come nel caso dello sleep che non sarebbe un dump dello stato della memoria, ma una cosa fatta a mano da ogni applicazione, che salva i dati strettamente necessari su disco.
Con una cosa del genere, si potrebbe anche mettere in sleep selettivamente una sola applicazione pesante e usare il pc per altro :D
Il che ci porta ad aggiungere un terzo stato all'esecuzione delle applicazioni: Attivo, in Background e Congelato.E' una buona idea; tuttavia, è un po' utopistica: come puoi fidarti delle applicazioni? Finchè le scrivi te è un conto, ma secondo te un programmatore che vuole far sembrare la sua applicazione velocissima, seriamente chiederebbe il permesso all'OS che *potrebbe* rallentarla (anche se con un motivo valido)?
In secondo luogo, dover gestire tutti questi eventi allungherebbe la scrittura del programma, quindi: o si lascia l'opzione al programmatore se gestire o meno gli eventi, e la maggior parte delle applicazioni non la userà, oppure metterlo d'obbligo facendo quindi allontanare tutti quei programmatori suddetti che non hanno voglia di gestire tutti questi dettagli.Ah, OGNI SINGOLA transazione di rete passa attraverso il SO, sennò viene bloccata. E il SO volendo può loggare tutti i dati emessi e ricevuti da un'app.
Quando un'app richiede accesso in scrittura o in lettura, l'installer lo fa presente all'utente.Perchè, non funziona così anche adesso? :confused:In sostanza tra questo e la cartella schermata, è del tutto impossibile smanacciare con le applicazioni, sia per l'utente sia per i malintenzionati; inoltre le applicazioni non sono più in posizione di comando sul sistema operativo: essendo ospiti, devono comportarsi educatamente e chiedere permesso :asd:Bisogna vedere però se tutte questi sistemi di protezione poi non influiscano negativamente sulla facilità d'uso del sistema: se i settaggi o le richieste di conferma sono troppo complesse, l'utente accetterà senza nemmeno guardare (difatti si è visto con Android che neanche dell'utente non ci si può fidare, a meno che non sia un power user che setta tutto a puntino)Sarebbe utilissimo per cose tipo le applicazioni che si aprono all'avvio, che potrebbero essere fatte partire una dopo l'altra sul segnale di "load complete" della precedente, senza intasare il sistema accendendosi tutte assieme (vero windows?).In questo caso avere il "load complete" porterebbe a dei vantaggi.
In effetti, si può lasciare non obbligatorio la scrittura delle gestioni, ma in questo caso, lo scheduler prenderà questi programmi con una priorità inferiore a quelli che la gestiscono (così i programmatori saranno incentivati maggiormente a rispettare le regole).Anche se comprendo che al 99% non arriverai nemmeno vicino a questo tipo di problemi :asd:
Non ho mica detto che servono per il mio os :O (in realtà si :D)Forse prima di pensare al nome non sarebbe meglio pensare alle sue funzionalità o al suo obiettivo, e in base ad essi pensare un nome adeguato?L'idea era di fare un os desktop general-purpose.
@cesare & blackskop
Ok, ma non banalizziamo, questo è un progetto S E R I O ! :asd:
Anche come Grand Central Dispatch? Cmq vedrò quando implementerò lo scheduler.
Yeah proprio tipo quello :read:
Lo scopo è impedire in qualsiasi modo che le app sappiano su quanti cores stanno girando, per permettere al programma di scalare su un numero arbitrario di cores di potenza variabile in futuro.
Mi sembra un buono stack. Cosa intendi dire per "completamente basato sulla scheda video"? Che è studiato per prendere il meglio dalle nuove tecnologie?
Intendo che non usa la CPU per nessun compito visuale, e tutta l'interfaccia alla fine della storia è renderizzata in OpenGL dalla memoria della scheda video.
La CPU ai vari livelli si limita ad assemblare le views e mandare in memoria le risorse necessarie.
E' una buona idea; tuttavia, è un po' utopistica: come puoi fidarti delle applicazioni? Finchè le scrivi te è un conto, ma secondo te un programmatore che vuole far sembrare la sua applicazione velocissima, seriamente chiederebbe il permesso all'OS che *potrebbe* rallentarla (anche se con un motivo valido)?
In secondo luogo, dover gestire tutti questi eventi allungherebbe la scrittura del programma, quindi: o si lascia l'opzione al programmatore se gestire o meno gli eventi, e la maggior parte delle applicazioni non la userà, oppure metterlo d'obbligo facendo quindi allontanare tutti quei programmatori suddetti che non hanno voglia di gestire tutti questi dettagli.
sicuramente allunga i tempi, di sviluppo: sia i tuoi, perchè dovrai validare le chiamate delle app facendole testare ad una persona vera (come fanno Apple , Google e MS) sia perchè va implementato tutto il protocollo che interessa l'applicazione (non tutte sono interessate a tutti gli aspetti del protocollo, anzi).
Di contro hai meno applicazioni, ma di conseguenza anche meno cloni e molta più qualità; vedila così:
quando vai a cercare la qualità vera sui sistemi correnti, devi implementare le stesse chiamate che offrirebbe il tuo SO, ma con hack assortiti.
Questo a scapito della portabilità tra versioni del SO e della stabilità.
Es: in windows migliaia di applicazioni usavano hardcoded path per salvare i propri settings in Documents and Settings, e nel peggiore dei casi in Program Files (che con Vista è diventato read-only), quindi scassandosi col cambio di nomi e privilegi
Nel tuo sistema invece, dotato di questo famoso protocollo, potresti dedicare ad ogni app uno spazio virtuale sul filesystem, dove piazzare salvataggi e impostazioni, che si accede con una propria interfaccia.
Questo andrebbe a scapito di chi fa un txt a tirar via, ma migliorerebbe considerevolmente la vita di chi vuole fare le cose fatte per bene.
(e ti permetterebbe di disinstallare l'applicazione in modo pulito, anche).
Per quanto riguarda applicazioni che _creano_ dei files, boh. Però avendo separato i file di impostazione, possiamo assumere che tutti gli altri siano dati creati per precisa volontà dell'utente, e quindi possono risiedere solamente nella sua cartella (che anche quella è sandboxed).
Così impedisci del tutto alle app di fare cazzate coi files in giro per il sistema, tipo virus che modificano dll, applicazioni che modificano se stesse o altre porcherie assortite.
Quindi indubbiamente ti perdi la fascia di mercato delle applicazioni non interessate alla qualità, e questo io lo vedo come un vantaggio :D
Bisogna vedere però se tutte questi sistemi di protezione poi non influiscano negativamente sulla facilità d'uso del sistema: se i settaggi o le richieste di conferma sono troppo complesse, l'utente accetterà senza nemmeno guardare (difatti si è visto con Android che neanche dell'utente non ci si può fidare, a meno che non sia un power user che setta tutto a puntino)
No le autorizzazioni dovresti tenerle il più possibile tra l'app e il sistema, lo scopo è evitare che l'user debba dare permessi di amministratore o roba del genere...
Perchè, non funziona così anche adesso?
Beh, dato che possono esistere backdoors e quant'altro qualcosa di diverso c'è.
Insomma, il succo è che l'utente, e quindi anche il SO, possono tenere traccia di tutte quante le connessioni attive e ricondurle alla data applicazione.
Una specie di task manager ma con le connessioni, insomma.
Il tutto con DNS di destinazione e traffico in chiaro.
Se ci aggiungi che un'app può accedere solo alle sue impostazioni ed ai dati dell'utente, il sistema è di diverse lunghezze più sicuro di quelli odierni, in quanto una backdoor dovrebbe essere già contenuta nel programma che l'utente scarica (niente trojan), e quel programma viene visionato da te e poi dall'installer (niente virus).
Riassumendo tutti i punti: metti tutto in una sandbox, e poi la sandbox in un'altra sandbox :asd:
grigor91
02-10-2010, 19:44
SolidOS: a rock-solid operating system.
Intendo che non usa la CPU per nessun compito visuale, e tutta l'interfaccia alla fine della storia è renderizzata in OpenGL dalla memoria della scheda video.
La CPU ai vari livelli si limita ad assemblare le views e mandare in memoria le risorse necessarie.Ottimo. Ovviamente ci sarà cmq un fallback sulla cpu se non è disponibile un driver compatibile.
sicuramente allunga i tempi, di sviluppo: sia i tuoi, perchè dovrai validare le chiamate delle app facendole testare ad una persona vera (come fanno Apple , Google e MS) sia perchè va implementato tutto il protocollo che interessa l'applicazione (non tutte sono interessate a tutti gli aspetti del protocollo, anzi).Controllare ogni singola applicazione, no. Ma un repository di applicazioni filtrate e selezionate ci stà tutto.
Nel tuo sistema invece, dotato di questo famoso protocollo, potresti dedicare ad ogni app uno spazio virtuale sul filesystem, dove piazzare salvataggi e impostazioni, che si accede con una propria interfaccia.
Questo andrebbe a scapito di chi fa un txt a tirar via, ma migliorerebbe considerevolmente la vita di chi vuole fare le cose fatte per bene.
(e ti permetterebbe di disinstallare l'applicazione in modo pulito, anche).Si potrebbe semplicemente fare una cartella "dinamica", con una struttura ben definita in cui il programma può salvare e trafficare quello che vuole. In questo modo anche i "txt a tirar via" non avranno vita difficile, e la portabilità di esistenti applicazioni è più semplice (tipicamente i percorsi sono si hard-coded, ma almeno tutti dichiarati tramite #define).
No le autorizzazioni dovresti tenerle il più possibile tra l'app e il sistema, lo scopo è evitare che l'user debba dare permessi di amministratore o roba del genere...
Si, ma quello che intendevo dire è (da quanto avevo capito dal tuo post) che se fai alla Android dove ti chiede "lasci che l'app acceda alla rete?", "lasci che l'app ti cambi lo sfondo?", "lasci che l'app bla bla bla", l'utente spassionato che si trova a leggere finestre simili ad ogni installazione, cliccherà sempre su "Accetto" senza manco leggere i permessi, quindi facendo crollare tutto il nostro sistema di protezione.
Insomma, il succo è che l'utente, e quindi anche il SO, possono tenere traccia di tutte quante le connessioni attive e ricondurle alla data applicazione.
Una specie di task manager ma con le connessioni, insomma.
Il tutto con DNS di destinazione e traffico in chiaro.
Non mi sembra una cosa insormontabile, daltronde le applicazioni si interfacciano con l'os, mica con la scheda di rete. Quello che manca forse è che non c'è un modo comodo per ottenerle queste informazioni.
Riassumendo tutti i punti: metti tutto in una sandbox, e poi la sandbox in un'altra sandbox :asd:
Sappiamo cmq entrambi che non è il maggior numero di sandbox che rende sicuro un sistema ;)
Sappiamo cmq entrambi che non è il maggior numero di sandbox che rende sicuro un sistema ;)
Google la pensa diversamente, e a ruota Apple e MS :D
Chrome non ha mai avuto una falla sfruttabile nella sua storia, IOS non ha nessun virus esistente, e WP7 sandboxa qualsiasi cosa usando come "protocollo" Silverlight+XML...
Altrettanto casualmente il più "accomodante" di tutti, cioè il vecchio windows XP è anche quello più bucato o semplicemente mal utilizzato dagli sviluppatori con cattive abitudini.
Che cosa rende sicuro un sistema, (data l'assenza di bug palesi) se non la limitazione dei privilegi?
cdimauro
03-10-2010, 05:41
Google la pensa diversamente, e a ruota Apple e MS :D
Chrome non ha mai avuto una falla sfruttabile nella sua storia, IOS non ha nessun virus esistente, e WP7 sandboxa qualsiasi cosa usando come "protocollo" Silverlight+XML...
Guarda che iOS è messo molto male. L'ultimo jailbreak sfruttava due falle che consentiva di installarlo semplicemente visitando un sito web (http://www.melablog.it/post/12308/jailbreakmecom-e-la-falla-nel-motore-pdf-di-safari) opportunamente realizzato. E ho detto tutto. :D
Sandbox? What's forfora? :asd:
Altrettanto casualmente il più "accomodante" di tutti, cioè il vecchio windows XP è anche quello più bucato o semplicemente mal utilizzato dagli sviluppatori con cattive abitudini.
Che cosa rende sicuro un sistema, (data l'assenza di bug palesi) se non la limitazione dei privilegi?
Il cervello degli utenti? :asd:
Guarda che iOS è messo molto male. L'ultimo jailbreak sfruttava due falle che consentiva di installarlo semplicemente visitando un sito web (http://www.melablog.it/post/12308/jailbreakmecom-e-la-falla-nel-motore-pdf-di-safari) opportunamente realizzato. E ho detto tutto. :D:
Cesare V_V fai il bravo.
Guarda che iOS è messo molto male. L'ultimo jailbreak sfruttava due falle che consentiva di installarlo semplicemente visitando un sito web (http://www.melablog.it/post/12308/jailbreakmecom-e-la-falla-nel-motore-pdf-di-safari) opportunamente realizzato. E ho detto tutto. :D
Mi mancava proprio :asd:
Ok meglio togliere IOS dalla lista dei sistemi sicuri, facciamo che ho detto solo Chrome :asd:
Google la pensa diversamente, e a ruota Apple e MS :D
Chrome non ha mai avuto una falla sfruttabile nella sua storia, IOS non ha nessun virus esistente, e WP7 sandboxa qualsiasi cosa usando come "protocollo" Silverlight+XML...
Altrettanto casualmente il più "accomodante" di tutti, cioè il vecchio windows XP è anche quello più bucato o semplicemente mal utilizzato dagli sviluppatori con cattive abitudini.
Che cosa rende sicuro un sistema, (data l'assenza di bug palesi) se non la limitazione dei privilegi?
Non sono contrario alle sandbox, era solo per commentare la tua frase: puoi mettere anche un migliaio di sandbox una dentro l'altra, ma se sono programmate da cani sono cmq un pericolo. Quindi "non è il maggior numero di sandbox che rende sicuro un sistema", ma ne basta una molto ben progettata e implementata. ;)
pabloski
03-10-2010, 11:41
Per il modello di sicurezza tiene presente le capabilities. Il vecchio schema basato su utenti e gruppi non mi è mai piaciuto tanto e non ha la granularità necessaria per i complessi sistemi di oggi.
Io elimineri completamente il concetto di filesystem. Non ha senso parlare a degli utonti di file e directory. Oddio i file si, ma le directory, sono roba decisamente vintage.
Ovviamente a livello fisico ci vuole una struttura che organizza i dati e un DB relazionale non è proprio il top come filesystem. Però potresti sfruttare i metadati e un linguaggio d'interrogazione per fare tante belle cosette.
Per come la vedo io ogni file va a far parte di un blocco ( perchè faceva parte dello stesso pacchetto d'installazione, perchè sono file creati dal programma X ). Ogni blocco ha un nome e una versione ( così la finiamo con le millemile dll sparse ovunque senza nè capo nè coda ).
Ad ogni blocco sono associate specifiche capabilities. L'accesso ai file del blocco è legato all'acquisizione delle capabilities necessarie. Può essere gestito dal sistema operativo e/o da un modulo del blocco che si occupa di regolare gli accessi e fornire credenziali d'accesso.
Non sono contrario alle sandbox, era solo per commentare la tua frase: puoi mettere anche un migliaio di sandbox una dentro l'altra, ma se sono programmate da cani sono cmq un pericolo. Quindi "non è il maggior numero di sandbox che rende sicuro un sistema", ma ne basta una molto ben progettata e implementata. ;)
Comunque se non ce la metti, la gente imperversa fin da subito :D
Guarda che iOS è messo molto male. L'ultimo jailbreak sfruttava due falle che consentiva di installarlo semplicemente visitando un sito web (http://www.melablog.it/post/12308/jailbreakmecom-e-la-falla-nel-motore-pdf-di-safari) opportunamente realizzato. E ho detto tutto. :D
Beh dai, via. Messo molto male adesso è esagerato :)
Sì, sono state trovate due falle gravi effettivamente. Ma tieni in considerazione che la possibilità di evadere dalla sandbox è stata data dalla seconda falla (http://www.pcalsicuro.com/main/2010/08/apple-rilascia-ios-4-0-2-e-blocca-jailbreakme/), EoP exploit trovato nel kernel. Se non fosse stato per quello, la prima falla trovata nella gestione dei PDF sarebbe rimasta confinata dalla sandbox.
È un evento "raro" riuscire a trovare una doppia falla che possa contemporaneamente riuscire a farti eseguire del codice da remoto e ottenere i massimi privilegi.
Non dico che sia impossibile, chiaramente (per inciso Windows ha due EoP exploit ancora non fixati, validi dai vecchi Windows XP fino a Windows 7, OS X non se la passa meglio) però da qui a dire che sono messi molto male, il passo è forse più lungo della gamba :)
cdimauro
03-10-2010, 21:15
Non è certo la prima volta che Apple ha gravi problemi di sicurezza.
Poi far girare Safari coi privilegi di root... :stordita:
cdimauro
03-10-2010, 21:31
Per il modello di sicurezza tiene presente le capabilities. Il vecchio schema basato su utenti e gruppi non mi è mai piaciuto tanto e non ha la granularità necessaria per i complessi sistemi di oggi.
Chessò, tipo le ACL di Windows (da NT in poi)? :fagiano:
Io elimineri completamente il concetto di filesystem. Non ha senso parlare a degli utonti di file e directory. Oddio i file si, ma le directory, sono roba decisamente vintage.
Ovviamente a livello fisico ci vuole una struttura che organizza i dati e un DB relazionale non è proprio il top come filesystem. Però potresti sfruttare i metadati e un linguaggio d'interrogazione per fare tante belle cosette.
Chessò, tipo il defunto WinFS? :fagiano:
Per come la vedo io ogni file va a far parte di un blocco ( perchè faceva parte dello stesso pacchetto d'installazione, perchè sono file creati dal programma X ). Ogni blocco ha un nome e una versione ( così la finiamo con le millemile dll sparse ovunque senza nè capo nè coda ).
Beh, esistono anche millemila .so sparse ovunque. :fagiano:
Ad ogni blocco sono associate specifiche capabilities. L'accesso ai file del blocco è legato all'acquisizione delle capabilities necessarie. Può essere gestito dal sistema operativo e/o da un modulo del blocco che si occupa di regolare gli accessi e fornire credenziali d'accesso.
A livello programmatico / applicativo penso sarebbe un casino da gestire.
Immagina di avere un software che deve accedere a una serie di file che gli interessano: deve memorizzare l'id del blocco e/o le capability?
E ogni volta che l'utente deve aprire qualcosa che gli interessa, deve fare una ricerca?
Lo trovo troppo dispersivo.
Catalogare è un'operazione innata nell'uomo, per cui il modello attuale dei filesystem a mio avviso va ancora bene per "dare ordine" agli oggetti.
Gli si dovrebbe affiancare un robusto db relazionale per permettere ANCHE agevoli e semplici ricerche sui metadati. WinFS docet.
pabloski
03-10-2010, 21:56
Chessò, tipo le ACL di Windows (da NT in poi)? :fagiano:
le capabilities sono molto più potenti
Chessò, tipo il defunto WinFS? :fagiano:
winfs è stato un tentativo non riuscito, io pensavo più a qualcosa tipo BeFS
Beh, esistono anche millemila .so sparse ovunque. :fagiano:
boh lo chiamano dll hell anche sui sistemi unix
A livello programmatico / applicativo penso sarebbe un casino da gestire.
sicurezza vs semplicità, non si può avere botte piena e moglie ubriaca
Immagina di avere un software che deve accedere a una serie di file che gli interessano: deve memorizzare l'id del blocco e/o le capability?
in quel caso le capabilities verrebbero rilasciate a runtime e caso per caso.....chi è il master ( il padrone assoluto ) di una risorsa sceglierebbe a chi concederne l'accesso e che tipo di accesso concedere
si integrerebbe perfettamente col discorso fatto da Tommo riguardo l'installazione di nuovi programmi e la relativa procedura di trust
E ogni volta che l'utente deve aprire qualcosa che gli interessa, deve fare una ricerca?
beh pure con le directory alla fin fine fai una ricerca
e poi si creerebbero delle cartelle virtuali ( come fa 7 ) che sono delle live queries
Catalogare è un'operazione innata nell'uomo, per cui il modello attuale dei filesystem a mio avviso va ancora bene per "dare ordine" agli oggetti.
a guardare dal casino che si trova sugli hard disk e quanti file ci si dimentica pure di avere direi che difficilmente l'uomo ha un innato ordine in testa
del resto il tentativo di winfs, la fissazione con l'integrare motore di ricerca nei sistemi operativi ( il search indexer di windows, nepomuk di kde, ecc... ) mostrano che la gestione a file e directory non è più idonea
Gli si dovrebbe affiancare un robusto db relazionale per permettere ANCHE agevoli e semplici ricerche sui metadati. WinFS docet.
beh veramente winfs ha fatto flop, magari BeFS docet :D
Non è certo la prima volta che Apple ha gravi problemi di sicurezza.
Poi far girare Safari coi privilegi di root... :stordita:
Cesare, ma ti pare che facciano girare Safari con i privilegi di root? :D Va bene che alla Apple hanno fatto (e stanno facendo) dei bei arrosti, ma in questo caso hanno evidentemente scritto male gli articoli :)
I privilegi di root sono stati ottenuti grazie ad una falla nel kernel :) Se non c'era quella falla, il codice sarebbe rimasto limitato a Safari, nella sandbox :)
cdimauro
04-10-2010, 07:17
OK, quindi hanno scritto una boiata. Buono a sapersi e grazie per la dritta (così evito di riportare FUD a mia volta :D).
cdimauro
04-10-2010, 07:30
le capabilities sono molto più potenti
Hai qualche link a in proposito?
winfs è stato un tentativo non riuscito, io pensavo più a qualcosa tipo BeFS
Hai ragione: c'è un illustre precedente che avevo dimenticato.
sicurezza vs semplicità, non si può avere botte piena e moglie ubriaca
in quel caso le capabilities verrebbero rilasciate a runtime e caso per caso.....chi è il master ( il padrone assoluto ) di una risorsa sceglierebbe a chi concederne l'accesso e che tipo di accesso concedere
si integrerebbe perfettamente col discorso fatto da Tommo riguardo l'installazione di nuovi programmi e la relativa procedura di trust
Rimane la difficoltà di accesso alla "massa".
Le soluzioni geek-oriented possono complicarsi la vita quanto vogliono (tanto i geek hanno anche tempo in abbondanza da perdere :D), ma la genialità sta nel rendere una tecnologia facilmente fruibile da chiunque.
beh pure con le directory alla fin fine fai una ricerca
e poi si creerebbero delle cartelle virtuali ( come fa 7 ) che sono delle live queries
D'accordo, ma questo perché avere un "namespace" a portata di mano fa sempre comodo. Ecco perché abbiamo le cartelle e una gerarchia.
a guardare dal casino che si trova sugli hard disk e quanti file ci si dimentica pure di avere direi che difficilmente l'uomo ha un innato ordine in testa
del resto il tentativo di winfs, la fissazione con l'integrare motore di ricerca nei sistemi operativi ( il search indexer di windows, nepomuk di kde, ecc... ) mostrano che la gestione a file e directory non è più idonea
Indubbiamente, ed è per questo che serve un'integrazione all'esistente, appunto. Il tutto IMHO, ovviamente.
beh veramente winfs ha fatto flop, magari BeFS docet :D
Non in toto. Buona parte della tecnologia è stata comunque integrata in Vista e successori.
Certo, l'idea di avere WinFS mi allettava molto. E idem per BeFS, col quale ho avuto modo di giocare parecchio ai tempi di BeOS, ma... permaneva la tipica struttura del filesystem. ;)
pabloski
04-10-2010, 12:46
Hai qualche link a in proposito?
secondo me la migliore introduzione è questa http://www.eros-os.org/essays/capintro.html
poi c'è un ottimo articolo degli autori di Eros www.eros-os.org/papers/sosp99-eros-preprint.ps
Rimane la difficoltà di accesso alla "massa".
e infatti per dare accesso alla massa, oggi ci ritroviamo con la testa rotta e i russi alle Bahamas :D
Le soluzioni geek-oriented possono complicarsi la vita quanto vogliono (tanto i geek hanno anche tempo in abbondanza da perdere :D), ma la genialità sta nel rendere una tecnologia facilmente fruibile da chiunque.
vabbè non è detto che l'implementazione sarà difficoltosa....io ho buttato lì l'idea ma si può pure scendere a compromessi e può pure venire fuori qualcuno che tira fuori un'implementazione utilizzabile anche dalle scimmie
alla fin fine si chiede ad un programmatore di definire quali sono le risorse che il programma userà e di creare un modulo che si occupa di assegnare ad altri moduli vari privilegi d'accesso alle sue risorse
poi ovviamente i programmatori che hanno avuto problemi con vista e 7 solo perchè comparivano i file manifest, ovviamente bestemmieranno tutti i santi di fronte ad una cosa del genere
Certo, l'idea di avere WinFS mi allettava molto. E idem per BeFS, col quale ho avuto modo di giocare parecchio ai tempi di BeOS, ma... permaneva la tipica struttura del filesystem. ;)
si, la struttura classica del filesystem può rimanere e non vedo perchè debba entrare in conflitto col resto
però credo all'utente non vada presentata perchè non è più adatta a gestire l'attuale collezione dati dell'utente comune...è un pò la differenza che passa tra sistemi di sicurezza basati su gruppi e utenti, acl e capabilities
OK, quindi hanno scritto una boiata. Buono a sapersi e grazie per la dritta (così evito di riportare FUD a mia volta :D).
Di nulla, capirai :D
Molti siti web hanno scritto erroneamente che Safari gira come privilegi di root, per via di una fonte originale inglese. La fonte non diceva che Safari girava con privilegi di root, ma neanche specificava bene cosa fosse successo esattamente. Mi sembra che più o meno dicesse qualcosa del tipo: "Grazie ad una falla in Safari , l'exploit è riuscito tramite root a....blablabla".
Frase che dice tutto e niente. E, di conseguenza, tutti i siti web non tecnici si sono accodati con la loro libera interpretazione :D
diablo512
04-10-2010, 18:10
ciao
mi iscrivo anche io a sto thread
cmq lo sto provando a compilare...ottengo questo
Done compiling
mcopy -o -i fdd.bin kernel.bin ::kernel.bin
init :: could not read boot sector
Cannot initialize '::'
Bad target ::kernel.bin
make: *** [copyToImage] Errore 1
può essere xche non abbia nessun lettore di floppy nel pc?
come creo un immagine da montare con virtualbox?
cos'è il file fdd.bin?
Discutiamo anche di questo: che funzioni vorreste avere implementate in un OS? Sia da lato "utente" (cioè ad esempio sull'interfaccia), sia dal lato "programmatore" (librerie, utilità di programmazione tipo Visual*)...
Scrivete qualsiasi cosa vi passi in mente, non importa quanto strana o complessa ;)
vorrei TUTTO il codice completamente commentato, ogni cosa, anche banale... sarebbe bellissimo per imparare xD
@pabloski
Grazie per avermi informato sulle cababilities, stò leggendo i link che hai postato, ti dirò cosa ne penso :)
ciao
mi iscrivo anche io a sto thread
cmq lo sto provando a compilare...ottengo questo
Done compiling
mcopy -o -i fdd.bin kernel.bin ::kernel.bin
init :: could not read boot sector
Cannot initialize '::'
Bad target ::kernel.bin
make: *** [copyToImage] Errore 1
può essere xche non abbia nessun lettore di floppy nel pc?
come creo un immagine da montare con virtualbox?
cos'è il file fdd.bin?
Errore mio, dovevo dare maggiori informazioni:
allora, fdd.bin è l'immagine floppy da dare in pasto alla VM, con grub già preimpostato. Se hai scaricato il tar.bz2 da SourceForge, non ha questo file perchè non lo ho incluso per non aumentare la dimensione dell'archivio. Ora lo carico; in caso puoi sempre vedere il primo post del thread e trovi anche l'immagine: mettila nella stessa cartella del Makefile e funzionerà tutto (il make è impostato in modo da compilare e copiare in un colpo solo la nuova immagine aggiornata).
vorrei TUTTO il codice completamente commentato, ogni cosa, anche banale... sarebbe bellissimo per imparare xD
Certamente :D. Sono però combattuto sul tradurlo in Inglese per avere una maggior audience; cosa ne pensate?
diablo512
04-10-2010, 18:45
ho scaricato l'immagine floppy gia compilata..
se dico castronerie fermatemi xD
da quel che so il file immagine è fatto cosi:
bootloader + kernel
sapendo la dimensione del bootloader posso sovrascriverci il nuovo kernel?
per il commento...massì dai lascialo in italiano visto che di documentazione in italiano ce n'è poca.
...se il progetto si dovesse allargare tanto si potrebbe poi sempre tradurre...
EDIT: risolto ho scaricato il tuo nuovo codice da git
Certamente :D. Sono però combattuto sul tradurlo in Inglese per avere una maggior audience; cosa ne pensate?
Io voto per l'inglese, se ti serve una mano, non sono una cima ma posso aiutarti. In tutto, anche in C. (anche se di OS capisco == 0) :D
ho scaricato l'immagine floppy gia compilata..
se dico castronerie fermatemi xD
da quel che so il file immagine è fatto cosi:
bootloader + kernel
sapendo la dimensione del bootloader posso sovrascriverci il nuovo kernel?
per il commento...massì dai lascialo in italiano visto che di documentazione in italiano ce n'è poca.
...se il progetto si dovesse allargare tanto si potrebbe poi sempre tradurre...
No, il file immagine è proprio come un floppy, formattato in FAT, e il kernel è un file all'interno della FAT. Il programma mcopy (che ti stava dando problemi prima proprio perchè non c'era fdd.bin) serve a "manipolare" il file immagine in modo che copi il nuovo kernel sistemando la FAT proprio come se tu aprissi la finestra di un floppy vero e trascinassi il nuovo file del kernel.
Infatti, se ti posizioni nella cartella di fdd.bin e scrivi:
mdir -i fdd.bin
Ti mostrerà i file all'interno dell'immagine, a me appare:
Volume in drive : has no label
Volume Serial Number is 68AC-0E64
Directory for ::/
GRUB <DIR> 2010-05-23 19:50 grub
kernel bin 110436 2010-10-04 19:52 kernel.bin
FILE 3399 2010-01-15 18:43 file
FILE2 521 2010-01-15 19:43 file2
RAMDISK IMG 1048576 2010-04-23 17:34 ramdisk.img
ALTROF~1 TXT 35 2010-04-23 17:32 altro file.txt
6 files 1 162 967 bytes
177 152 bytes free
Abbiamo il nostro kernel.bin, poi abbiamo altri file di prova, e la cartella dove ci sono tutti i file di grub.
Se vuoi puoi anche montare il file come se fosse una unità vera creando una cartella:
mkdir floppyVirtuale
sudo mount -t msdos fdd.bin floppyVirtuale -o loop
ls floppyVirtuale
sudo umount floppyVirtuale
rmdir floppyVirtuale
Ho approfittato della tua domanda per spiegare meglio alcune cosette :D
Io voto per l'inglese, se ti serve una mano, non sono una cima ma posso aiutarti. In tutto, anche in C. (anche se di OS capisco == 0) :D
Molto gentile :)
Puoi provare a dare un'occhiata ai sorgenti e vedere quali file secondo te sono carenti di commenti.
Molto gentile :)
Puoi provare a dare un'occhiata ai sorgenti e vedere quali file secondo te sono carenti di commenti.
Già osservati e ri-osservati.
Nel week prossimo mi metto a guardarli ancora meglio.
Diciamo che più o meno tutti andrebbero riscritti, sia come pulizia del codice sia come commenti; scommetto che sei 'giovane', molto, come esperienza di scrittura codice; conoscenze ne hai una cifra, ti manca un pò di 'ordine' nei sorgenti. (Poi è una questione di gusti, ma nei progetti ci vuole un filo guida preciso).
Se vuoi una mano io te la do volentieri almeno imparo qualcosa sugli OS in maniera applicata (che non è il mio campo). Usi skype/MSN? Se si, scrivimi pure in PM.
Ne parliamo li!
Diciamo che più o meno tutti andrebbero riscritti, sia come pulizia del codice sia come commenti; scommetto che sei 'giovane', molto, come esperienza di scrittura codice; conoscenze ne hai una cifra, ti manca un pò di 'ordine' nei sorgenti. (Poi è una questione di gusti, ma nei progetti ci vuole un filo guida preciso).
La prendo come un'offesa personale! :mad: (;))
Tuttavia anche io penso che alcuni siano un po' antiestetici, ma non tutti dai :D
La prendo come un'offesa personale! :mad: (;))
Tuttavia anche io penso che alcuni siano un po' antiestetici, ma non tutti dai :D
Ma è un'offesa personale, legata al programmatore; che colpe ne ha la tua creatura? :D
Scherzo ovviamente, ci becchiamo su MSN :)
...se il progetto si dovesse allargare tanto si potrebbe poi sempre tradurre...
Commento spot, sto leggendo il thread da qualche giorno giusto per curiosità.
Volevo dire la mia su questa frase: il progetto si potrebbe allargare se si traduce la documentazione in inglese. Purtroppo siamo noi che ci dobbiamo adeguare a questo standard di fatto...
La documentazione aumenta sicuramente l' appeal di un prodotto, in questo caso di un software.
[OT mode ON]
Questa cosa l'ho assimilata oggi stesso leggendo del progetto di creare una sorta di manuale dell' engine gtk Murrine.
[OT mode OFF]
banryu79
05-10-2010, 08:08
Anche io penso che i commenti siano da tradurre in lingua inglese, ciao :)
Commento spot, sto leggendo il thread da qualche giorno giusto per curiosità.
Volevo dire la mia su questa frase: il progetto si potrebbe allargare se si traduce la documentazione in inglese. Purtroppo siamo noi che ci dobbiamo adeguare a questo standard di fatto...
La documentazione aumenta sicuramente l' appeal di un prodotto, in questo caso di un software.
[OT mode ON]
Questa cosa l'ho assimilata oggi stesso leggendo del progetto di creare una sorta di manuale dell' engine gtk Murrine.
[OT mode OFF]
Anche io penso che i commenti siano da tradurre in lingua inglese, ciao :)
Si, è quello che pensavo anche io, solo vuoi mettere un sistema operativo italiano? :D
(Cmq i nomi delle funzioni e delle variabili sono in inglese, sono solo i commenti in italiano)
Si, è quello che pensavo anche io, solo vuoi mettere un sistema operativo italiano? :D
(Cmq i nomi delle funzioni e delle variabili sono in inglese, sono solo i commenti in italiano)
Bugiardo :P
Io ho visto diversi nomi di variabili, strutture e funzioni in italiano V_V.
Bugiardo :P
Io ho visto diversi nomi di variabili, strutture e funzioni in italiano V_V.
Solo nel codice più vecchio :O
Solo nel codice più vecchio :O
V_V vediamo di sistemarle :P
Mi è venuta una piccola idea, i "file dinamici":
sono file che ci sono sul filesystem ma non hanno dati, che quando vengono aperti viene richiamato un programma che genera un output che sarà letto dal primo programma; come una pipe, insomma, solo che il collegamento viene fatto automaticamente quando il primo programma cerca di aprire il file, oppure come i file di /proc, solo che questo può richiamare qualsiasi programma con una command-line + o - complessa.
Un esempio banale ma concreto: un file /time che quando aperto ha come contenuto la data e ora correnti.
Potrebbe essere utile una cosa del genere (ovviamente non per leggere la data! :D)?
Mantis-89
18-10-2010, 19:18
un link? :D
un link? :D
No, è qualcosa di più di un link.
Se fosse un normale link (ad esempio /time che punta all'utility per leggere la data), io quando faccio:
ifstream file("/time", ios::in);
file = fopen("/time");
e poi leggo dal file, otterrei i dati binari dell'eseguibile. Qui io invece intendo questa sequenza di operazioni:
Il programma apre il file ( ifstream file("/time", ios::in); )
Il sistema riceve la richiesta, controlla il file "/time" e vede che è un file dinamico.
Il sistema legge i dati del file dinamico (tra cui c'è indicato la linea di comando da eseguire, e magari con quale interprete, ad esempio: "bash", "/bin/gettime -t")
Il programma produrrà dell'output, che verrà salvato dal sistema in un file temporaneo o in un'area di memoria
Il sistema ritorna all'applicazione un handler di questo nuovo file temporaneo o memoria condivisa.
pabloski
18-10-2010, 20:06
quindi non è nemmeno simile ai device driver unix, perchè in questo caso dietro un file virtual in /dev c'è un processo che è sempre in ascolto
nel tuo caso, invece, il processo viene creato al momento in cui il file viene aperto per la lettura
è una cosa simile al rpc di corba ma fatta con i file
quindi non è nemmeno simile ai device driver unix, perchè in questo caso dietro un file virtual in /dev c'è un processo che è sempre in ascolto
nel tuo caso, invece, il processo viene creato al momento in cui il file viene aperto per la lettura
è una cosa simile al rpc di corba ma fatta con i file
Esatto, proprio così.
Potrebbe essere di utilità in qualche modo?
pabloski
18-10-2010, 20:44
Esatto, proprio così.
Potrebbe essere di utilità in qualche modo?
direi più di qualche modo
parlo di cluster, cloud computing, semplice comunicazione interprocesso, ecc...
quello che tu vuoi fare è creare dei programmi automatizzati che possono essere interrogati da un altro processo.....ovviamente bisogna aumentare la granularità, nel senso che non dev'esserci un file che una volta aperto ti permette di leggere dallo standard output di un altro processo
ci vuole qualcosa che ti permetta di invocare questo o quel metodo di una specifica classe all'interno di un altro processo
a questo punto il sistema bypasserebbe di parecchio la nozione di programma come blocco monolitico
è quello che cercò di fare pure la microsoft con com ma poi non ho capito perchè è diventata una tecnologia marginale
Kralizek
18-10-2010, 23:42
direi più di qualche modo
parlo di cluster, cloud computing, semplice comunicazione interprocesso, ecc...
quello che tu vuoi fare è creare dei programmi automatizzati che possono essere interrogati da un altro processo.....ovviamente bisogna aumentare la granularità, nel senso che non dev'esserci un file che una volta aperto ti permette di leggere dallo standard output di un altro processo
ci vuole qualcosa che ti permetta di invocare questo o quel metodo di una specifica classe all'interno di un altro processo
a questo punto il sistema bypasserebbe di parecchio la nozione di programma come blocco monolitico
è quello che cercò di fare pure la microsoft con com ma poi non ho capito perchè è diventata una tecnologia marginale
beh diciamo che COM si é evoluto in .NET che si é successivamente evoluto in WCF =)
quello che tu vuoi fare è creare dei programmi automatizzati che possono essere interrogati da un altro processo.....ovviamente bisogna aumentare la granularità, nel senso che non dev'esserci un file che una volta aperto ti permette di leggere dallo standard output di un altro processo
ci vuole qualcosa che ti permetta di invocare questo o quel metodo di una specifica classe all'interno di un altro processo
a questo punto il sistema bypasserebbe di parecchio la nozione di programma come blocco monolitico
è quello che cercò di fare pure la microsoft con com ma poi non ho capito perchè è diventata una tecnologia marginale
Forse sei andato più in là: non vengono creati nuovi programmi ad-hoc, può essere qualsiasi linea di comando, o anche uno script in python per esempio.
L'output del programma viene salvato in un buffer, e quando ha terminato, il buffer può essere passato al richiedente. Il "metodo della classe" può essere richiamato solo se il programma stesso prevede degli switch per attivare le apposite funzioni. Praticamente è un po' meno potente di una RPC (che tra l'altro non sarebbe adatta ad essere implementata con i file).
DanieleC88
19-10-2010, 13:53
A questo punto diventa una scorciatoia per una pipe... Non so quanto possa essere utile, al limite accorcia qualche script.
A questo punto diventa una scorciatoia per una pipe... Non so quanto possa essere utile, al limite accorcia qualche script.
Ma, al contrario della pipe, si accede come un file, e potrebbe essere un file richiesto dall'utente, cioè che l'applicazione non si aspetta essere una pipe.
DanieleC88
19-10-2010, 14:07
Continua ad essere una scorciatoia. :D
Continua ad essere una scorciatoia. :D
Ok, allora come puoi fare per inviare dati generati da un programma ad un altro che non legge dallo standard input? Quindi non puoi fare un p1 | p2 ?
In questo caso non si può usare una pipe.
DanieleC88
19-10-2010, 14:19
Li scrivi su un file, e il secondo programma legge dal file.
jappilas
19-10-2010, 16:25
No, è qualcosa di più di un link.
Se fosse un normale link (ad esempio /time che punta all'utility per leggere la data), io quando faccio:
ifstream file("/time", ios::in);
file = fopen("/time");
e poi leggo dal file,<...>e poi cosa fai, parsi il file testuale per ottenere i campi dati? non è molto più semplice ed efficiente invocare una funzione e farti restituire una struttura dati?
Mi è venuta una piccola idea, i "file dinamici":
sono file che ci sono sul filesystem ma non hanno dati, secondo me la prima cosa da fare è chiedersi: se sono file che non hanno dati, ha senso che stiano nel filesystem?
la seconda è lasciare da parte il fatto che ciò avvenga su unix, e ancora più su linux (con il kitchen sink che è appunto, /proc), entrare nell' ottica che se anche linux fa qualcosa in un certo modo, può non essere il modo più corretto ( o elegante, o efficiente) di farla (*) e ragionare liberamente dai requisiti ad una soluzione pulita, su cui eventualmente appoggiare in un secondo tempo un sistema di compatibilità, senza vincolarsi in partenza a paradigmi vecchi
*: per dire, su linux va di moda creare programmi gui come frontend per altri programmi con cui interagiscono facendo scraping dell' output (testuale e formattato) che questi producono (già che non possono sapere se dall' altra parte c'è un altro programma -con cui potrebbero più efficientemente scambiare strutture dati - o un essere umano di fronte a una CLI)
che è un modo al tempo stesso anacronistico, inefficiente e fragile (cambia una virgola non gestita dal parser, la comunicazione si rompe) di fare le cose, frutto di una certa mentalità in cui si partiva dal presupposto che l' utilizzo prevalente del sistema fosse da parte di un sysadmin di fronte a una shell, e il riuso del codice avvenisse non tramite librerie ma processi comunicanti, anche per non avere tempo (o voglia) di stare a modularizzare codice di tool console esistenti
discorso analogo per il trasformare qualunque cosa in file ed esporlo nel FS (con la pollution che ne deriva), fatta per consentire un accesso uniforme alle risorse del sistema da script e tool - quando un protocollo unificato per lo scambio di dati strutturati tra processi, e comandi / tool ad hoc per ogni API di sistema ad hoc (in pratica: spostare l' uniformità a un livello al di sopra del kernel), avrebbe praticamente ottenuto lo stesso risultato senza che quei dati fossero esportati nel FS ( anche se ciò avrebbe richiesto una diversa shell e nuovi script)
il tuo sistema è basato sulla stessa concezione?
ora, in pratica i requisiti sono
a) attivare, a richiesta, un programma associato a una certa funzione, senza saperne il nome (quindi disaccoppiare questo dai programmi richiedenti)
b) invocare delle procedure del programma handler di cui sopra (alla fine i messaggi sarebbero usati per quello) e avere indietro i risultati
per la prima si può benissimo evitare di passare per il file system - basta che il sistema implementi un meccanismo ed esporti una api (di base, 3 funzioni - register/create, open/join, call/send), che poi programmi sia server che client useranno, i primi per dichiararsi come handler per una funzione, i secondi per agganciarvisi e mandare messaggi o invocare i metodi ( a seconda di cosa decidi di fare per il punto b);
per quest' ultimo entra in gioco la IPC locale - ora, però, esistono dei sistemi che vanno oltre il limite dei sistemi di IPC ed RPC data based, anche supportati dalla memoria condivisa (perchè questa elimina la necessità di fare copie in memoria tra un buffer e l' altro, ma non quella di fare marshaling formattando nel messaggio gli argomenti e i risultati della chiamata)
http://en.wikipedia.org/wiki/Doors_(computing)
http://pages.cs.wisc.edu/~sschang/OS-Qual/process/LRPC.htm
http://www.jamesmolloy.co.uk/jimix/index.html
questi, di cui l' ultimo hobbysta (ma di un membro di OSDev.org) usano la memoria condivisa per mappare direttamente gli stack di passaggio, bypassando il marshaling di argomenti E nome/indirizzo del metodo da invocare
inoltre come puoi notare, una costante è l' implementazione mediata dal kernel di un sistema di publish/subscribe che bypassa il file system - e che nel complesso forma un infrastruttura su cui i servizi locali di livello superiore, anche di sistema come networking e file system, sono costruiti - piuttosto che viceversa
e poi cosa fai, parsi il file testuale per ottenere i campi dati? non è molto più semplice ed efficiente invocare una funzione e farti restituire una struttura dati? Non ho detto che deve ritornare un file testuale.
la seconda è lasciare da parte il fatto che ciò avvenga su unix, e ancora più su linux (con il kitchen sink che è appunto, /proc), entrare nell' ottica che se anche linux fa qualcosa in un certo modo, può non essere il modo più corretto ( o elegante, o efficiente) di farla (*) e ragionare liberamente dai requisiti ad una soluzione pulita, su cui eventualmente appoggiare in un secondo tempo un sistema di compatibilità, senza vincolarsi in partenza a paradigmi vecchi
Ma questo non vuol dire mica che non si possano usare entrambi i metodi:
un sistema di RPC e passaggio di messaggi lo implementavo cmq visto che volevo ottenere anche un ambiente basato molto su eventi, piuttosto che cicli di attesa per i dati.
il tuo sistema è basato sulla stessa concezione?
Il mio sistema è pensato per fornire più strumenti possibili per sviluppare al meglio i propri programmi. Io non volevo proporre questi file dinamici come soluzione definitiva, ma solo come qualcosa in più, perchè magari non tutti i programmi vogliono mettersi a implementare funzioni complesse come esportare servizi se fanno solo piccole cose.
Come paradosso, potrebbero essere utili proprio come front-end per fornire i dati leggibili all'utente esperto che sta usando la shell (il file dinamico usa un programma che legge i dati dal sistema RPC e li ritorna sotto forma di file alla shell).
Oltre a essere utili per portare tutti quei programmi che sono stati pensati in ottica di file (non possiamo mica implementare tutto da zero, qualcosina lo riutilizziamo no?)
per la prima si può benissimo evitare di passare per il file system - basta che il sistema implementi un meccanismo ed esporti una api (di base, 3 funzioni - register/create, open/join, call/send), che poi programmi sia server che client useranno, i primi per dichiararsi come handler per una funzione, i secondi per agganciarvisi e mandare messaggi o invocare i metodi ( a seconda di cosa decidi di fare per il punto b);
Questo presuppone che i server siano sempre attivi e in ascolto, o che ci sia un sistema centralizzato dove il sistema possa guardare per avviare un server on-demand. Bisogna trovare una giusto modo per implementarlo, per non limitare troppo la libertà d'azione.
*
Questo.
Chi ha inventato il "everything is a file" avrebbe fatto meglio a fare altro :D
Inoltre dimentichiamo il simpaticissimo problema che per qualsiasi comunicazione/cazzata tiriamo in ballo il filesystem, che per quanto potrebbe non accedere a disco (e ci mancherebbe) è comunque un sistema mastodontico e non adatto all'uso.
Penso che sia semplicemente meglio organizzare tutto col pattern API+libreria dinamica, altro che comunicazione testuale tra processi, ha semplicemente troppi svantaggi per avere un senso. X Server anyone?
PS @Z80Fan: ho già avuto modo di dirlo, ma imo mettere "qualcosa in più" magari incompleto, magari mal studiato, solo per dare l'ennesimo modo di fare la stessa cosa al programmatore seguendo i suoi gusti, è la cosa più controproducente tu possa fare :D
jappilas
21-10-2010, 11:06
Questo.
Chi ha inventato il "everything is a file" avrebbe fatto meglio a fare altro :D:mano:
Inoltre dimentichiamo il simpaticissimo problema che per qualsiasi comunicazione/cazzata tiriamo in ballo il filesystem, che per quanto potrebbe non accedere a disco (e ci mancherebbe) è comunque un sistema mastodontico e non adatto all'uso.in effetti, se già si guarda il contenuto di un inode/vnode, c'è parecchio overhead...
X Server anyone?oppure, mi è venuto in mente adesso, SQL (http://xkcd.com/327/) anyone? :D
PS @Z80Fan: ho già avuto modo di dirlo, ma imo mettere "qualcosa in più" magari incompleto, magari mal studiato, solo per dare l'ennesimo modo di fare la stessa cosa al programmatore seguendo i suoi gusti, è la cosa più controproducente tu possa fare :Dvero :)
vedi dopo...
Non ho detto che deve ritornare un file testuale.ok, ma anche ammesso che sia un file in formato binario, lo dovrai aprire e deserializzare, per ricostruirti i dati strutturati che ti necessitano...
ben che vada le tue strutture dati avranno dimensioni fisse, altrimenti potresti trovarti a dover leggere word a word fino a trovare dei field delimiter che avrai previsto, o a dover prevedere meta dati (da leggere a loro volta, a parte) che descrivano le dimensioni dei singoli field della tua struttura dati
usare de(gl)i (pseudo/) file come meccanismo di interscambio è inefficiente per questo motivo, oltre che per il fatto di richiedere potenzialmente una syscall per ogni operazione read/write - cosa per cui peraltro è inefficiente (rispetto ai meccanismi di RPC locale a cui accennavo prima, certo per il mondo unix è il massimo) la "finta" shared memory POSIX style (finta, perchè a casa mia "memoria condivisa" significa "indirizzo che posso dereferenziare con ptr->data, senza passare per delle system call" - quello che descrive lo standard posix non è altro che un file cachato)
Il mio sistema è pensato per fornire più strumenti possibili per sviluppare al meglio i propri programmi. Io non volevo proporre questi file dinamici come soluzione definitiva, ma solo come qualcosa in piùse dai al programmatore di applicazioni due modi diversi di fare le cose, uno nativo, e uno non nativo e meno efficiente ma retrocompatibile, come minimo l' inerzia tipica del mondo userland e dei programmatori di applicazioni (a maggior ragione applicazioni e programmatori formatisi nella monocultura unix) farà sì che venga usato principalmente quello retrocompatibile, e quello nativo resti sottosfruttato (nonostante tu abbia presumibilmente speso tempo e risorse mentali a implementarlo) - per questo è controproducente ...
e per questo avrei detto che, potendo partire da un foglio bianco, l' approccio più logico e "sano" fosse individuare prima di tutto dei meccanismi e algoritmi più efficienti / eleganti possibile, dopodichè implementarli come primitive al livello più basso (quindi nel kernel o executive del sistema) e preoccuparsi della compatibilità legacy all' ultimo, quando le fondamenta sono già state costruite
ora, per quanto attiene la IPC i colli di bottiglia sono dati da: sincronizzazione (necessaria per dire quando si prevede messaging asincrono e c'è da gestire code di messaggi), copia di dati in memoria, marshaling nelle RPC (che sono la maggior parte dei casi in cui verrà utilizzata la ipc), eventuali overhead protocollari e da context switch
la famiglia L4 elimina la sincronizzazione attraverso una ipc sincrona, elimina le copie attraverso i messaggi in shared memory e i virtual register, riduce le latenze implementando il minimo indispensabile a trovare e switchare sul processo ricevente (handoff scheduling - cosa che per dire non avviene su altri sistemi - nello unix classico, ad esempio, il processo riceve il messaggio quando schedulato nel round robin) ma non elimina il marshaling, ciononostante, come si nota nei benchmark svolti ad esempio in questa tesi (http://www.disy.cse.unsw.edu.au/theses_public/09/mikeh.pdf) ha un' efficienza notevole, di parecchio più elevata di Android che a sua volta ha un' efficienza più elevata di, per dire, DBUS
LRPC eliminava il memory copying e il marshaling ed eseguiva un context switch diretto, però prevedeva costi leggermente superiori per la sincronizzazione, per tenere attivo un numero potenzialmente pari a N, di A stack (coda di stack, invece di coda messaggi) e per la validazione (ad ogni transazione vengono verificati gli argomenti e il procedure descriptor invocato) - quindi aveva comunque margini di miglioramento
con le doors la comunicazione/invocazione è sincrona, avviene tramite shared memory, evita il marshaling, MA ogni door ha un suo vnode - Solaris comunque le affianca a un sistema di IPC data based (che a sua volta segue due path diversi a seconda della dimensione dei messaggi)
qui (http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=D2E77408D9CC824BC87FD56470850BE7?doi=10.1.1.51.7045&rep=rep1&type=pdf) sarebbe poi descritto tra l' altro un sistema in apparenza simile alle doors, che avrebbe tagliato sul costo del context switch tra client e server effettuando uno switch "lightweight" ed eseguendo il server nel contesto del client sempre giocando sulla virtual / shared memory
la perfezione per un sistema di IPC equivale a eliminare contemporaneamente tutti i colli di bottiglia di cui sopra, con il minimo stretto di codice - anche se è parecchio ardua da raggiungere a causa di alcuni come gli overhead di kernel e protocollo, non è impossibile avvicinarvisi con un design curato e possibilmente olistico (a maggior ragione potendo partire da zero) e si possono comunque ottenere ottimi risultati affrontandone alcuni e mitigando gli altri, come appunto negli esempi precedenti
riprendendo il discorso di prima, se tu implementassi a livello kernel un sistema del genere (e solo quello) poi potresti costruire un compatibility layer che vi si appoggi, e ottenere che anche le comunicazioni passanti per esso beneficino dell' efficienza delle primitive - mentre implementando sistemi e path paralleli concentrandoti sulla retrocompatibilità rischi che nessuno sia efficiente come potrebbe essere (altro motivo per cui l' approccio "piede in più staffe" tende ad essere controproducente)
rispetto al file system, c'è poi da considerare l' aspetto intrinseco che il file è un' astrazione - la più minimale possibile, in effetti - ricondurre ad essa oggetti diversi da file veri e propri su disco, implica un costo (in termini di righe di codice, quindi overhead) costo che dovrà essere sostenuto dal kernel per farli apparire come tali alle applicazioni userspace (oltre che per arbitrarlo tra di esse in modo trasparente), e dalle applicazioni (o librerie su cui queste si basano) per adattare la propria logica interna a quella del "file"
ora, questo costo sarà possibilmente minimo, per esempio, per una porta di IO semplice e magari non arbitrata, la cui logica di funzionamento sia già sovrapponibile al modello RWOC, ma difficilmente sarà lo stesso per una periferica più complessa come una moderna GPU...
anche senza scomodare il modo in cui Synthesis (http://valerieaurora.org/synthesis/SynthesisOS/ch4.html) spingeva agli estremi il concetto di OOP allocando codice, oltre che strutture dati, per ogni oggetto presente nel sistema (inclusi i device, quindi il codice di interfacciamento ad hoc per ciascuno) in una configurazione sostanzialmente automodificante - è possibile vedere come, potendo progettare un kernel nuovo e non obbligatoriamente legato ai paradigmi unix e una sola astrazione, ragionare in termini comunque OOP, individuare le caratteristiche richieste a ogni diverso oggetto supportato dal kernel (quindi files, processi -loro gestione- GPU -non necessariamente i comandi di disegno, è sufficiente la gestione dei contesti- device USB, ecc) e quindi esporre per ognuno una API apposita tra il kernel e la userland (o la runtime library) sia una scelta sensibile ...
un eventuale layer di compatibilità poi si potrà occupare dell' adattamento ad uso dei programmi legacy unix, ma intanto hai minimizzato l' overhead per quelli nativi ...
perchè magari non tutti i programmi vogliono mettersi a implementare funzioni complesse come esportare servizi se fanno solo piccole cose.se tu costruisci il tuo sistema su uno specifico meccanismo / algoritmo di IPC la sua applicazione sarà possibilmente pervasiva, tutti i programmi dovranno partecipare a quel meccanismo, non ci piove (anche perchè, per quanto non ci si pensi, il design, la semantica e la API del sistema di ipc nativa inficia, anche radicalmente, il process model (http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html) su cui si baseranno i programmi event driven (http://en.wikipedia.org/wiki/Event_loop) nativi per quel sistema, e il modo di programmarli)
ma al tempo stesso non è detto che i programmi e chi li sviluppa si debbano preoccupare esplicitamente di implementare la ipc, non per sempre almeno ... potresti incapsulare le chiamate ai metodi primitivi di messaging/invocazione nella runtime library (in questo modo per i programmi userspace l' implementazione di una fopen() sarà trasparente) insieme con l' eventuale codice di setup comune (analogamente a quanto avviene per i signal, trasparentemente associati ad uno stesso handler di default)
magari in un primo momento puoi sviluppare i programmi nativi (presumibilmente a cominciare da quelli vitali, tipo la gui) a mano e successivamente isolare e incapsulare nella runtime library il codice di basso livello - ma consiglierei di farlo come prima cosa
in effetti consiglierei quasi di implementare un IDL che vada di pari passo con il sistema di IPC/RPC che progetti, come prima cosa - ma forse è un po' troppo imegnativo...
...
Hai portato delle argomentazioni e degli esempi molto chiari, ti ringrazio :)
Certo, creare un kernel da zero permette di avere la massima flessibilità, ma bisogna anche riuscire a implementare tutte le features :D
Bisognerà fare delle ricerche su quali sistemi siano più efficienti, o con un miglior rapporto semplicità/efficienza, visto l'esiguo numero di sviluppatori disponibili (leggasi: uno :))
Probabilmente lavorerò un po' meno in questo periodo, perchè mi voglio prendere avanti e cominciare a preparare il progetto per la tesina. Cmq devo ancora finire di gestire la memoria, direi che c'è tempo per pensarci :O
cdimauro
22-10-2010, 05:56
Potresti leggerti intanto la tesi di cui ha postato il link jappilas. ;)
Stavo pensando a come implementare la "vera memoria condivisa", ma mi sono imbattuto in un piccolo problema: dove, nello spazio virtuale, la posiziono? Perchè da una parte ci sono codice, dati e heap, il quale cresce verso indirizzi maggiori; dall'altra c'è lo stack che cresce in basso. Sia lo stack che l'heap devono essere delle zone di memoria contigue, quindi, dove posso mettere le pagine condivise senza fare da tappo per l'una o per l'altra struttura? Anche se lo metto a metà della distanza tra le due, non posso sapere quanto cresceranno, e se arriveranno a toccarle. Avete esperienza di altri OS con pagine condivise? In che indirizzi vengono mappate? Hanno bisogno di un heap contiguo o possono lavorare anche con pagine sparse?
cdimauro
28-10-2010, 03:50
Io direi di piazzarle in un segmento della GDT. :fagiano:
Ho finito di lavorare su l'allocatore di memoria: gestisce blocchi di qualsiasi dimensione, unisce automaticamente i blocchi liberi vicini, divide i blocchi se si usa solo una parte dello spazio, e si preoccupa di tornare indirizzi allineati.
Il codice è scaricabile da Git o dalla prima pagina del thread.
Ho fatto diversi esperimenti con il sistema grafico: ho creato un "protocollo" di comunicazione tra il sistema tty e il sistema video, in modo da astrarre su due livelli i due moduli. Ho anche deciso di passare alla versione 0.05. Il codice e l'immagine disco sono scaricabili come sempre dalla pagina di SourceForge (link nel primo post), o tramite Git.
PS: C'è anche una nuova "mascotte" ;)
cdimauro
13-12-2010, 05:13
La mascotte non l'ho vista nel sito (tra l'altro c'è un solo screenshot :P).
Un paio di curiosità: qual è la granularità delle allocazioni? Cosa intendi per sistema grafico e video?
La mascotte non l'ho vista nel sito (tra l'altro c'è un solo screenshot :P).
Non c'è bisogno di tanti screenshot perchè è tutto li quello che si vede :asd:
Cmq la mascotte c'è in quell'immagine, in alto a destra ;)
(Inizialmente era solo un'immagine di prova, ma la lascio lì un po' alla easter-egg)
Un paio di curiosità: qual è la granularità delle allocazioni? Cosa intendi per sistema grafico e video?
La gestione della memoria permette di allocare blocchi di qualsiasi dimensione (memoria permettendo); se però una richiesta è troppo piccola rispetto a un valore minimo impostabile, viene allocato quel valore minimo (che adesso è di 16 byte). Lo stesso sistema si occupa di allineare l'indirizzo di ritorno ad un valore anch'esso specificabile.
Per quanto riguarda il video, facciamo un esempio pratico: quando chiamo kprintf(), la funzione "renderizza" la stringa di formato in un vettore temporaneo, che poi viene passato alla funzione tty_puts(); quest'ultima, carattere per carattere, elabora il carattere se è di controllo, altrimenti chiama (in uno stile un po' da RPC) il driver grafico (vesa.c) passandogli la bitmap del carattere da disegnare, e la posizione a cui stamparlo. Precedentemente, io passavo la stringa da stampare al driver grafico, e lui si occupava di elaborare i caratteri e renderizzarli. Ora ho spostato questa funzionalità in tty.c, e in questo modo posso usare la funzione di scrittura verso il driver (devWrite()) per passargli una struttura che contiene campi che identificano l'operazione da compiere. Allo stato attuale ho implementato una funzione per tracciare una bitmap a 1bpp in formato xbm (che uso per i caratteri), una per disegnare un rettangolo pieno, e una per disegnare un rettangolo con solo il bordo (che vengono usate per disegnare il box giallo nello screenshot del sito).
cdimauro
13-12-2010, 19:54
Richiamare il driver per ogni carattere da stampare mi sembra eccessivo, come pure l'uso di un meccanismo di RPC o simile (X-11 concettualmente e praticamente è da A-BO-LI-RE).
Nel primo caso ti consiglio di specificare nell'interfaccia del driver una funzione per la stampa di una stringa di testo a una precisa coordinata su un canvas (che ha, quindi, un font, un colore di riempimento, un pattern di riempimento, un colore principale, un pattern di disegno, e un'area di clip assegnata).
Sarà poi il driver, se la scheda video supporta qualcosa di simile, a inviarle l'apposito comando, altrimenti a provvedere all'emulazione della funzionalità.
In questo caso la mia idea è che il driver esponga all'esterno un'interfaccia, che di default ha preimpostate tutte le funzioni di default offerte dal s.o. (per intenderci: in modalità framebuffer tutte le API puntano a funzioni standard, quindi eseguono codice generico che emula tutto), e sovrascrive soltanto quelle che è in grado di gestire autonomamente (e velocemente).
E' una sorta di ereditarietà che punta a semplificare la scrittura del driver.
Quanto al modello di invocazione delle API, al bando l'RPC e passiamo a delle chiamate locali. :D
Richiamare il driver per ogni carattere da stampare mi sembra eccessivo, come pure l'uso di un meccanismo di RPC o simile (X-11 concettualmente e praticamente è da A-BO-LI-RE).
Nel primo caso ti consiglio di specificare nell'interfaccia del driver una funzione per la stampa di una stringa di testo a una precisa coordinata su un canvas (che ha, quindi, un font, un colore di riempimento, un pattern di riempimento, un colore principale, un pattern di disegno, e un'area di clip assegnata).
Sarà poi il driver, se la scheda video supporta qualcosa di simile, a inviarle l'apposito comando, altrimenti a provvedere all'emulazione della funzionalità.
In questo caso la mia idea è che il driver esponga all'esterno un'interfaccia, che di default ha preimpostate tutte le funzioni di default offerte dal s.o. (per intenderci: in modalità framebuffer tutte le API puntano a funzioni standard, quindi eseguono codice generico che emula tutto), e sovrascrive soltanto quelle che è in grado di gestire autonomamente (e velocemente).
E' una sorta di ereditarietà che punta a semplificare la scrittura del driver.
Quanto al modello di invocazione delle API, al bando l'RPC e passiamo a delle chiamate locali. :D
E' facile dire "chiamate locali"... ma quando devi chiamare del codice che è in un'altro spazio virtuale, e non sai neanche in che posizione è, è un po' difficile ;)
Vedendo il progetto finito, un tipico percorso dei dati dall'applicazione allo schermo è il seguente:
1- Applicazione chiama libreria con richiesta di disegno (stesso spazio virtuale)
2- Libreria sceglie se bufferizzare la richiesta (in caso non sia bloccante) per migliorare le prestazioni, o inoltrarla subito al server grafico.
3- La richiesta passa attraverso uno o più messaggi a server grafico (diverso spazio virtuale)
4- Il server grafico controlla se l'applicazione ha i permessi e/o è nelle condizioni di poter disegnare (ad es. l'handler specificato è di una finestra in suo possesso).
5- Il server invia uno o più messaggi al driver video
6- Il driver video esegue la o le operazioni, eventualmente richiedendo di condividere dei dati dall'applicazione per poter eseguire correttamente il comando (p.es. stampare una bitmap).
7- Eventualmente il driver (o il server) inviano un evento di conferma al dispatcher in modo che faccia ripartire l'applicazione.
C'è anche la versione semplificata, in cui ogni applicazione disegna in un suo buffer, e poi il driver copia questi buffer nel framebuffer nel vblank; questo è vantaggioso solo se il driver non ha nessuna funzionalità di accelerazione, altrimenti si perde tutto.
Che ci siano le funzioni di fallback in mancanza di un driver accelerato, non c'è dubbio, e il driver stesso può indicare di usarle durante l'inizializzazione; in questo caso, verrà caricata e collegata nello stesso spazio virtuale una libreria che esegue queste funzioni.
Cmq vedo di implementare la scrittura di un'intera stringa, anche a me non piacevano le chiamate multiple...
cdimauro
15-12-2010, 13:26
E' facile dire "chiamate locali"... ma quando devi chiamare del codice che è in un'altro spazio virtuale, e non sai neanche in che posizione è, è un po' difficile ;)
Esistono dei protocolli di LPC anziché RPC. jappilas potrebbe fornire delle informazioni utili, allo scopo.
L'importante è evitare l'RPC, perché di remoto non c'è proprio nulla qui. :p
[...]
Cmq vedo di implementare la scrittura di un'intera stringa, anche a me non piacevano le chiamate multiple...
Bene. :)
innanzitutto ciao a tutti ^^, sono nuovo nel forum
scusate se rispondo ad una discussione vecchia... ma il progetto continua? Oppure è morto? Mi potrei unire allo sviluppo?
innanzitutto ciao a tutti ^^, sono nuovo nel forum
scusate se rispondo ad una discussione vecchia... ma il progetto continua? Oppure è morto? Mi potrei unire allo sviluppo?
Ciao! Benvenuto!
Il progetto non è morto, è solo fermo a causa degli esami imminenti che mi hanno portato via moolto tempo.
Se ti vuoi unire nello sviluppo puoi fare tranquillamente, su Sourceforge puoi scaricare i sorgenti e attraverso git puoi trovare la versione più aggiornata (attento che potrebbe anche non funzionare ;))
Sono contento che qualcuno sia ancora interessato :)
Ciao! Benvenuto!
Il progetto non è morto, è solo fermo a causa degli esami imminenti che mi hanno portato via moolto tempo.
Se ti vuoi unire nello sviluppo puoi fare tranquillamente, su Sourceforge puoi scaricare i sorgenti e attraverso git puoi trovare la versione più aggiornata (attento che potrebbe anche non funzionare ;))
Sono contento che qualcuno sia ancora interessato :)
Cos'è Git?
Non ne ho mai sentito parlare :D a che serve?:confused:
pabloski
30-04-2011, 10:10
Cos'è Git?
Non ne ho mai sentito parlare :D a che serve?:confused:
http://git-scm.com/
ovvero un sistema per la gestione delle versioni del software, delle modifiche apportate, con tanto di report circa le modifiche, ecc...
serve ovviamente quando ci sono n-mila programmatori che lavorano sullo stesso progetto
guarda questo esempio http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
ad esempio vuoi lavorare al kernel linux? allora scarica i sorgenti sul tuo pc tramite git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
vuoi aggiornare la tua copia locale dei sorgenti?
git pull
vuoi annullare le modifiche fatte ai sorgenti in locale?
git checkout -f
http://git-scm.com/
ovvero un sistema per la gestione delle versioni del software, delle modifiche apportate, con tanto di report circa le modifiche, ecc...
serve ovviamente quando ci sono n-mila programmatori che lavorano sullo stesso progetto
guarda questo esempio http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
ad esempio vuoi lavorare al kernel linux? allora scarica i sorgenti sul tuo pc tramite git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
vuoi aggiornare la tua copia locale dei sorgenti?
git pull
vuoi annullare le modifiche fatte ai sorgenti in locale?
git checkout -f
in poche parole come il cvs, giusto?
pabloski
30-04-2011, 10:23
in poche parole come il cvs, giusto?
si, è un cvs ma con alcuni miglioramenti rispetto ai vari cvs tra cui subversion, che lo rendono adatto a gestire grossi progetti distribuiti
si, è un cvs ma con alcuni miglioramenti rispetto ai vari cvs tra cui subversion, che lo rendono adatto a gestire grossi progetti distribuiti
ok ^^
Corso di base per Git:
http://www.eecs.harvard.edu/~cduan/technical/git/
Corso di base per Git:
http://www.eecs.harvard.edu/~cduan/technical/git/
thx ^^
EDIT:
Cavolo, guardando il codice sono rimasto sorpreso, avete creato una superfigata, solo odio lo stile che usate per il codice -.- xD ^^
non mi piace il genere:
while( p < (max_lenght-1) )
{
if(xyz)
{
return true;
}
}
preferisco il genere:
while(p < (max_lenght -1)) {
if(xyz) { return true; }
}
( il codice che ho scritto è senza senso, ma è per dare l'idea xD )
Spero che sia indentato e non come l'hai scritto te :asd:
La prima forma IMHO è la migliore, decisamente più leggibile.
Spero che sia indentato e non come l'hai scritto te :asd:
La prima forma IMHO è la migliore, decisamente più leggibile.
bhe, io l'ho indentato xD, solo che invece di [ code ] ho messo [ quote ] xD
ecco l'ho modificato :P XD
cdimauro
30-04-2011, 19:09
Io preferisco questo:
while (p < max_length - 1)
if (xyz)
return true;
Ma discussioni sullo stile è facile che sfocino in guerre di religione. :stordita:
P.S. Ovviamente si scrive length e non lenght, ma quest'errore è tipico dei programmatori. :p
Beh Python è Python :cool: .
Edit: mi sono reso conto dopo quel codice è validissimo anche in C :D.
Io la penso così:
- la forma
if(bla)
{
per i blocchi che al loro interno contengono molte linee di codice, in modo da evidenziare bene l'inizio;
- la forma
if(bla) {
per i blocchi con poche linee, ma sempre maggiori di una;
- la forma senza parentesi per i blocchi a singola linea.
Poi in giro per il codice ci sono delle variazioni sul tema, tipo i
if(abc) xyz=w;
E' da ricordare inoltre che molto di questo codice è temporaneo o in fase di costruzione, quindi potrebbe non essere ancora ben indentato ;)
DanieleC88
01-05-2011, 12:25
Edit: mi sono reso conto dopo quel codice è validissimo anche in C :D.
Più che altro non è codice Python valido (mancano i due punti).
Io la penso così:
- la forma
if(bla)
{
per i blocchi che al loro interno contengono molte linee di codice, in modo da evidenziare bene l'inizio;
- la forma
if(bla) {
per i blocchi con poche linee, ma sempre maggiori di una;
- la forma senza parentesi per i blocchi a singola linea.
Poi in giro per il codice ci sono delle variazioni sul tema, tipo i
if(abc) xyz=w;
E' da ricordare inoltre che molto di questo codice è temporaneo o in fase di costruzione, quindi potrebbe non essere ancora ben indentato ;)
Bhe, la cosa della linea singola la faccio uguale anche io ^^ ( solo che aggiungo le parentesi ), comunque sono abitudini ^^
Più che altro non è codice Python valido (mancano i due punti).
Ormai vedo Python ovunque, specie se posta Cesare :D.
Ormai vedo Python ovunque, specie se posta Cesare :D.
xD
diablo512
04-05-2011, 06:55
Scusate l'ot
Sapete darmi qualche dritta e qualche link per installare git su un server locale? grazie
Scusate l'ot
Sapete darmi qualche dritta e qualche link per installare git su un server locale? grazie
Cioè vuoi creare un server Git dove diversi client possono accedere, o vuoi configurare un client per lavorare con Git?
Serve anche su che sistema operativo vuoi montarlo.
diablo512
04-05-2011, 18:18
Hai ragionissima scusami,
Ero connesso dal real trono di ceramica col telefono xD
Comunque devo installare un server git su un server di testing (ubuntu) connesso in LAN
Alla quale i vari client si devono collegare per fare i commit
jappilas
04-05-2011, 22:52
E' facile dire "chiamate locali"... ma quando devi chiamare del codice che è in un'altro spazio virtuale, e non sai neanche in che posizione è, è un po' difficile ;)allora, scomponiamo...
c'è il problema 1) di accedere a codice o strutture dati in un altro spazio di indirizzamento;
e c'è il problema 2) di invocare codice in una specifica posizione;
il problema 1) è esattamente il motivo per cui ho più volte suggerito di implementare la memoria condivisa a livello kernel (dal momento che è questo a creare le tabelle di corrispondenza tra pagine fisiche e virtuali per ogni processo - oltre che a poter sapere sempre dove si trovano i segmenti di codice di ciascuno, in memoria fisica)
per quanto riguarda il problema 2) si potrebbe cominciare a chiedersi, su cosa è incentrata una delle funzioni primarie a cui il kernel assolve, ovvero il multitasking? sulla capacità di arrestare un processo in modo trasparente e asincrono, salvarne lo stato e riprenderlo successivamente dal punto (PC) in cui era stato interrotto;
e su cosa si basa su molti sistemi la gestione in userspace di eventi notificati dal kernel? i signal, ovvero un meccanismo a semantica (primitiva) stop-goto, i cui handler alla fine altro non sono che function pointer per procedure senza parametri e con un "nome" standard..
da questo, e considerato che tipicamente si vorrà che le funzioni esportate dai server siano uniche e a scope globale (a differenza dei signal handler, che ogni processo deve implementare nel proprio), è logico pensare di implementare nel kernel (in quanto punto nodale) una lista di coppie <procedure id, process> , e delle sycall con cui
- il processo server da una parte dichiara le funzioni esportate (eventualmente con numero e tipo di parametri)
- il client dall' altra invoca la funzione richiedendola in effetti al kernel (che dal procedure id risalirà al processo che la esporta e all' indirizzo, ed eseguirà un restore del processo server a quel program counter), e salva i parametri sullo stack che il server potrà recuperare tal quale grazie al fatto che il kernel lo avrà rimappato al volo nel suo spazio di indirizzamento)
questa è la struttura e la logica seguita con variazioni ed eventuali complicazioni (ad esempio sui parametri - puoi prevedere solo valori immediati o passare come con door_call() su solaris, una lista di file descriptor -o quel che hai- E un puntatore a un' area -opzionale- di shared memory sia all' andata che al ritorno ... oppure rendere l' esecuzione asincrona e le chiamate non bloccanti - dovrai con ogni probabilità creare un nuovo thread (e un nuovo stack) nello spazio del server, ma la semantica non cambia - oppure voler sottoporre l' utilizzo di procedure, a restrizioni o policy, quindi serviranno dei meccanismi di accesso e tracciatura...) sui principali sistemi ...
poi c'è il caso del sottoprogetto Fusion (http://directfb.org/wiki/index.php/Fusion:About) di DirectFB (sì proprio il sottosistema ui framebuffer based per linux) che a fronte di alcune differenze algoritmiche (per dire, calling fusion_enter() creates a fusion messaging thread quindi in pratica si ha una message pump attiva invece che "passiva") e terminologiche ricicla in pratica gli stessi concetti...
il problema 1) è esattamente il motivo per cui ho più volte suggerito di implementare la memoria condivisa a livello kernel (dal momento che è questo a creare le tabelle di corrispondenza tra pagine fisiche e virtuali per ogni processo - oltre che a poter sapere sempre dove si trovano i segmenti di codice di ciascuno, in memoria fisica)
E fin qui non ci piove (anche perchè non saprei come implementare le pagine condivise al di fuori del kernel ;))
da questo, e considerato che tipicamente si vorrà che le funzioni esportate dai server siano uniche e a scope globale (a differenza dei signal handler, che ogni processo deve implementare nel proprio), è logico pensare di implementare nel kernel (in quanto punto nodale) una lista di coppie <procedure id, process> , e delle sycall con cui
- il processo server da una parte dichiara le funzioni esportate (eventualmente con numero e tipo di parametri)
- il client dall' altra invoca la funzione richiedendola in effetti al kernel (che dal procedure id risalirà al processo che la esporta e all' indirizzo, ed eseguirà un restore del processo server a quel program counter), e salva i parametri sullo stack che il server potrà recuperare tal quale grazie al fatto che il kernel lo avrà rimappato al volo nel suo spazio di indirizzamento)
Si, l'idea che avevo è proprio quella, solo che, invece di funzioni senza parametri, faccio passare una struttura messaggio contenente i dati appropriati per richiamare quella funzione:
int mainServer() {
handler_id id;
id = addRemoteHandler("sum2Function", serverFunctionHandler);
printf("Id funzione: %d\n", id);
Sleep();
}
void serverFunctionHandler( struct message *msg ) {
msg->ret = msg->par1 + msg->par2;
}
-----
handler_id remoteF;
int mainClient() {
remoteF = findRemoteHandler("sum2Function");
printf("Sum: %d\n", sumInts(4,5) );
return 0;
}
int sumInts(int a, int b) {
struct message *msg = allocNewMessage();
int ret;
msg->par1 = a;
msg->par2 = b;
callRemote(remoteF, msg);
ret = msg->ret;
deleteMessage(msg);
return ret;
}
Molta della "complessità" nel richiamare il server la nascondo nelle varie librerie.
allocNewMessage() automaticamente lavora in un'area di memoria condivisa dedicata (nel senso che viene usata solo dal sistema IPC, per il gestore della memoria è come tutte le altre pagine).
Riguardo a permettere ad ogni funzione di avere una lista di parametri differente, ci devo pensare un po', perchè:
- callRemote dovrebbe avere una lista di parametri variabile, nulla di male ma in questo modo il compilatore non può fare un controllo sui tipi di dato;
- il kernel non sa nulla, copia solo i dati che trova nello stack del client su quello del server, in base a come il server ha indicato;
- il server non può sapere se i dati passati sono corretti, o se sono solo dei byte sparsi dati da tipi di dato non corretti o disordinati.
Certo, in questo modo si semplificherebbe molto la chiamata, non avendo bisogno della struttura messaggio.
Pensavo anche che la funzione potesse restituire un valore direttamente, invece che riempire un campo del messaggio; bisognerebbe definire un tipo di dato capace di contenere il più grande possibile ritornabile (di quelli standard, ovviamente), tipo un long double o cose del genere.
Più o meno questa è la mia idea di RPC (mi basavo sulla definizione data da Wikipedia, dove RPC significava una chiamata fuori dallo spazio di indirizzamento della funzione, non necessariamente fuori dal computer, anche se con questo metodo può essere fatto); poi ovviamente le mie conoscenze sull'argomento sono quelle di quarta superiore, potrebbero esserci problemi che non ho notato ;).
x diablo512:
Potresti provare a guardare qui:
http://www.eecs.harvard.edu/~cduan/technical/git/git-4.shtml
La cosa interessante di Git è che non hai bisogno di un server centrale, quindi potresti semplicemente creare il repository sul server come faresti localmente, ma su una cartella condivisa, e poi far lavorare tutti i client su quella cartella condivisa.
Oppure, potresti provare Gitolite (https://github.com/sitaramc/gitolite#start); io non lo ho provato, ma sembra interessante per il tuo problema.
jappilas
06-05-2011, 16:11
Si, l'idea che avevo è proprio quella, solo che, invece di funzioni senza parametri, faccio passare una struttura messaggio contenente i dati appropriati per richiamare quella funzione:
<snip>
allocNewMessage() automaticamente lavora in un'area di memoria condivisa dedicata (nel senso che viene usata solo dal sistema IPC, per il gestore della memoria è come tutte le altre pagine).ottimo primo passo :)
in questo modo però esegui un' allocazione ad ogni chiamata di procedura, quando probabilmente quell' area di memoria può essere riutilizzata - se non altro perchè uno stesso processo non può stare invocando più procedure remote come non può invocare più syscall, contemporaneamente, a meno che non sia multithread
ma allora forse è meglio prevedere un' area di scambio, condivisa di default, e sicuramente presente, per ogni thread attivo nel sistema, e delle macro per manipolare lo stack in maniera trasparente...
Certo, in questo modo si semplificherebbe molto la chiamata, non avendo bisogno della struttura messaggio.pensa anche questo, il kernel deve fornire un meccanismo di base il più possibile affidabile e sicuro, ma immischiarsi il meno possibile ;)
se nonostante ciò i dati non sono corretti od ordinati si interviene a livello superiore
Pensavo anche che la funzione potesse restituire un valore direttamente, invece che riempire un campo del messaggio; bisognerebbe definire un tipo di dato capace di contenere il più grande possibile ritornabile (di quelli standard, ovviamente), tipo un long double o cose del genere.secondo me ti conviene ragionare in modo simmetrico, uscire dal solito schema "client - server" e vedere la cosa più come processi paritetici che si invocano a vicenda ;)
poi ovviamente le mie conoscenze sull'argomento sono quelle di quarta superiore, eh beh complimenti, sai molto più di quanto non sapessi io in quarta superiore :D
potrebbero esserci problemi che non ho notato ;).il passo successivo, ed è in effetti uno dei problemi successivi più sostanziali, è quello di vedere come fare per passare quantità maggiori di dati - ad esempio dei "chunk" audio (segmenti contenenti un tot di campioni) da miscelare nel server sonoro, oppure delle pixmap da rielaborare per il compositing... - nonchè, strutture dati iterative ;)
in quei casi sarebbe sufficiente passare un puntatore (quindi un singolo intero al più a 64 bit) e lo puoi fare sullo stack, a patto che l(e) area/e di memoria a cui è riferito (comprese quelle contenenti i dati degli elementi successivi nel caso di una lista) sia(no) condivisa/e a loro volta - ma per fare questo il programma client (ma vale lo stesso principio per il ritorno del o dei risultati dal server) avrà con molta probabilità già svolto la propria parte di elaborazione su aree di memoria allocate come condivise, ma allora sarà già necessariamente implementata una syscall ad hoc o un' opzione di una syscall generica (malloc, mmap)
l' alternativa è una syscall che metta in condivisione aree di memoria già allocate, ma implica la necessità per il client di iterare prima di invocare il server e cedere il controllo a questo, di condividere con un' operazione in più ogni oggetto elaborato (nel caso di una lista, iterandola) cosa che mi sembra assai poco pratica ..
Più o meno questa è la mia idea di RPC (mi basavo sulla definizione data da Wikipedia, dove RPC significava una chiamata fuori dallo spazio di indirizzamento della funzione, non necessariamente fuori dal computer, anche se con questo metodo può essere fatto); è che l' ultima volta che l' ho vista la definizione su wikipedia era focalizzata sul concetto di procedure call indifferentemente locale o remota ma prevalentemente tra agenti distanti fisicamente impegnati a scambiarsi messaggi anche di grandi dimensioni ( vengono in mente query su database o messaging su middleware come corba o amqp) più che all' interazione tra un' applicazione e , per dire, un window manager...
ottimo primo passo :)
in questo modo però esegui un' allocazione ad ogni chiamata di procedura, quando probabilmente quell' area di memoria può essere riutilizzata - se non altro perchè uno stesso processo non può stare invocando più procedure remote come non può invocare più syscall, contemporaneamente, a meno che non sia multithread
ma allora forse è meglio prevedere un' area di scambio, condivisa di default, e sicuramente presente, per ogni thread attivo nel sistema, e delle macro per manipolare lo stack in maniera trasparente...
No, la zona di memoria funziona un po' come l'heap del programma, quindi viene allocata la memoria alla prima chiamata, e viene rilasciata dopo un po' di tempo (o quando è necessaria).
Poi, secondo le mie idee, un processo potrebbe effettivamente star facendo più chiamate allo stesso server, mi spiego: il programma si interfaccia solo con le librerie di sistema, effettivamente non è lui che richiama il kernel. La libreria può decidere di bufferizzare le richieste, se queste ultime non sono bloccanti o non richiedono risposta, in modo da migliorare le prestazioni (meno context-switch). Si può essere sicuri della loro effettiva esecuzione chiamando una funzione flush(). Quindi ci potrebbero essere più di una chiamata contemporaneamente (come hai detto te anche in caso di multithreading). Cmq la zona di cui parlavo conteneva solo i messaggi, altre aree condivise sono separate.
pensa anche questo, il kernel deve fornire un meccanismo di base il più possibile affidabile e sicuro, ma immischiarsi il meno possibile ;)
se nonostante ciò i dati non sono corretti od ordinati si interviene a livello superiore
Penso che andrò secondo l'idea della struttura, che almeno può venir controllata dal compilatore, togliendo un po' di problemi di mezzo.
secondo me ti conviene ragionare in modo simmetrico, uscire dal solito schema "client - server" e vedere la cosa più come processi paritetici che si invocano a vicenda ;)
Uhm interessante, ci rifletterò su!
il passo successivo, ed è in effetti uno dei problemi successivi più sostanziali, è quello di vedere come fare per passare quantità maggiori di dati - ad esempio dei "chunk" audio (segmenti contenenti un tot di campioni) da miscelare nel server sonoro, oppure delle pixmap da rielaborare per il compositing... - nonchè, strutture dati iterative ;)
Il client può allocare zone di memoria condivisa, con una funzione simile alla malloc, con l'unica particolarità che l'allocazione avviene su un heap separato, in modo da diminuire la possibilità di accesso degli altri programmi ai dati privati dell'applicazione (dato che vengono condivise intere pagine).
Il problema è come far in modo che la memoria venga fatta condividere solo al processo server a cui è destinata; a questo punto pensavo:
1- Il client specifica il pid del processo con cui condividere la memoria; la comunicazione così avviene solo tra due processi e la destinazione viene specificata durante l'allocazione
2- Il client riceve dal kernel un id che identifica l'area messa in condivisione; quando vuole condividere la memoria, il client invia nel messaggio anche l'id della zona da condividere e il server chiede al kernel di essere messo in condivisione. In questo modo si potrebbero avere aree condivise da più processi, e la condivisione avviene dopo l'allocazione.
Un dettaglio importante è anche quando si condividono strutture dati che fanno uso di puntatori (una lista, appunto); i puntatori della struttura sono riferiti allo spazio di indirizzamento del client, non necessariamente uguale a quello del server, quindi quest'ultimo dovrà tener conto dell'offset positivo o negativo da applicare ad ogni puntatore, sia prima di leggerlo che prima di scriverlo.
l' alternativa è una syscall che metta in condivisione aree di memoria già allocate, ma implica la necessità per il client di iterare prima di invocare il server e cedere il controllo a questo, di condividere con un' operazione in più ogni oggetto elaborato (nel caso di una lista, iterandola) cosa che mi sembra assai poco pratica ..
Si può sempre avere anche questa possibilità, se l'app deve condividere un piccolo blocco di dati, anche se, se un'applicazione sa già che dovrà condividerlo, lo allocherà già in area condivisibile...
Non era meglio evitare di implementare nuovamente il driver del floppy e delle altre periferiche di base, prendendo spunto da quello di Minix (eventualmente ottimizzandolo, aggiungendo soltanto delle porzioni nuove di codice per la lettura di formati non standard, se non sono già implementati), per concentrarsi sul resto (memory management, etc)?
Quali requisiti ha questo Sistema Operativo? E' stato implementato per girare anche su CPU precedenti al 386?
Non era meglio evitare di implementare nuovamente il driver del floppy e delle altre periferiche di base, prendendo spunto da quello di Minix (eventualmente ottimizzandolo, aggiungendo soltanto delle porzioni nuove di codice per la lettura di formati non standard, se non sono già implementati), per concentrarsi sul resto (memory management, etc)?
Prendendo il caso particolare del lettore floppy, avrò provato a usare 10 implementazioni diverse (tra cui quella di Minix e di Linux), e tutte sistematicamente non funzionavano. Per questo ho lasciato perdere questa periferica. Gli altri dispositivi son stati abbastanza facili da implementare (il sistema VESA, quello che ha dato più problemi, era causato da una piccola distrazione da parte mia nel parsing della tabella Multiboot di Grub).
Quali requisiti ha questo Sistema Operativo? E' stato implementato per girare anche su CPU precedenti al 386?
Allo stato attuale (cioè lontano dall'essere utile) ovviamente non ha molti requisiti. L'idea è quella di portarlo ad una architettura a 64 bit, e lasciare completamente i 32 bit; adesso però lavora ancora a 32 bit, e poichè usa paginazione e modalità protetta, è necessario almeno un 386 per farlo girare (e con modalità protetta non mi riferisco a quell'orrore del 286).
Attualmente il file ELF binario è intorno ai 50 KiB, caricato sarà un po' meno, metti qualche K per tabelle varie in RAM, e vedi che come requisiti ha veramente poco :D
Prendendo il caso particolare del lettore floppy, avrò provato a usare 10 implementazioni diverse (tra cui quella di Minix e di Linux), e tutte sistematicamente non funzionavano. Per questo ho lasciato perdere questa periferica.
[...]
Allo stato attuale (cioè lontano dall'essere utile) ovviamente non ha molti requisiti. L'idea è quella di portarlo ad una architettura a 64 bit, e lasciare completamente i 32 bit; adesso però lavora ancora a 32 bit, e poichè usa paginazione e modalità protetta, è necessario almeno un 386 per farlo girare (e con modalità protetta non mi riferisco a quell'orrore del 286).
[...]
I lettori floppy non sono stati completamente abbandonati, se non mi sbaglio quest'anno è stato l'ultimo anno di produzione dei floppy disk, quindi penso che almeno fino al 2020 non si estingueranno completamente, anche perché molti PC dei paesi poveri li usano ancora, e sarebbe brutto non considerarli; allo stesso modo hanno CPU a 32 bit, quindi sconsiglio di abbandonarli (anche il mio Pentium 4 Northwood 2.4 Ghz è a 32 bit, così come alcuni modelli di Atom ancora in commercio).
I lettori floppy non sono stati completamente abbandonati
Si certo, addirittura ne ho installato uno sul mio nuovo computer! :D
Non è che lo abbia abbandonato del tutto, lo ho solo lasciato perdere, perchè non riuscivo a farlo funzionare, e non volevo perderci troppo tempo ignorando le altre componenti più importanti del kernel. Non è detto che, in futuro, ci possa dare un'altra occhiata, perchè tanto basta solo scrivere il driver apposito, non c'è nulla che impedisce di usarlo.
allo stesso modo hanno CPU a 32 bit, quindi sconsiglio di abbandonarli (anche il mio Pentium 4 Northwood 2.4 Ghz è a 32 bit, così come alcuni modelli di Atom ancora in commercio).
Tecnicamente parlando non ci sarebbe nulla di complicato a far girare il kernel a 32 bit, perchè il kernel è pensato per essere modulare in quasi tutto, sopratutto la cpu. Quindi posso sempre tenere un "driver" per i sistemi a 32 bit, che poi può essere selezionato durante il build.
Principalmente quello che volevo dire era che lo sviluppo lo farò principalmente in modalità a 64 bit; però se c'è richiesta, posso anche perfezionare i 32 bit.
Aggiornamenti:
Ora il sistema del caricamento moduli è quasi completamente funzionante, c'è solo bisogno di mappare in memoria virtuale il blocco di memoria fisica per poter accedere ai dati. Per far questo ho inserito un blocco chiamato "virtual memory manager", che servirà anche per gestire i diversi spazi virtuali dei processi.
Dato che si prestava benissimo a un'interpretazione a oggetti, dopo un paio di ragionamenti mi son messo a fare delle modifiche e ora il kernel compila in C++ ! :D
Ho già sistemato dei punti dove posso sfruttare bene le funzioni del C++, ad esempio dividere i blocchi in namespace diversi, o il passaggio dei valori tramite riferimento.
Ho pure scritto una classe per fare lo stream di output, così posso fare l'output tramite "kout" :D.
Avviserò quando faccio il prossimo commit, sarà uno bello grosso!
Pian pianino si va avanti. :)
Prima di continuare con qualsiasi cosa ho voluto rendere più "orientato agli oggetti" il kernel: fino a adesso ho passato tutti i file del kernel per renderli sia più ordinati, sia per sistemare i vari warning che il compilatore c++ dava. Ho pure sistemato i vari "moduli" definendo dei namespace appositi.
Ora sto convertendo la gestione dei dispositivi, ogni driver sarà una classe derivata da "Device", e similmente gli interrupt verranno gestiti con un sistema a oggetti.
Sistemata questa ultima parte eseguirò il caricamento della versione 0.05a; non porterà nessuna nuova funzione, solo dei cambiamenti al codice e alla struttura, che secondo me è meglio progettare bene subito, visto che sarà le fondamenta di tutto il resto.
cdimauro
13-11-2011, 18:08
A Torvalds staranno fischiando fastidiosamente le orecchie. :asd:
Pian pianino si va avanti. :)
Prima di continuare con qualsiasi cosa ho voluto rendere più "orientato agli oggetti" il kernel: fino a adesso ho passato tutti i file del kernel per renderli sia più ordinati, sia per sistemare i vari warning che il compilatore c++ dava. Ho pure sistemato i vari "moduli" definendo dei namespace appositi.
Ora sto convertendo la gestione dei dispositivi, ogni driver sarà una classe derivata da "Device", e similmente gli interrupt verranno gestiti con un sistema a oggetti.
Sistemata questa ultima parte eseguirò il caricamento della versione 0.05a; non porterà nessuna nuova funzione, solo dei cambiamenti al codice e alla struttura, che secondo me è meglio progettare bene subito, visto che sarà le fondamenta di tutto il resto.
Penso che sia una buona idea aggiustare la struttura del codice già adesso.
Kralizek
14-11-2011, 09:05
A Torvalds staranno fischiando fastidiosamente le orecchie. :asd:
perché?
perché?
Ha avuto qualche sparata su C++ e OO in passato... tipo:
http://harmful.cat-v.org/software/c++/linus
Kralizek
14-11-2011, 10:18
dopo tre anni in svezia non posso che avere una stima bassissima dei finlandesi...
al contrario, le finlandesi... :eek:
Su C++ sono d'accordo al 100% con lui... un linguaggio orribile e indecente.
Ma perché non prendono come riferimento Java, ci aggiungono classi per gestire la memoria e ci fanno un bel compilatore?
Bastava poco per rendere C ad oggetti e migliorarlo, invece hanno inserito un sacco di bloat sintattico.
PS: l'orientamento ad oggetti lo puoi fare anche in C ;).
cdimauro
14-11-2011, 19:58
Che il C++ sia un linguaggio orribile lo ripeto ormai da anni, ma non per le motivazioni che adduce Torvalds.
Infatti: A response to Linus Torvalds on C++ (http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html). :fagiano:
dopo tre anni in svezia non posso che avere una stima bassissima dei finlandesi...
al contrario, le finlandesi... :eek:
Foto! :D
Kralizek
14-11-2011, 23:56
Che il C++ sia un linguaggio orribile lo ripeto ormai da anni, ma non per le motivazioni che adduce Torvalds.
Infatti: A response to Linus Torvalds on C++ (http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html). :fagiano:
Foto! :D
scusa siamo amici su facebook... fatti un giro tra i miei album :P
cdimauro
15-11-2011, 06:11
Obbedisco! (cit.) :D
EDIT: 1065 foto. Micidiale. Non ho trovato particolari riferimenti alle finlandesi, ma in compenso ho capito perché non potrei vivere da quelle parti. Primo, le donne. :D Secondo, la birra: da astemio morirei già solo a guardare quei boccali di birra onnipresenti.
Kralizek
16-11-2011, 23:43
Obbedisco! (cit.) :D
EDIT: 1065 foto. Micidiale. Non ho trovato particolari riferimenti alle finlandesi, ma in compenso ho capito perché non potrei vivere da quelle parti. Primo, le donne. :D Secondo, la birra: da astemio morirei già solo a guardare quei boccali di birra onnipresenti.
messa così mi fai sembrare un alcolizzato :(
cdimauro
17-11-2011, 06:36
Oops. Non era quello che volevo dire.
E' che, da astemio, mi fa un po' impressione. Andrei KO alla prima uscita. :stordita:
banryu79
17-11-2011, 08:08
Tanto lo sapevamo che Kralizek è un ubriacone! :read: :asd:
Basta leggere i suoi post! (a parte quelli in cui parla di ragazze sdevesi) :Prrr:
Kralizek
17-11-2011, 08:16
Tanto lo sapevamo che Kralizek è un ubriacone! :read: :asd:
Basta leggere i suoi post! (a parte quelli in cui parla di ragazze sdevesi) :Prrr:
cicchetto di prima mattina? ;)
e cmq, da warcraft III: "I can't shoot straight unless I've had a pint!"
dio se abbiamo mandato in vacca il topic...
Come sapete sto portando il kernel in C++. Di recente ho sistemato le ultime cose che impedivano di compilarlo (alla fine erano meno di quanto pensassi), quindi ora è nuovamente eseguibile.
La conversione in C++ non è ancora completa, devo controllare ancora diversi file, aggiungere i namespace, sistemare i commenti etc...
Questa versione 0.06 (i link alla pagina di Sourceforge come sempre sono sul primo post) contiene il codice che sul server git corrisponde al branch "cpp_conv"; quando vedrò che il codice è pronto, lo sposterò sul branch principale.
Una modifica secondo me importante che ho inserito è l'uso dell'OOP nella gestione delle periferiche (classe Device) e nella gestione degli interrupt (classe GenericISR).
Come sapete sto portando il kernel in C++. Di recente ho sistemato le ultime cose che impedivano di compilarlo (alla fine erano meno di quanto pensassi), quindi ora è nuovamente eseguibile.
[...]
Vorresti per davvero arrivare a fare un Sistema Operativo completo con interfaccia grafica?
Vorresti per davvero arrivare a fare un Sistema Operativo completo con interfaccia grafica?
Boh, perchè no? Alla fine per ottenere qualcosa di semplice non serve molto lavoro...
Se non fossi così pigro avrei fatto certamente di più! :D
tecno789
23-01-2012, 12:20
Boh, perchè no? Alla fine per ottenere qualcosa di semplice non serve molto lavoro...
Se non fossi così pigro avrei fatto certamente di più! :D
che bello complimenti, mi iscrivo volentieri alla discussione....
sarei curioso di vedere com'è il sorgente del s.o in C puro...:)
Kralizek
23-01-2012, 12:50
che bello complimenti, mi iscrivo volentieri alla discussione....
sarei curioso di vedere com'è il sorgente del s.o in C puro...:)
allora sbrigati a prendere un dump del source code prima che Z80Fan faccia il merge del branch cpp :)
tecno789
23-01-2012, 12:59
allora sbrigati a prendere un dump del source code prima che Z80Fan faccia il merge del branch cpp :)
se riesco a trovarlo.... ma come mai sta convertendo tutto il codice in C++, diventa più efficiente??
allora sbrigati a prendere un dump del source code prima che Z80Fan faccia il merge del branch cpp :)
Non basta prendere la versione precedente del codice?
tecno789
23-01-2012, 13:03
Non basta prendere la versione precedente del codice?
da quello che ho potuto notare. la versione più recente è stata fatta in C++, mentre la versione 0.05 è ancora in C...
ma come mai sta convertendo tutto il codice in C++, diventa più efficiente??
La velocità di esecuzione non cambia, ma diventa molto più semplice da programmare, perchè abbiamo a disposizione tutte quelle cose (orientamento agli oggetti, template etc) che aiutano molto lo sviluppo.
Certe cose ad esempio vengono naturali facendole attraverso degli oggetti, come la gestione delle periferiche; non che non si possa fare in C liscio, ma ti tocca fare a mano tutto ciò che in C++ viene fatto implicitamente dal compilatore. Ed è meglio farglielo fare a lui che lo sa fare bene. ;)
Certe cose ad esempio vengono naturali facendole attraverso degli oggetti, come la gestione delle periferiche; non che non si possa fare in C liscio, ma ti tocca fare a mano tutto ciò che in C++ viene fatto implicitamente dal compilatore. Ed è meglio farglielo fare a lui che lo sa fare bene. ;)
Comunque è una filosofia inaspettata da parte di uno che sta facendo un sistema operativo da 0 :D
Kralizek
24-01-2012, 13:35
Comunque è una filosofia inaspettata da parte di uno che sta facendo un sistema operativo da 0 :D
vbbé mica se lo sta scrivendo in binario :sofico:
vbbé mica se lo sta scrivendo in binario :sofico:
E' che di solito è una gara contro se stessi per vedere quanta ruota si riesce a reinventare :sofico:
@Z80Fan: a parte gli scherzi, C++ nella pratica non è usato per gli OS perchè ha una ABI spaventosa e rende un incubo creare wrapper per diversi linguaggi, che spesso hanno runtime scritto in C e non possono essere ricompilati in C++.
Tant'è che Windows è scritto in C++ e poi è esposto in C (e wrappato a sua volta in .NET o WinRT che dir si voglia).
Richiederai a tutti i programmi di essere compilati in C++ oppure creerai coraggiosamente il tuo Win32?
cdimauro
24-01-2012, 16:43
Con Z80Fan ne abbiamo già parlato nel forum NonSoloAmiga: il mondo non è C++ centrico.
Per cui un'ABI "universale" che si rispetti deve cercare di dare spazio alla maggioranza dei linguaggi. ;)
Per il resto il C++ per sviluppare un s.o. va benissimo. Almeno lui l'ha capito in poco tempo.
Gente molto più stagionata e famosa dopo anni continua a ripetere "C++ sucks"... :rolleyes:
Kralizek
24-01-2012, 17:11
cos'é un ABI? :help:
banryu79
24-01-2012, 17:27
cos'é un ABI? :help:
Acquired Brain Injury :asd:
Kralizek
24-01-2012, 17:42
Acquired Brain Injury :asd:
ce l'ho doppione! :)
@Z80Fan: a parte gli scherzi, C++ nella pratica non è usato per gli OS perchè ha una ABI spaventosa e rende un incubo creare wrapper per diversi linguaggi, che spesso hanno runtime scritto in C e non possono essere ricompilati in C++.
Tant'è che Windows è scritto in C++ e poi è esposto in C (e wrappato a sua volta in .NET o WinRT che dir si voglia).
Richiederai a tutti i programmi di essere compilati in C++ oppure creerai coraggiosamente il tuo Win32?
Non vedo come la scelta del linguaggio del kernel possa condizionare le applicazioni che ci girano sopra. Le applicazioni non comunicano con il kernel, ma con le apposite librerie, le quali si allora che richiamano il kernel. Queste librerie esportano l'interfaccia in C necessaria (o qualsiasi altra: nessuno vieta di avere più librerie, ognuna che esporta le funzioni nell'ABI del linguaggio preferito).
A scanso di equivoci, il kernel (scritto in C++) NON esporta (esporterà) un'interfaccia C++ alle applicazioni, ma C per gli stessi motivi che hai descritto anche te (che, non essendo un kernel monolitico, si limitano a pochi campi come il passaggio di messaggi, gestione processi, gestione memoria, e forse anche filesystem).
Cmq secondo me il modo preferito per le applicazioni di interfacciarsi con l'OS dovrebbe essere proprio attraverso le librerie, e non manualmente richiamando il kernel, perchè ciò ci permette di stravolgere l'ABI "kernel - librerie standard" senza intaccare la compatibilità con i programmi più vecchi (assumendo che le librerie di base vengano modificate, il che è banalmente vero visto che le programmiamo noi stessi).
I componenti che richiedo vengano scritti in C++ (o qualsiasi linguaggio che si adegui all'ABI) sono driver/moduli che verranno caricati in kernel mode. Questi non sono il metodo preferito per scrivere driver in questo OS (che è quello dei driver in user-mode), ma servono solo come complemento a un driver user per gestire dispositivi ad alta velocità/ad alta frequenza di interrupt che risulterebbero penalizzati dall'overheat imposto dalla comunicazione con i driver user-mode.
Ho pensato che non è una richiesta troppo "pazza": visto che un modulo come questo deve lavorare a stretto contatto con il kernel, è accettabile pensare che siano scritti nel linguaggio di quest'ultimo.
Capisco, comunque rimane che ti tocca creare un'interfaccia C apposta. Ma è anche vero che per la pulizia dell'architettura l'interfaccia ci andava comunque.
Quindi boh, mi hai risposto :D
Buon lavoro :asd:
cdimauro
25-01-2012, 07:19
Cmq secondo me il modo preferito per le applicazioni di interfacciarsi con l'OS dovrebbe essere proprio attraverso le librerie, e non manualmente richiamando il kernel, perchè ciò ci permette di stravolgere l'ABI "kernel - librerie standard" senza intaccare la compatibilità con i programmi più vecchi (assumendo che le librerie di base vengano modificate, il che è banalmente vero visto che le programmiamo noi stessi).
Ma le librerie devono comunque comunicare col kernel. Con quale ABI? Quella C++? Allora abbiamo soltanto rimandato il problema...
I componenti che richiedo vengano scritti in C++ (o qualsiasi linguaggio che si adegui all'ABI) sono driver/moduli che verranno caricati in kernel mode. Questi non sono il metodo preferito per scrivere driver in questo OS (che è quello dei driver in user-mode), ma servono solo come complemento a un driver user per gestire dispositivi ad alta velocità/ad alta frequenza di interrupt che risulterebbero penalizzati dall'overheat imposto dalla comunicazione con i driver user-mode.
Ho pensato che non è una richiesta troppo "pazza": visto che un modulo come questo deve lavorare a stretto contatto con il kernel, è accettabile pensare che siano scritti nel linguaggio di quest'ultimo.
Non sono d'accordo per quanto già esposto. I driver li si dovrebbe poter scrivere con qualunque linguaggio che sia in grado di utilizzare un'ABI abbastanza semplice come quella offerta dal C (o Pascal, nel caso di Windows).
Per essere chiari, driver e librerie soffrono dello stesso problema (accedere alle API del kernel) e sarebbe strano e confusionario che per i primi venga adottata la sola ABI C++, mentre per i secondi C++ e/o C.
Ma le librerie devono comunque comunicare col kernel. Con quale ABI? Quella C++? Allora abbiamo soltanto rimandato il problema...
Non c'è nessuna differenza nell'esportare l'ABI comune direttamente dal kernel o dopo nelle librerie, visto che l'applicazione deve comunicare solo attraverso queste ultime.
Forse non sono stato abbastanza preciso nella mia spiegazione.
Prima di tutto, con "librerie di base" intendo le librerie che sono distribuite come parte dell' OS. Tra queste c'è una in particolare: una libreria "principale", caricata automaticamente con ogni binario, che nasconde la natura del kernel alle applicazioni. Io ipotizzo che le applicazioni non debbano comunicare per niente con il kernel direttamente, ma solo attraverso questa libreria.
Un particolare su cui porre attenzione, è che anche altre librerie devono comunicare attraverso questa libreria di interfaccia, sopratutto se sono di terze parti.
Praticamente, quello che in un kernel monolitico sarebbero le chiamate al kernel, qui sono chiamate a questa libreria, che potrebbero non essere solo quelle (poche) esportate dal (micro) kernel.
Ciò ha il vantaggio già descritto del poter stravolgere l'architettura del kernel, mantenendo la compatibilità con tutte le applicazioni, o nel fare altri giochetti, tipo far girare un'istanza del nostro OS, applicazioni e librerie, come applicazione in un'altro OS, semplicemente modificando la "master lib" e tutte quelle che chiamano il kernel direttamente (che, ripeto, sono solo librerie nostre, nessuna lib di terze parti può chiamare il kernel; il modo con cui possiamo rinforzare questo obbligo è da vedere).
Ripeto: già avevo deciso di esportare un'interfaccia C dal kernel (addirittura mi sembrava una cosa ovvia), anche perchè le funzioni delle syscall del kernel sono molto semplici e non serve un orientamento agli oggetti (al massimo si passano strutture di dati); volevo solo dimostrare come si potesse anche fare a meno.
Non sono d'accordo per quanto già esposto. I driver li si dovrebbe poter scrivere con qualunque linguaggio che sia in grado di utilizzare un'ABI abbastanza semplice come quella offerta dal C (o Pascal, nel caso di Windows).
Forse mi ripeto: i driver che richiedo siano in C++ (o linguaggi compatibili) sono SOLO quelli che devono stare in kernel-mode.
I driver user-mode (TUTTI i driver stanno in user-mode, la possibilità di avere un piccolo modulo in kernel-mode non implica l'assenza della parte user) si interfacciano (già, anche qui) attraverso una loro libreria, parallela alla "master lib" delle applicazioni ma caricata solo assieme ai driver e contenente quelle funzioni utili a questi ultimi (come l'accesso alle porte di I/O).
Questa libreria per driver usa le stesse convenzioni della master-lib, quindi il driver user-mode lo puoi sempre scrivere in qualsiasi linguaggio tu voglia.
Come ho già detto prima, non la trovo una richiesta per niente assurda o limitante.
cdimauro
26-01-2012, 07:56
L'idea delle librerie che nascondono i dettagli interni (la vera interfaccia del kernel) non è in discussione, perché è una buona cosa, come tra l'altro già fanno altri s.o., come Windows che ha le sue API native (NT*), ma delega poi ai subsystem la presentazione di un'ABI/API da esporre alle applicazioni.
Riguardo alla questione ABI C++/C ti porto un esempio pratico. Supponiamo che scriva un driver user-mode in FreePascal per una periferica a cui sto lavorando. Tutto a posto, funziona, e siamo tutti contenti.
A un certo punto arriva un cliente che apre un ticket perché si lamenta che nel suo sistema le prestazioni sono troppo scarse e la periferica non riesce a reggere il carico di lavoro.
A questo punto decido di spostare il driver in kernel-space, ma... lo devo riscrivere da zero in C++...
Non è una situazione irrealistica, ma sono cose che capitano "in the real life". Avere due driver model completamente diversi comporta questi problemi.
Mi dirai: perché non sviluppi i driver direttamente in C++? Perché, sempre "in the real life", per me è importantissimo il "time-to-market" e/o la manutenibilità e/o il costo di realizzazione dei miei prodotti, e questo il C++ NON me lo garantisce assolutamente, mentre altri strumenti/linguaggi sì.
Un s.o. "generalista" deve tenere conto di tutto ciò, e offrire un'interfaccia quanto più semplice e flessibile possibile (nei limiti delle due diverse variabili, che non sempre si "sposano").
Se poi parliamo di un s.o. "custom", pensato soltanto in un particolari ambiti applicativi / di mercato, allora è un altro paio di maniche.
Mentre stavo scrivendo una risposta ho realizzato che la gestione a classi dei dispositivi, come è correntemente implementata, non può funzionare al di fuori di quei driver che sono compilati insieme al kernel stesso.
Non ho avuto tempo per pensarci più a fondo, però dovrò modificare di nuovo il modo in cui i driver (attuali) si registrano. In poche parole la classe "Device" diventerà qualcosa di più interno al kernel di quanto non sia adesso.
Da questa modifica risulterà che l'interfaccia che i driver useranno per registrarsi non sarà più object-oriented (nel senso che il driver non deve ereditare la classe e implementare i metodi), quindi ciò risolve anche la discussione in corso: ci sarà un'interfaccia C-like anche per i driver kernel-mode.
Visto che in un thread delle news avevamo cominciato a parlare di API multipiattaforma etc., per ravvivare un po' il thread pensavo di porre un po' di domande riguardanti proprio le API:
Che API possiamo usare nel sistema operativo? Parlando solo di quelle a livello utente, di qualsiasi tipo: grafica, audio, etc...
Secondo me sarebbe molto carino usare API già esistenti e multipiattaforma, in modo da poter avere già qualche programma funzionante.
Oppure potremmo progettare la nostra, magari prendendo solo ispirazione da altre API, in modo da metterci dentro le nostre idee su come Fare le Cose Bene®, così possiamo fare tutti gli esperimenti che vogliamo.
So che la domanda è un po' generica, ma magari riusciamo a tirar fuori qualche bella idea, tanto parlarne non costa. :)
Possiamo iniziare indicando le nostre API preferite. Ad esempio a me piacciono le Qt come librerie per la GUI, e conosco abbastanza bene l'OpenGL.
pabloski
01-05-2012, 21:08
Che ne pensi di questa? http://www.haxenme.org/api/
Ci sono incappato oggi, su suggerimento di un utente del forum di html.it ( che sta pensando ad un os basato su concetti mutuati da erlang, inferno, ecc... ) che mi ha parlato di haxe http://haxe.org/doc
Da lì ho scoperto che ci sono vari progetti collegati, tra cui il framework nme, vari traduttori per svariati linguaggi ( php, html5, flash, uno in sviluppo per java ) e la vm neko ( di cui nemmeno conoscevo l'esistenza ).
In pratica stanno facendo quello che proponi, addirittura inglobando pure le piattaforme mobili. Mi pare complessivamente un degno avversario di qt.
In pratica stanno facendo quello che proponi, addirittura inglobando pure le piattaforme mobili. Mi pare complessivamente un degno avversario di qt.
Interessante, anche se io non volevo avere un linguaggio unificato, ma piuttosto una API che sia abbastanza flessibile da poter scrivere facilmente wrapper per vari linguaggi.
pabloski
01-05-2012, 21:36
Interessante, anche se io non volevo avere un linguaggio unificato, ma piuttosto una API che sia abbastanza flessibile da poter scrivere facilmente wrapper per vari linguaggi.
si potrebbe emulare l'api nme lasciando fuori il linguaggio haxe
il problema è però che si fa con le applicazioni che sfruttano le api classiche c/posix
cdimauro
02-05-2012, 08:23
http://amigadev.elowar.com/ :fiufiu:
il problema è però che si fa con le applicazioni che sfruttano le api classiche c/posix
E che problema c'è? Per la libc nessuno, visto che bisogna metterla per forza, per tutte le altre cose POSIX si scrive una libreria wrapper. Non ci serve per forza essere 100% compatibili, perchè tanto alcune funzioni la maggior parte delle applicazioni non le usa.
Poi in POSIX ci sono anche specifiche sulle utilità e linea di comando che ci interessano relativamente.
Basta vedere Mac OS X che è un sistema POSIX certificato, eppur ha tantissime API tutte sue.
pabloski
02-05-2012, 14:47
E che problema c'è? Per la libc nessuno, visto che bisogna metterla per forza, per tutte le altre cose POSIX si scrive una libreria wrapper. Non ci serve per forza essere 100% compatibili, perchè tanto alcune funzioni la maggior parte delle applicazioni non le usa.
Poi in POSIX ci sono anche specifiche sulle utilità e linea di comando che ci interessano relativamente.
Basta vedere Mac OS X che è un sistema POSIX certificato, eppur ha tantissime API tutte sue.
Pensavo volessi completamente sostituire la classica libc con qualcosa di diverso. Invece hai intenzione di integrarla.
Pensavo volessi completamente sostituire la classica libc con qualcosa di diverso. Invece hai intenzione di integrarla.
La libc è la libreria di base definita dall' ANSI C, per forza dobbiamo metterla dentro, altrimenti qualsiasi minuscolo programma C non può funzionare:
http://en.wikipedia.org/wiki/C_standard_library
Certo, non è detto che quelle funzioni che lavorano con il sistema operativo si devono mappare 1:1 con le syscall come avviene su molti sistemi Unix, si mette un wrapper anche per quelle certo, non volevo negare questo.
cdimauro
02-05-2012, 19:47
La libc serve per il C, appunto. Non c'entra niente con le API esposte dal s.o., che possono essere anche di natura completamente diversa.
Sarà compito di chi scriverà poi la libc fare in modo di mettere a disposizione degli sviluppatori di tutto ciò che serve per essere ANSI C-compliant, sfruttando le API native del s.o. (ospite).
Idem per chi dovrà realizzare librerie e/o altri linguaggi di programmazione. ;)
A proposito di C++, guardate che chicca ho trovato per sbaglio su Linux:
http://www.kernel.org/pub/linux/kernel/v1.0/CHANGES
Change log per la versione 1.0 di Linux:
NOTABLE changes since patchlevel 10 or earlier:
- The kernel is now compiled with C++ instead of plain C. Very few
actual C++ features are used, but even so C++ allows for more
type-checking and type-safe linkage.
CHANGES since 0.99 patchlevel 12 and earlier:
- compiled with plain C by default instead of C++
Praticamente dalla versione 0.99.11 Linux veniva compilato di default come se fosse in C++ (e controllando il Makefile è confermato), mentre dalla 0.99.13 sono ritornati a C puro.
Interessante nevvero? :D
tecno789
07-07-2012, 08:45
Praticamente dalla versione 0.99.11 Linux veniva compilato di default come se fosse in C++ (e controllando il Makefile è confermato), mentre dalla 0.99.13 sono ritornati a C puro.
Interessante nevvero? :D
quindi il contrario di quello che stai facendo tu? :)
pabloski
07-07-2012, 10:38
quindi il contrario di quello che stai facendo tu? :)
Lui lo sta scrivendo in C++, mentre linux era in C ma compilato con g++. Ma a che pro??
quindi il contrario di quello che stai facendo tu? :)
Beh, parzialmente. Han cominciato in C, poi hanno avuto questo piccolo trip in C++ (non credere chissaché, avranno usato solo qualche proprietà del C++ sul type-checking e nient'altro), e infine son tornati al C puro.
Io avevo iniziato in C (volevo partire già dal C++ però c'erano dei dettagli da fare per accontentare il compilatore, "tanto il kernel è una parte piccola e si può fare anche in C"...), poi ho visto quasi subito che usando gli oggetti in C++ e altre proprietà mi veniva molto più semplice fare il tutto scrivendo molto meno codice (lo ho capito proprio quando dovevo fare una lista concatenata, avendone già fatta un'altra pensavo come poter riusare il codice, e ho visto che a meno di trick orribili non si poteva fare), così ho deciso di cambiare e adesso sono a metà della revisione di tutti i file per pulirli e C++izzarli; purtroppo il tempo libero universitario è quello che è, e devo anche mandare avanti un altro progetto prioritario. :(
(Per essere precisi, il kernel compila con il flag C++11 attivo).
Lui lo sta scrivendo in C++, mentre linux era in C ma compilato con g++. Ma a che pro??
Beh lo dice proprio lì, "C++ allows for more type-checking and type-safe linkage"; quindi lo volevano usare per un maggior controllo dei tipi.
Non so se in quel periodo fosse tutto codice C valido, bisognerebbe provare a compilarli senza il flag.
Vincenzo1968
13-12-2012, 18:38
http://www.hwupgrade.it/forum/showpost.php?p=38706833&postcount=411
M'iscrivo anche qui.:O
diablo512
27-02-2014, 08:50
News? :)
News? :)
È passato tanto tempo eh? :)
Non mi ricordo qual'era la situazione all'ultimo messaggio, ma in sostanza ho lasciato perdere il convertire i sorgenti da C a C++ e ho fatto un progetto totalmente nuovo e da subito in C++, meglio organizzato anche dal punto di vista della struttura directory (questo è successo a fine 2012, inizio 2013).
Al momento si avvia, i costruttori degli oggetti statici vengono correttamente chiamati etc.
Poi ci ho lavorato sempre meno per vari motivi: l'università prende tempo, c'erano delle cose che volevo aver ben chiaro in mente prima di implementare e sopratutto ho un altro progetto in corso che se va a buon fine potrebbe portare bei soldini...
Quindi boh, il sorgente posso anche caricarlo ma non è che faccia molto.
Quello che servirebbe sarebbe invece pensare un buon sistema di message passing, visto che è uno strumento essenziale all'architettura che ho in mente. :cool:
mone.java
28-02-2014, 12:34
Quello che servirebbe sarebbe invece pensare un buon sistema di message passing, visto che è uno strumento essenziale all'architettura che ho in mente. :cool:
Ciao, qualche anno fa all'università di bologna abbiamo fatto un piccolo kernel per architettura uUMPS basato sul message passing... il progetto l'ho messo su google-code: https://code.google.com/p/amikaya-os-2011/ magari puoi darci un occhiata...
Nella cartella dei sorgenti in trunk/ trovi sia il PDF con le specifiche che un PDF con la relazione che abbiamo redatto per il prof (Renzo Davoli).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.