Newsgroup: it.comp.os.dibattiti
Titolo: Il sistema grafico di VegetaOS

 PhGraphicCard.0              (Kernel mode)
Che ne pensate?
Saluti
Vegeta

 Che ne pensate?
Che e' piu' facile parlare che fare.

 Che ne pensate?
Solo una domanda: non sarebbe meglio iniziare dalle
fondamenta, invece che dall'attico?
bye,
-- 
   Piergiorgio Sartor

 Che ne pensate?
Beh io non sono un esperto. Pero' leggendo mi sono saltate alcune domande
basilari.
La prima e' se questo tipo di approccio che tu hai sia sufficientemente
descrittivo ai fini della stesura di un SO. Oppure sia ancora troppo
astratto, benche' comprensibile.
La seconda e' che tu hai dato per scontate molte cose. Parli di messaggi,
per esempio. Non hai specificato in che modo il kernel comunica con i
sottosistemi. Il tuo post e' un esempio, ma la regola qual e'?
Esistono dei punti cardine di questo OS? Quanti e quali?
Scusa per le banalita'.
Saluti.

 <icq:241572242>
But still I fear, and still I dare not
Laugh at the mad man (The Prophet's song)

 VegetaOS?
Di merda! :)

 mondo Linux e del mondo Windows.
Sono onesto: ammiro la tua dedizione al progetto e ti auguro di andare avanti.
L'unica cosa che mi chiedo e': non ha ancora degli scopi "troppo nebulosi e non 
ben definiti"?
-- 
  _|O|_ Davide Silvio Inglima-Modica     | "Mana is rapidly disappearing from"
  _|_|O mailto:
hades...@despammed.com
 | "the Earth, even the mana tree has"
  O|O|O 
http://limacat.blogspot.com
      | "begun to wither" Seiken Densetsu 3
Posted from X-Privat Free NNTP server - 
www.x-privat.org


Si. Ma non è possibile riassumere tutto in poche righe perchè
sarebbe del tutto incompleto. Considera poi che siamo in fase
di progettazione, e quindi le specifiche sono soggette a revisioni
progressive.
Saluti
Vegeta


Microkernel. Questo viene compilato direttamente in fase di installazione
insieme ad altre librerie e componenti critici per potere girare alla
massima velocità possibile, usando tutte le istruzioni estese del
processore. Alcune aree del microkernel sono scritte direttamente
in assembler per avere la massima velocità.
Il kernel supporta i moduli. E' in teoria possibile aggiungere al
microkernel
dei moduli che vengono caricati solo se ciò è necessario.
Ogni applicazione deve essere scritta totalmente a 32 bit, e lavora in una
propria area di memoria, protetta. Ogni applicazione può interagire solo
con la propria area di memoria, o con delle zone del kernel che sono
"pubbliche" (come i registri messaggi dell'IPC).
Scheduler: simile a quello Unix. Ogni applicazione ha a disposizione un
periodo di tempo minimo (quantum time) per l'esecuzione. Ogni applicazione
può tenere il controllo della CPU per un massimo di 4 quantum time (a
seconda del carico che in quel momento esercita l'applicazione). Il
multitasking è preemptivo. Quando un'applicazione chiede l'esecuzione
di un'operazione al kernel può farlo in due modi: attraverso una chiamata
diretta, ovvero attraverso una chiamata indiretta. Se l'applicazione ha
fatto una chiamata diretta al kernel, lo scheduler non può cambiare il
processo corrente finchè l'operazione richiesta dal kernel non si è
esaurita. Se l'applicazione ha fatto una chiamata indiretta al kernel,
la richiesta viene semplicemente accodata, ed il kernel la eseguirà
quando meglio riterrà opportuno: l'applicazione continua ad attendere
finchè non gli viene inviato un messaggio dal kernel che conferma il
compimento dell'operazione. Durante tale tempo di attesa lo scheduler può
togliere il controllo all'applicazione per darlo alle applicazioni
concorrenti.
File system: utilizza uno standard universale per la gestione dei file
system
(VFSS - VegetaOS File System Standard). Quando si vuole supportare
un nuovo file-system, si scrive semplicemente un nuovo modulo compatibile
con le specifiche VFSS e lo si installa: l'OS riconosce immediatamente
il nuovo file-system. Sto lavorando sulle specifiche per un file-system
proprietario che supporta nativamente crittografia, diritti d'accesso,
compressione,
ridondanza per resistenza agli errori e così via: ma è ancora presto per
parlarne.
IPC: Ne ho già parlato nel messaggio a Endymion
Ciao
Vegeta


Questo mi sembra faccia parte gia' da tempo del layer VFS di linux (e 
non solo di linux)...        :-)
bye G.L:

 [SNIP]
Non e' che a scrivere prima le specifiche va a finire che ti stanchi 
prima di cominciare?
Tra l'altro e' difficile stabilire tutto a priori, perche' poi dovrai 
scontrarti coi problemi d'implementazione.
Secondo me ti conviene (se sei convinto) cominciare dal kernel e poi, se 
avrai tanta gente che ti segue, piano piano farete tutto il resto.
MA:
La gente (intesa nel senso di programmatori) ti seguira' solo se 
riterra' che questo OS abbia delle caratteristiche per cui vale la pena 
di spendere tempo e risorse.
Cioe', in pratica quello che e' importante di questo OS e' quello che 
offre DI MEGLIO ripetto a quelli gia' esistenti.
Quindi: per avere in mano subito qualcosa di corposo, non ti conviene 
partire dal codice di un kernel gia' esistente, o comunque partire da 
zero ma ritagliare codice qua e la' per avere in fretta drivers e 
supporto per cio che non e' ancora implementato?

 scontrarti coi problemi d'implementazione.
Ecco, il problema principale e` questo IMHO. Certe cose dal punto di
vista implementativo sono quasi impensabili partendo da zero e in poco
tempo. Certe altre che ha scritto sono impensabili nel 2003, magari
nel 1950 si potevano pensare ma non oggi...
Tutto quell'accrocchio sull'IPC e la faccenda del "solo 32 bit" e`
roba che al massimo, forse, fara` usare il suo OS solo a lui.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 tolto fino al completamento della richiesta...
Le chiamate dirette vengono fatte quando il PC deve eseguire
una operazione che non può essere interrotta nel kernel.
Allora, il sistema attende che la chiamata al kernel sia
completata prima di potere processarne altre.
Le chiamate indirette, al contrario, prevedono che il processo
attenda il completamento dell'operazione da parte del kernel.

 roba che al massimo, forse, fara` usare il suo OS solo a lui.
Insomma. Sotto BeOS le applicazioni Dos a 16 bit non
girano....
Riguardo all'accrocchio dell'IPC, lo fa anche QNX.
Di mio ho aggiunto il fatto che il kernel
possa decidere se passare o meno i messaggi ai processi, perchè
un processo non autorizzato non deve essere in grado di interagire
con un altro.
Saluti
Vegeta
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/03


In teoria sì. Il problema, però, è che i kernel
di BeOS e di QNX, che sono due sistemi operativi
molto più vicini a VegetaOS di Linux (da cui VegetaOS
ricava solo alcune scelte per garantire la sicurezza di
funzionamento e la stabilità delle applicazioni), non
sono disponibili....



Diciamo che e' conveniente in tal caso che il kernel ponga il processo 
in attesa, e' inutile che il processo "cicli" (sprecando cicli macchina) 
attorno ad un flag nel suo user space o in apposita area condivisa per 
verificare il completamento della svc e prelevare i dati dal buffer (o 
aver conferma che son stati inviati, tutte cose che avevo gia' 
sperimentato nel sistema operativo RSX11: $QIO e $QIOW...) in ma penso 
che  stiamo parlando fondamentalmente della stessa cosa.
bye G.L.

 con un altro.
Si, ma scrivere un po' di specifiche prima, cioe`
cosa si vuole fare e non come, non sarebbe malvagio.
La "protezione" dai messaggi e` una specifica?
bye,
-- 
   Piergiorgio Sartor

 IPC: Ne ho già parlato nel messaggio a Endymion
Non ho ancora compreso se questo os è microkernel oppure no.
Ad esempio... C'è un FS server?


 Ad esempio... C'è un FS server?
Nel kernel c'è un object manager che riceve dai processi le richieste per
i vari oggetti, e provvede a smistarle.
Nel kernel c'è anche, vero, del codice che si occupa di richiedere
all'object
manager di rintracciare, fra gli oggetti del sistema, l'oggetto
File-System. Il chè significa che il kernel sa che c'è un file-system
nel sistema (perchè altrimenti non potrebbe funzionare), ma non
sa come gestirlo (sa che nell'oggetto file-system c'è una funzione
che consente di scrivere un file in una certa unità logica, ma non
sa di preciso come si scrive il file in una unità FAT, o in un'unità
HPFS).
Le richieste del kernel vengono redirette dall'object manager
all'oggetto File-System, che a sua volta provvede a redirigerle
agli oggetti dipendenti (che sono quelli che contengono il codice
per accedere ai vari file-system FAT, EXT2, CDFS ecc. ecc.).
La struttura oggetti di primo livello ed oggetti dipendenti è
gestita dall'object-manager dinamicamente: ogni oggetto ha degli
oggetti dipendenti, ma quali essi sono viene scelto dinamicamente
durante il funzionamento (significa che File-System ha degli
oggetti figli, come ad esempio FAT-FS e EXT2-FS, ma non
avrai quest'ultimo in memoria se non hai partizioni EXT2-FS sul
tuo PC).
A questo punto si tratta solo di dire se gli oggetti (che, come vedi,
non sono integrati nel kernel, ma solo entità esterne a cui il kernel
reindirizza), girano in user-space o in kernel-space.
Gli oggetti di tipo *critical* di VegetaOS (diversamente da quelli
*soft* che sono definiti dai processi), girano in user space ad una
priorità intermedia tra il kernel ed i processi (ring 1).

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true. [J. Robert Oppenheimer]


Gli oggetti di VegetaOS *girano*. E' una delle novità di
VegetaOS.
Un oggetto sotto VegetaOS è una struttura costituita da
a) processi
b) procedure e funzioni
c) permessi
d) proprietà
Ogni oggetto si compone di una prima struttura detta "primary
interface" che contiene un set di funzioni e procedure che
dovranno essere richiamate dal kernel o dai processi utente.
Un processo utente può interagire con tutto ciò che c'è
all'interno dell'oggetto solo attraverso delle chiamate
sulla primary interface.
In realtà, il processo utente indirizza la chiamata al kernel:
quest'ultimo verifica, attraverso l'object manager, che
l'oggetto richiesto esista e che il processo utente abbia il diritto
di richiamare quella determinata funzione (quindi la gestione
dei permessi viene fatta dall'object-manager ed è hardcoded
nel kernel).
Se i diritti sono corretti, la richiesta viene passata alla primary
interface dell'oggetto (l'object-manager calcola l'indirizzo
corretto della procedura e provvede a passare il controllo
a questa).
Anche se l'interazione avviene sempre nello stesso modo, la
primary interface può svolgere la funzione assegnate in tre
modi diversi:
a) Esecuzione di un Get Properties
In tal caso il codice della primary interface si occupa solo di
determinare l'indirizzo di un dato che è stato richiesto dal
processo utente e che in questo momento sta nella "memory
area" dell'oggetto. Per esempio, se si chiede all'oggetto
Processore di fornire la sua frequenza, il sistema si limiterà
ad andare a leggere due byte nella memoria area dell'oggetto,
ed a copiarli in un registro del processo utente.
b) Esecuzione di una operazione diretta
In tal caso il codice della primary interface esegue direttamente
l'operazione.
c) Interazione con un Object-Process.
Gli oggetti sotto VegetaOS possono contenere dei processi.
Questi processi girano in ring 1, ad una priorità maggiore
rispetto a quella dei processi utente. La loro area di memoria
è protetta, ed i processi utente non possono in alcun modo
interagire con loro, neanche tramite IPC.
Gli object-process possono interagire solo con la loro
corrispondente Primary Interface. Per fare questo si
servono di un sistema di messaggistica specifico, diverso
da quello usato dai processi, che si chiama xIPC.
La primary interface in genere provvede a trasmettere un
messaggio via xIPC all'object-process, che lo accoda e lo
esegue quando ritiene più opportuno (per esempio, quando
ha esaudito le richieste precedenti).
Quando l'operazione viene completata, l'object-process può
inviare un messaggio via xIPC alla primary interface che può
provvedere a sua volta a ritrasmetterlo, stavolta via IPC, al
processo utente.
Per esempio, l'oggetto SecurityModule, possiede un processo
che si occupa di generare ad intervalli regolari dei numeri
casuali, che vengono poi utilizzati da un sottosistema del
kernel per verificare che la copia del sistema operativo sia
legale. Questo processo gira in modo trasparente alle
applicazioni, che non possono far niente per interagire con
esso.
Un altro esempio è lo spooler di stampa: l'applicazione
non deve attendere che la stampa sia completata. Si limita
ad inviare i dati per la stampa nell'oggetto Stampante, e
lì un object-process si occuperà di stampare questi dati
inviandoli alla porta LPT o USB (nel frattempo l'applicazione
utente e le altre applicazioni procedono senza evidenti
cali di velocità).
Gli object-process non possono comunque bloccare il
sistema operativo. Se un object-process si blocca, esiste
una funzione della primary interface dell'oggetto che
consente di reinizializzarlo: naturalmente, per usarla,
è necessario avere i necessari diritti.
A ring 0 gira invece il kernel, con tutti i propri sistemi
(tranne quelli che vengono implementati come oggetti).


 dovranno essere richiamate dal kernel o dai processi utente.
In che modo pubblichi le interfacce? Con un meccanismo stile COM ?
Saluti.

sono disponibili....
Hai dato un'occhiata a come implementano il kernel i ragazzi di
OpenBeOS?

 ha scritto nel messaggio
news:bpr083$r7c$1...@lacerta.tiscalinet.it...

Esatto.
Saluti
Vegeta

 ha scritto nel messaggio
news:p6g2sv8116n8c0v9v...@4ax.com...

In realtà, so che loro partono da un kernel minimale
che è quello di NewOS.
Devo vedere se come implementazione è accettabile
per il mio VegetaOS.
Grazie comunque per il suggerimento.
Saluti
Vegeta

 file system
esiste già. Si chiama VFS e, in una forma od un'altra, è usato da tutti 
gli UNIX. E fa il suo sporco dovere
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 gli UNIX. E fa il suo sporco dovere
Beh... E visto che siamo nel 2003 direi anche di creare addirittura un altro
layer sopra VFS magari implementato con EVMS visto che la cosa renderebbe
il sistema di gestione dischi veramente molto semplice da gestire.


 errori
/me pensa alle epoche e rabbrividisce...
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.


 
Per carita', se proprio devi ispirarti usa qnx, o solaris o aix, non
andare a cascare nella brace......

 errori
Fonte?

 Fonte?
Mah sono passati da un obbrobrioso scheduler O(n) a uno scheduler
multicoda O(1). Noti qualche somiglianza?
Saluti.


 multicoda O(1). Noti qualche somiglianza?
Io non ho replicato prima perche` pensavo che ci fossero ragioni
fondate, ma se tutto si ferma qua allora avete detto la solita
baggianata...


 messo undici anni per riconoscerlo come il migliore
interpreta, ovviamente, "il migliore dei due".


 interpreta, ovviamente, "il migliore dei due".
Il vecchio scheduler infatti non era il massimo come potenza, ma solo
pensando ai server con N thread con N > 1000 contemporaneamente in
esecuzione. Su un desktop si nota molto meno uno scheduler O(n).
Il nuovo scheduler di linux da la paga anche allo scheduler di freebsd
5, con buona pace dei freebsdiani. Su internet (slashdottati tempo fa)
sono apparti bench _approfonditi_ tra il vecchio linux e il nuovo,
freebsd 5, netbsd e openbsd. Il vecchio linux non era proprio il
massimo anche se in alcuni compiti (1 o 2 su una 15ina di test)
risultava il migliore. Il kernel 2.6 e` risultato il migliore quasi in
tutto, piu` dell'80% dei test. In 1 o 2 freebsd e` stato il migliore
(marginalmente) ed e` stato secondo per tutti gli altri.


 massimo anche se in alcuni compiti (1 o 2 su una 15ina di test)
                                                    ^^^^^^
secondo me tu ti confondi con i test di scalabilita' apparsi qlc tempo fa':
i test erano 8 (se nn ricordo male) e free5 mostrava di utilizzare un 
algo con complessita' piu' alta (O(n) o O(logn) ora nn ricordo) solo in 
1 caso rispetto a Linux 2.6.
E per essere precisi, quelli di NetBSD, dopo aver visto i risultati di 
quel test si sono rimboccati le maniche ed ora (sempre se nn ricordo 
male pure stavolta) NetBSD e' al pari di Linux o giu' di li' in tutti i 
campi.
Vabbe', finito di scrivere cavolate, avevo 10min liberi prima della 
pausa caffe', torno ai cavoli miei ora... =)
Paolo

 tra il vecchio linux e il nuovo, freebsd 5, netbsd e openbsd. 
ROTFL !
Bench _approfonditi_ con due sistemi operativi scaricati da CVS ?
Per non farli approfonditi cosa bisognava fare ? Farli fare a dmitry ?
-- 
                                                __Nicholas Wieland
Explicit is better than implicit.
                                                __The Zen of Python

 Per non farli approfonditi cosa bisognava fare ? Farli fare a dmitry ?
Eh eh :). Approfonditi nel senso che hanno fatto parecchi test per
vedere come e` il comportamento di una stessa funzionalita`.


 pausa caffe', torno ai cavoli miei ora... =)
C'hai ragione, mi sono sbagliato abbastanza clamorosamente, la mia
memoria ha fatto cilecca.
Era proprio quelli i test.


 vedere come e` il comportamento di una stessa funzionalita`.
Ho capito, ma se proprio chi li ha fatti e' cosi' "clueless" da usare
sistemi di test, che almeno usi delle release, non dei sistemi operativi
scaricati da CVS...
-- 
                                                __Nicholas Wieland
If the implementation is hard to explain, it's a bad idea.
                                                __The Zen of Python

 scaricati da CVS...
Si ma era un "Quello che verra`...", a parte linux 2.4, tutti gli
altri erano in testing se non sbaglio.


 altri erano in testing se non sbaglio.
CVS. Leggi bene che lo dice.
Tutti CVSup. Tipo che ha avuto culo che compilassero :)
-- 
                                                __Nicholas Wieland
Special cases aren't special enough to break the rules.
Although practicality beats purity.
                                                __The Zen of Python

 Tutti CVSup. Tipo che ha avuto culo che compilassero :)
 
E magari in quel momento c'era un'ottimizzazione strafiga che poi è stata 
ignobilmente cassata via ;))
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

 ignobilmente cassata via ;))
Sinceramente non lo so, pero' io credo che i benchmark abbiano un
(tenue) senso solo se fatti da persone differenti che conoscono i
sistemi su cui vanno a lavorare e su software in produzione.
Poi sono opinioni.
-- 
                                                __Nicholas Wieland
Simple is better than complex.
                                                __The Zen of Python