Newsgroup: it.comp.os.dibattiti
Titolo: os/2 - mach - osx

Scusate, ma e' corretto?
(da 
http://www.zdnet.co.uk/news/2001/13/ns-22124.html
)
"...
The Mach microkernel was created at Carnegie Mellon University in 1985 and
has been incorporated into a number of commercial operating systems
including IBM's OS/2 on certain platforms and Apple's OS X. Torvalds says
that as developers have tried to improve the Mach microkernel it has become
hugely complicated and convoluted. "
Cioe' OS/2 e' uno unix con microkernel mach? Oppure sono io che non ho
capito una mazza?
E, visto che ci siamo, qualcuno mi riesce a dire se OSX e' un microkernel?
E qualcuno ha capito se X ha la grafica in kernel o no?
Grazie e saluti
Marco


Ciao,
Marco

 E qualcuno ha capito se X ha la grafica in kernel o no?
No di certo !
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 E qualcuno ha capito se X ha la grafica in kernel o no?
E' un ibrido. Se non sbaglio ha uno spazio di indirizzamento comune per
ovviare a certi problemi di lentezza... non ci ho capito molto, ma la
documentazione c'č:
http://developer.apple.com/techpubs/macosx/Kernel/General/KernelEnvironment/
index.html
Il resto non l'ho capito bene. Intendi OSX? No la shell Aqua č a se stante.
Non sono diffusi i sorgenti della shell grafica. Del kernel Darwin si'.
Ciao.

No di certo !
Se intendete dire quartz, no. Viceversa, da quello che ho letto, ho 
l'impressione che driver della scheda video siano estensioni del kernel 
caricate nel kernel space.

 capito una mazza?
No, non e` spiegato bene... si narra che la versione di OS/2 per PowerPC
era basata sul kernel Mach... purtroppo non so dirti di piu` avendo OS/2
solo per PC, tranne che quello per PC (oltre a funzionare molto bene) non
e` microkernel...
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://www.quasarbbs.net/mircomir/
 ]

 caricate nel kernel space.
Beh se e' cosi' non mi sembra una cosa furba: praticamente avrebbero
clonato lo stesdo madornale errore del team di sviluppo di Neanderthal
Technology, ottenendo un accesso alla grafica piu' veloce ma al tempo
stesso meno affidabile.


 No di certo !
mmmhh, allora si dovrebbe poter far girare Xfree su MacOsX, e questo ultimo
dovrebbe sopravvivere ai crash di Aqua... carino.
Forse con questo si spiega la sua lentezza. Qualcuno ha visto quanta ram si
magna Aqua? Con che processo gira?
Saluti
Marco

 caricate nel kernel space.
alla faccia del microkernel! ;-))
MA allora hai gli svantaggi di entrambi i sistemi: la gui non e' reattiva
pero' ti puo' impastare il sistema?!?!
Dimmi che non e' vero...
Saluti
Marco

 magna Aqua? Con che processo gira?
I dunno.


stesso meno affidabile.
Si potrebbe dire la stessa cosa dei driver della scheda di rete, del bus 
scsi, della seriale, del mouse e cosi' via. Tutte cose che risiedono nel 
kernel, non solo dell'OSX.
Comunque, immagino che il driver si occupi solo di cose elementari. Il 
resto dovrebbe stare piu' su.

Dimmi che non e' vero...
Era solo una supposizione. Comunque, vado a controllare. Per chi e' 
interessato:
http://developer.apple.com/techpubs/macosx/Kernel/IOKit/DeviceDrivers/WritingKi
tDrivers/About/index.html
ciao

nke) oppure "sopra" tra i core services ...
Onestamente, neanche io ho capito a che livello stanno i driver video. 
Immagino comunque che nel kernel risieda una qualche forma di supporto. Ma 
non vado oltre con le supposizioni.
-- 
Balrog ):E...

Forse con questo si spiega la sua lentezza.
No, propendo per la grafica PDF implementata in floating point... anche se 
non so se sia sufficiente a giustificare tutta la lentezza. Se fosse un 
problema a piu' basso livello, anche i giochi, come le applicazioni che 
girano in emulazione dentro Classic, andrebbero da schifo. Invece non e' 
affatto cosi'.
ciao

 resto dovrebbe stare piu' su.
Ma rimaniamo sempre nel campo delle supposizioni, mi sembra.


Ma rimaniamo sempre nel campo delle supposizioni, mi sembra.
Si, si parla per ipotesi. Mi pare di aver capito che apple non abbia 
rilasciato la documentazione del video server e di come utilizzi i driver 
video. Esiste un IO Kit che definisce alcune classi di driver (nel vero e 
propri senso della parola, visto che si tratta di oggetti dell'embedded 
C++), tra cui suppongo esista quella dei driver video. I driver dovrebbero 
essere residenti nel kernel, visto che per debuggarli e' necessario 
adottare le stesse modalita' di debugging delle kernel extensions. Piu' di 
questo, non so.
-- 
Balrog ):E...

 video. Esiste un IO Kit che definisce alcune classi di driver (nel vero e 
Uhm la via proprietaria.. mi pare che dopo aver tanto parlato di
aderenza all'Open Source si caschi sull'uccello, come la sig.ra Longari.
E questo IO kit scommetto che e' pure a pagamento, vero? Molto
interessante..


...E questo IO kit scommetto che e' pure a pagamento, vero?
L' kit e' del kernel e lo puoi trovare in Darwin. Il video server e' un'altra 
cosa.
-- 
Balrog ):E...

 sei un po' confuso.
Beh, pero' per esempio in una workstation grafica (mercato apple di
elezione) e' piu' utile un milionesimo di secondo in meno nel fare il
rendering di una videata che un milionesimo di secondo in meno nel
trasferire un byte (lavoro da server --> mercato di elezione di linux e NT
server).
Saluti
Marco

 cosa.
A me sembrava si parlasse del secondo, poi non so..


giocattoli ed inutilities.
Appunto ma se il SO venisse usato prevalemtente come client come e' il
caso di Mac osX?
Ciao
  Francesco Da Riva

 server).
Sicuramente, ma non venitemi a dire che cio' favorisca la stabilita'
perche' NT e' un lampante esempio del come cio' non sia vero. Ed avete
letto come e' stata criticata la scelta di una possibile versione di X11
in kernel space, il che significa che la cosa non era ben vista in
quanto potenzialmente pericolosa per la stabilita' del sistema,
appunto.


 caso di Mac osX?
La stabilita' sarebbe meno importante, ma non per questo garantita.


 affatto cosi'.
Mi sa che la spiegazione deve essere da qualche altre parte...
-- 
 "Si', d'accordo, Free Mandela, Free Valpreda e tutti gli altri, ma Free
 anche mio cuggino... anzi, Free anche -a- mio cuggino!" (Elio e L.S.T.)
 Rudi Chiarito         SGML/XML, user interface, i18n         Amiga Inc.
 
ru...@amiga.com
 
http://amiga.com/

Sicuramente, ma non venitemi a dire che cio' favorisca la stabilita'
E chi lo dice? 
-- 
Balrog ):E...

 E chi lo dice? 
I fatti: poi se tu sei in grado di dimostrare che NT e' stabile grazie
al fatto avere la grafica in kernel space fatti avanti, attendiamo
tutti impazienti la tua spiegazione.


importante per discernere quale possa essere l'importanza della grafica,
Comunque, come ho detto prima, questo problema potrebbe essere in realta' un 
problema molto marginale. NT e figli hanno il problema di aver a che fare con 
hardware molto eterogeneo, il che complica le cose.
-- 
Balrog ):E...

mai stato definito lento.
Non credo sia solo un problema di coordinate. Tanto per fare un esempio, un 
layer di quartz (equivalente di una porta grafica) supporta alfa channel, 
anti aliasing (non locale alla porta, ma globale al desktop) ed mi pare 
abbia anche una profondita' propria.
-- 
Balrog ):E...

 hardware molto eterogeneo, il che complica le cose.
E' comunque un problema legato ad NT ed alla errata scelta progettuale,
non all'architettura altrimenti non si spiega perche' solo NT ne soffra.


 abbia anche una profondita' propria.
Elate supporta alpha channel, blending, anti aliasing e tutta una marea di
altre cose, e nonostante si basi su una macchina virtuale è *estremamente*
veloce.
Fabio Alemagna

tutti impazienti la tua spiegazione.
No, non mi sono spiegato: chi e' che ha detto questo? Io non lo sostengo.
-- 
Balrog ):E...

veloce.
In che senso li supporta? Scendi nei dettagli, perche' cambiano molte cose.
A scanso di equivoci, ci tengo a precisare che io ho un po' di dubbi sul 
risultato ottenuto da Apple con Quartz.
-- 
Balrog ):E...

trovato stabile, altrimenti si continua a fare parole inutili.
Giusto. Non ho riscontrato problemi, ma non l'ho usato molto. Notizie in 
tal merito non ne ho raccolte. Quando avro' piu' informazioni in tal senso 
ne faro' partecipe il gruppo.
-- 
Balrog ):E...

 In che senso li supporta? Scendi nei dettagli, perche' cambiano molte
cose.
Nel senso che ogni pixel č dotato di alfa channel. Il blending č supportato
a livello di API, cosě come l'anti aliasing.
Dai uno sguardo a queste pics:
http://www.amigasdk.com/screen.php
Ce ne sono altre di piů esplicative sul sito della TAO:
http://www.tao-group.com
Fabio Alemagna


 ne faro' partecipe il gruppo.
Bene quindi per il momento e' inutile continuare il thread.


 E chi lo dice? 
Senti un po', piantala di attaccarti alle singole parole pur di
contraddire: sono io a dire (anche perche' ci sono stati lunghi thread
in proposito qui) dall'inizio del thread che la grafica in kernel
space porta alla instabilita' e *tu* invece stai dicendo che non e'
importante se in alcuni casi si deve lavorare con la grafica.


 No, non mi sono spiegato: chi e' che ha detto questo? Io non lo sostengo.
Vabbe', lasciamo stare...


Bene quindi per il momento e' inutile continuare il thread.
Ma no, perche' non perdere ancora un po' di tempo in discussioni 
filosofiche?
;)
ciao
-- 
Balrog ):E...

importante se in alcuni casi si deve lavorare con la grafica.
E neanche mi pare un reato considerare anche altri criteri di valutazione.
-- 
Balrog ):E...

 E neanche mi pare un reato considerare anche altri criteri di valutazione.
Certo che no, ma mi concederai, visto che sono abituato ad un sistema in
cui la grafica in kernel space non c'e' e cio' va indubbiamente (visto
che pare siamo tutti concordi su questo) a vantaggio della stabilita',
di continuare a ritenere che sia una boiata?


 filosofiche?
Puoi continuare anche da solo, se proprio ne trai cosi' tanto piacere
;-) Ti fai un altro account e ti rispondi da solo <g>


 sei un po' confuso.
Beh, pero' per esempio in una workstation grafica (mercato apple di
elezione) e' piu' utile un milionesimo di secondo in meno nel fare il
rendering di una videata che un milionesimo di secondo in meno nel
trasferire un byte (lavoro da server --> mercato di elezione di linux e NT
server).
Saluti
Marco

 Beh, pero' per esempio in una workstation grafica (mercato apple di
[..]
Ma.. mi sembra male o questo l'avevi gia' postato??


supportato a livello di API, cosě come l'anti aliasin
Il blending con alfa channer e' piuttosto semplice da realizzare. L'anti 
aliasing e' un po' piu' complesso. Aggiungi il buffering automatico e la 
suddivisione tra coordinate di sistema e coordinate utente col supporto 
della conversione tra l'uno e l'altro sistema di riferimento con 
trasformazioni, magari non lineari. Penso che ottenere prestazioni 
eccellenti per fare queste cose non sia semplice.
Sarei curioso di dare un'occhiata alla documentazione dell'Amiga SDK, ma 
non mi pare sia disponibile, se non pagando. Peccato.


 Ma.. mi sembra male o questo l'avevi gia' postato??
Ho paura che mi sia uscito 2 volte... sorry
Marco

 Ho paura che mi sia uscito 2 volte... sorry
No problemo :)


 E qualcuno ha capito se X ha la grafica in kernel o no?
Non lo so...
Mi vien da chiedere che senso avrebbe una cosa simile: verrebbe lesa la 
flessibilità per la quale la scelta di un microkernel possa rivelarsi 
utile, a discapito delle prestazioni, sicuramente maggiori in sistemi 
monolitici (Hurd docet).
Tra l'altro: volete vedere che con il marketing di Cupertino torna di 
moda mach, nonostante Hurd sia ancora sconosciuto ai più?
--
Au revoir.
Lele...

rendering di una videata che
No.
Obelix

 Che e' _esattamente_ cio' che vado dicendo..
Comunque se si implementasse la grafica a livello kernel su linux avresti
sempre la possibilitą di compilarlo senza, cosa che in NT non e' minimamente
immaginabile. :-)

 immaginabile. :-)
Beh certo ma credo che sia comunque una cosa che interessa a pochi :)


 No.
Ho perso il filo: me la speghi in stile non-MdI? ;-)
Saluti
Marco

di continuare a ritenere che sia una boiata?
A questo punto spiegatemi una cosa: perche' tutti i driver possono stare 
nel kernel, tranne quello della scheda video?
-- 
Balrog ):E...

 nel kernel, tranne quello della scheda video?
Cambia spacciatore, quello che hai ti da' della roba molto scadente e
cio' ti spinge a scrivere cazzate come questa: nessuno ha mai detto una
cosa del genere bensi' solo che la grafica in kernel space porta ad
instabilita' e che mentre e' una cosa normale avere il driver di una
ethernet in kernel space non e' altrettanto logico che debba esserci la
GUI e tutta la gestione della grafica. Se ne sei capace dimostra il
contrario altrimenti piantala.


 nel kernel, tranne quello della scheda video?
Ops, penso si debba spiegare cosa si intende per "driver".
Tutti i driver stanno nello stesso spazio (di solito kernel).
Pero` la GUI od X non sono "driver".
Ad es. il driver NVidia e` un modulo kernel, cosi` come
l'interfaccia AGP, pero` OpenGL od X sono in user space
ed usano la scheda tramite il suo driver.
bye,
-- 
  Piergiorgio Sartor

server?
sto seguendo lo sviluppo di un clone di Windows NT, e ho una notizia
incoraggiante (beh, sempre che il progetto abbia successo): il driver
per la grafica (quando ce ne sarà uno :) sarà disattivato di default (il
sistema punta soprattutto al mercato server - purtroppo) e in ogni caso
sarà possibile caricarlo e terminarlo a piacimento. Giusto per
dimostrare che l'architettura di NT non è cattiva (tutt'altro, anzi, per
quanto - poco - conosca entrambe, sarei tentato di dire che è meglio di
quella di Linux), ha solo avuto le amicizie sbagliate :)
tra l'altro, in mailing list sta girando una storia carina. Sembra che
Microsoft, poco prima di tirare fuori Windows, avesse acquistato i
sorgenti di un programma di grafica per DOS... magicamente, pochi mesi
dopo, eccoli che tirano fuori un'interfaccia grafica per DOS. Andiamo a
vedere le funzioni di sistema della GDI, e troviamo più d'un (circa il
50% :) riferimento a "penne", "pennelli" e "tavolozze" (pen, brush,
palette)... pura coincidenza? :)
-- 
Posted from 
smtp.technorail.com
 [195.103.144.19] (may be forged) 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

tutti impazienti la tua spiegazione.
non mi sembra abbia detto questo. La domanda è se l'instabilità di
Windows NT derivi *unicamente* dal fatto che si faccia interagire l'user
mode con l'hardware "direttamente e senza passare per il Via" (Monopoli
docet)


Ho perso il filo: me la speghi in stile non-MdI? ;-)
Uffa. Il rendering di una videata serve all'utente per farci qualcosa.
Una differenza di un milionesimo di seconod sulal videata (*non* sulla
singola operazione sul bit...) e' di fatto irrilevante. Mentre invece
in un trasferimento di byte (milioni di byte al secondo, mentr le
videate sono una ogni ,2 secondi al massimo...) un milionesimo al byte
*applicato a milioni di byte* e' senz'altor piu' utile *anche alla
videata stessa*..
Obelix

GUI e tutta la gestione della grafica.
solo l'accesso diretto alla scheda video. Torniamo al tuo amato Windows
NT: il sistema non *richiede* l'interfacca grafica, e in Windows 2000
non farti ingannare dal logo e la progress bar all'avvio! Controllando
la frequenza del monitor ti accorgeresti che è in modalità VGA
(disattivabile con modifica al boot.ini, se è questo a preoccuparti),
come un qualsiasi DOS, ed esattamente come la schermata blu all'avvio di
Windows NT 4. Il sottosistema Win32 (crss.exe) nemmeno, semplicemente lo
carica (win32k.sys), perchè sennò i gestori della GUI e della GDI
(user32.dll e gdi32.dll) si lamenterebbero vivamente. Ma win32k.sys, di
suo, gestisce l'accesso diretto all'hardware e basta


il tuo la taglia con il borotalco, pare :)
... e il mio con i gessetti colorati... cancella tutto quello che ho
detto, erroraccio mio


ooops. Ri-ritratto ma con molta cautela: GDI e GUI si trovano nel
kernel, ma non fisicamente, cioè non in ntoskrnl.exe, quindi un modo per
disattivarle senza tuttavia compromettere il sistema c'è.


 sorgenti di un programma di grafica per DOS... magicamente, pochi mesi
[..]
Che m$ scopiazzasse qui e li' per non dover reinventar la ruota e che
cio' accade in molti dei loro prodotti lo si sapeva [1]
[1] Quel simpatico messaggio del TCP/IP che parla di Regents of
California la dice lunga..


 Windows NT derivi *unicamente* dal fatto che si faccia interagire l'user
No, il bello e' che non deriva solo da ma sicuramente _anche_
da questo


>il tuo la taglia con il borotalco, pare :)
^^^^
di chi e' sta roba, di qualche coglione nel mio killfile?


 disattivarle senza tuttavia compromettere il sistema c'č.
Ok allora, 1) qual'e' (e non dirmi boot.ini) perche' li disattivi ma li'
rimangono 2) ti risulta che qualcuno l'abbia mai fatto rinunciando alle
amate finestrine svulazzanti? Beh a me no..


 singola operazione sul bit...) e' di fatto irrilevante. Mentre invece
Non posso che essere d'accordo: nel caso del rendering nessuno se ne
accorgerebbe (a meno di avere gli occhi di un supereroe della Marvel
Comics) mentre nel secondo se ne accorge eccome.


 (disattivabile con modifica al boot.ini, se è questo a preoccuparti),
Uhm fammi pensare, questa storia del boot.ini la sapevo gia' ma a te
risulta che mettendo "Gui = 0" (o quel che era) cio' mi levi dal kernel
tutto quel pruppo inutile? No, in primo luogo, in secondo luogo questa
e' una cazzata perche' _NESSUNO_ lo farebbe mai (come infatti nessuno lo
fa) perche' l'utonto senza la rilassante visione della finestra che
svolazza si sente perduto.


 contrario altrimenti piantala.
Veramente da quel che ho capito lui non parlava di GUI, ma solo del driver
della scheda video e magari un piccolo supporto per la grafica, e neanch'io
capisco perchè darebbe più instabilità di un driver (ad es.) di una scheda
di rete.
Qualcuno mi puo' spiegare il motivo?
Grazie.


Una domanda a cui non ho trovato facile risposta... ma i driver cosiddetti
kernel-mode e gli *altri*... in cosa differiscono esattamente?
Ciao.

 Qualcuno mi puo' spiegare il motivo?
Forse perche' crashando la GUI (e di conseguenza l'ambiente grafico,
cosa che accade certo non raramente) puo' portarsi appresso l'intero
kernel?


 Una differenza di un milionesimo di seconod sulal videata
si, ma io intendevo la differenza di qualche istante sulla visualizzazione
di qualche comando di modifica di una foto o di una animazione.
Per una workstation che di queste cose fa il suo pane, mezzo istante qui, un
quarto li', considerando che un creativo spippola modificando tutto il santo
giorno, la differenza esiste, eccome.
Se vuoi fare una prova, usa un sw di disegno sulla stessa macchina con su
linux prma win o mac poi.
Apri una immagine *grande* e *complessa* e inizia a modificare: anche se non
sei un grafico, la differenza la scorgi ad occhio nudo.
Poi, magari la gui a livello kernel non c'entra una mazza, ma allora c'e'
qualcosa di altro che non funziona a dovere...
Ovviamente, se parliamo di server, il discorso non ha fondamento.
Saluti
Marco

 sei un grafico, la differenza la scorgi ad occhio nudo.
Come fai a fare di questi confronti? Dovresti mettere in mezzo anche le
considerazioni sull'HW sottostante: una scheda 3d sicuramente sarebbe
piu' veloce della mia schifida Virge Trio 64, e questo solo da PC a PC,
indipendentemente dall'OS, sia Uindous o Linux.


 considerazioni sull'HW sottostante
Ho detto infatti "sulla stessa macchina": a casa ho un PII 350 con win e
linux, e le differenze sono evidenti.
Da un apple center ho visto un ppc in dual boot e la solfa era la stessa. (E
MacOSX era lento pure lui)
Saluti
Marco

 MacOSX era lento pure lui)
Su Mac non mi pronuncio essendo totalmente ignorante..


 all'hardware...
e' questo il punto: non dubito che per un server che lavora a command line e
deve essere sempre on-line questa sia la soluzione corretta, ma per una wks
grafica *forse* vale la pena di avere i driver video a livello kernel.
Ripeto, magari il motivo di questa evidente disparita' di funzionamento non
e' quello, ma allora cosa e'?
Saluti
Marco

 e' quello, ma allora cosa e'?
Se c'e' una disparita' di funzionamento IHMO il motivo e' quello e basta
ma il punto non e' questo bensi' il fatto che se mi crasha l'ambiente
grafico mi porta con se' l'intero kernel e questo non mi pare un bene,
indipendentemente se e' un server (molto piu' grave) che una workstation
grafica.
BTW mi pare che stiamo girando sempre sulle stesse cose..


piattaforma decisamente migliore di NT grazie alla sua flessiblilita')
veramente Linux (kernel monolitico) punta alle prestazioni elevate,
Windows NT (microkernel) punta alla flessibilità. Che poi Linux sia
diventato un sistema distribuito in gran parte sotto forma di codice
sorgente (quindi flessibile), e Windows NT un'architettura, oltre che
closed source (che non sarebbe poi così grave), poco documentata (quindi
la flessibilità è stata castrata) e mirata alle prestazioni (grafica a
ring 0), dipende dalle "amicizie" a cui i due sistemi si sono
accompagnati


esattamente?
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=2984
Qui parla dell'architettura di Windows NT in particolare, ma spiega
anche la differenza tra kernel mode e user mode



Ok Grazie per il link.
Buona Pasqua a tutti.. prima che me ne dimentichi :-)
Ciao.

 BTW mi pare che stiamo girando sempre sulle stesse cose..
vero..
Saluti
Marco

 Pero` la GUI od X non sono "driver".
Eccerto che ce lo so :)
Mi riferisco proprio ai driver delle schede video, non alle librerie 
grafiche
-- 
balrog ):E...

 della scheda video e magari un piccolo supporto per la grafica
Si, parlavo proprio del driver.
-- 
balrog ):E...

stesso meno affidabile
Allorche', ho posto un po' di dubbi sul fatto che un driver, solo perche' 
quello della scheda video, debba esser tenuto fuori dal kernel. Anche 
perche', non so quanto sia facile fare un driver che lavora in user-mode.
Spero che se di equivoco si tratta, questo sia chiarito.
ciao
-- 
balrog ):E...

 perche', non so quanto sia facile fare un driver che lavora in user-mode.
Uffa' il discorso non e' tanto sulla scheda video e del suo driver ma di
tutto l'ambiente grafico in kernel space.


kernel?
Ma se la GUI non è nel kernel (ma solo i driver), non può certo fargli
danni. Per driver si intende soltanto un sistema che compia le
operazioni di base (come il cambio del modo video) e che si occupi di
gestire gli accessi alle risorse hardware da parte dei programmi in
user-space. Il resto (operazioni di blitting, rendering, triangolini e
altre amenità) deve essere eseguito da librerie che stanno in
user-space.
Se crasha un programma GUI, può crashare la GUI stessa e le sue
librerie, ma il kernel non se ne accorgerà nemmeno.
-- 
Saluti,
    Mardy

 gestire gli accessi alle risorse hardware da parte dei programmi in
Guarda che stai dicendo esattamente le stesse cose che vado dicendo
io: il probnlema non e' solo nella presenza del driver della sk video
ma di tutta la GUI in kernel space perche' se crasha quella si porta
dietro l'intero kernel e cio' e' una cosa _estremamente_ stupida.


 operazioni di base (come il cambio del modo video) e che si occupi di
[..]
Infatti io sto parlando di NT che ha la GUI nel kernel, non solo i 
driver della scheda video.


 driver della scheda video.
OK, fin qui allora siamo d'accordo, io intendevo un miglior interfacciamento
con la scheda video da parte del kernel, per la GUI son d'accordo che se ne
può stare fuori.

 può stare fuori.
Oh bene, allora finalmente sono riuscito a farmi capire, anche se con
l'interfacciamento del driver della sk video nel kernel bisognerebbe
IHMO prestare attenzione ma basta non fare come m$ e si e' a cavallo :)


 kernel-mode e gli *altri*... in cosa differiscono esattamente?
In che OS o che tipo di OS?
Ad occhio e croce direi che in Unix *tutti* i driver
sono in kernel mode.
Se per driver intendi un *pezzo* di SW che mostra all'utente
un interfaccia generica ed uniforme per differenti dispositivi
hardware.
In particolare quello che si trova in /dev/... :-)
In un microkernel, invece, direi che quasi tutti i driver
sono in user space, ma anche questo e` un po' dipendente
dalle definizioni di uK.
bye,
-- 
  Piergiorgio Sartor

 grafiche
Come ho scritto il driver NVidia e` un modulo kernel,
in Linux, cosi` come l'agpgart, quindi sono in kernel space.
Versioni precedenti di X avevano il "driver" integrato,
il quale funzionava usando /dev/mem, se non vado errato,
il che equivale a dire che erano in kernel space :-)
Credo che il problema sia con win in cui tutta la
grafica e` in kernel space: driver, GUI, etc.
Il che implica minore stabilita` (una GUI e` un
macello di malloc/free ed object handling), con
il vantaggio di avere (forse) maggiore velocita`.
Il "forse" sta nel fatto che con le CPU di oggi e con
il bus AGP dubito si senta tanta differenza con un
kernel switch in piu` od in meno... :-)
bye,
-- 
  Piergiorgio Sartor

sono in kernel mode.
Non necessariamente.
Quelli dei file system solitamente si`.
Quello della stampante no, quello della porta parallela si`.
Quello del mouse no, quello della porta seriale si`.
Quello della scheda video dipende, con XFree86 4 e i kernel 2.4 ce n'e`
un pezzetto.
Il toolkit grafico naturalmente no. :-)
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

Come ho scritto il driver NVidia e` un modulo kernel,
Non tutto il driver, solo il pezzetto che parla direttamente con
l'hardware e gestisce gli interrupt, cosa che in user space non si puo`
fare.


 Oh bene, allora finalmente sono riuscito a farmi capire...
Diciamo che ti eri spiegato un pochino maluccio :-))

 fare.
600KB (contro un kernel di 400KB) di modulo sono un interrupt handler?
Mi sembra alquanto strano...
bye,
-- 
  Piergiorgio Sartor

 Il toolkit grafico naturalmente no. :-)
Ovviamente...
bye,
-- 
  Piergiorgio Sartor

 Diciamo che ti eri spiegato un pochino maluccio :-))
Diciamo che qualcuno non ha neanche letto bene cio' che ho scritto,
perche' di NT con GUI in kernel space qui si parla da tempo immemore
<g>


Quello (della stampante) non e` un driver... :-)
Per windows si`.


600KB (contro un kernel di 400KB) di modulo sono un interrupt handler?
OK, non ho mai visto il driver in questione e supponevo che fosse fatto
come gli altri inclusi nel kernel...



Mah pensavo che la definizione riguardasse solo windows NT. In ogni caso se
vi sono analoghi in unix/linux... fammi sapere (grazie anticipatamente)
Ciao.

 Per windows si`.
Si, ma io scrivevo per Unix... Cioe` in Unix *direi*
che i driver sono in kernel space sempre.
In particolare "gpm" (responsabile di /dev/gpmdata e /dev/gpmctl)
e` definito come "mouse server".
"lpd" (responsabile di /dev/printer & affini) e` definito
come "printer daemon".
Direi che per dare una risposta esatta si debba avere
una stessa definizione di:
driver
server
daemon
Secondo me valgono i seguenti concetti:
"daemon" e` un programma che gira *per conto suo* ed e`
responsabile di alcune funzioni di *mantenimento*
del sistema (ad es. crond).
"server" e` daemon che offre dei servizi *esterni*
(ad es. ftpd).
"driver" e` un pezzo SW che si occupa di fornire un'interfaccia
uniforme e coerente per dispositivi HW.
Il che implica ad es. che debba essere sempre in grado di
gestire interrupt (fisici o virtuali), quindi ad occhio e croce
implica che sia in kernel space (per Unix, ovviamente).
Queste sono mie definizioni, se qualcuno volesse aggiungerci o
modificare qualcosa e` naturalmente benvenuto.
bye,
-- 
  Piergiorgio Sartor

uniforme e coerente per dispositivi HW.
Quindi sia gpm che ghostscript sono driver.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 Quindi sia gpm che ghostscript sono driver.
Dipende, non credo forniscano un'interfaccia coerente ed uniforme,
ma specifica.
D'altro canto serve definire a sua volta "coerente" ed "uniforme".
In generale, essendo gpm un "mouse server", non e` un driver.
C'e` da chiedersi se un pezzo di software che offre servizi
su socket possa essere un driver, oppure un servizio costruito
sopra ad un driver (e magari indistinguibile).
In particolare gpm potrebbe usare il serial driver ed
offire servizi in maniera trasparente e quindi essere
assimilato ad un driver...
D'altro canto tutto potrebbe essere a sua volta un
"driver", cioe` tutto il kernel con le infrastrutture
esterne, quali X e roba tipo GNOME.
Ad es. xft puo` cadere nella definizione di driver,
pur essendo un "font server".
Io prefirei distinguere tra server, daemon e driver.
bye,
-- 
  Piergiorgio Sartor

 monolitico e microkernel (NT e` uK).
NT non e` microkerenel... sono tutte bufale inventate dalle
"sapienti e tecnike) riviste informatiche nel 1996...
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://www.quasarbbs.net/mircomir/
 ]

tecnike) riviste informatiche nel 1996...
Uh ? Dove posso trovare piu' info ?
-- 
Giambonini Gabriele           Teamup AG
Software Engineer             Industriestrasse 15
                              5242 Lupfig
+41 56 464 46 05
              Switzerland

 "sapienti e tecnike) riviste informatiche nel 1996...
NT e` uK per affermazione di M$ stessa, direi.
Esistono documenti della casa stessa dove "vantano"
questo fatto (ma non chiedere dove :-)).
Da quello che so, il kernel base (il core) e` stato
acquistato da un'altra ditta (o forse tutta la ditta
fu acquistata da M$).
Su questo nucleo fu costruito NT cosi come lo conosciamo adesso.
bye,
-- 
  Piergiorgio Sartor

ma specifica.
gpm fornisce una API indipendente dall'hardware attraverso /dev/gpmdata,
ghostscript converte postscript e pdf nei formati stampabili dalle
stampanti.



:-) Mi ricorda il mitico config.sys del DOS (e anche di win9x :-( ) che
caricava appunto i driver della tastiera keyboard.sys per esempio, e altre
cose... finchè non ho scoperto che una classe cospicua di drivers si poteva
caricare anche dinamicamente con il comando DEVICE fornito con il qemm o
programmi simili, equiparandoli agli altri TSR.
In ogni caso... la faccenda si complica allora... mi piacerebbe avere un
chiarimento ulteriore. TUTTI i driver sono o in user o in kernel? Mi sembra
di no, ma non vorrei dire panzane... cioè in NT i driver AGP, quelli della
scheda video, quelli della scheda sonora sono in kernel-mode. Ma gli altri?
Stampante, per esempio...
Ciao.

 stampanti.
Dunque ghostscript converte postscript in formati stampabili.
Un software che fa questo si chiama "compilatore", non e`
un driver, ne` un daemon e nemmeno un server.
Non so cosa fornisca gpm, ma in generale direi che non e`
compito del driver manipolare i dati del dispositivo HW.
Cioe` il driver fornisce i dati cosi` come sono senza
nessun processamento ulteriore, solo l'interfaccia e` astratta.
Il daemon od il server (od il compilatore) prendono i dati
"raw" e li convertono i qualcosa di utile e "specifico".
Potrei immaginare che il driver ethernet fornisca i pacchetti
cosi` come arrivano alla scheda, spetta poi ai "moduli"
specifici (IP, TCP, UDP, etc.) "spacchettarsi" i dati.
Questi moduli non fanno parte, secondo me, del driver.
Certo interfacce come USB o PCMCIA complicano la vita
(ed i concetti) ulteriormente.
Ad es. una scheda PCMCIA potrebbe avere un interfaccia USB
alla quale e` connesso un disco SCSI...
Per mantenere il sistema coerente non e` il caso di
fornire un unico driver PCMCIA -> SCSI, ma si passera`
per tutti i livelli, cioe` PCMCIA -> X, X -> USB,
USB -> Y, Y -> SCSI.
Con successive manipolazioni di dati da parte del driver.
Pero` l'astrazione delle interfacce e l'uniformita`
rimangono tali anche in questo caso.
bye,
-- 
  Piergiorgio Sartor

 Stampante, per esempio...
Per prima cosa devi definire cosa intendi per "driver".
"driver" e` quello che il produttore (Microsoft) ti dice
essere un driver od un concetto ben formato che, magari,
chiariremo in seguito?
Dove stiano questi oggetti dipende dall'architettura.
Non conosco NT cosi` a fondo da poter dire se i driver (?)
stiano in kernel, user od entrambi gli spazi.
Sempre d'Itri sottolinea che per gestire gli interrupt
(in Unix) si debba essere in kernel space.
In uK non e` piu` necessario.
Ci potrei aggiugere che un driver *per definizione* DEVE
gestire almeno un interrupt (fisico o virtuale).
Dato questo per vero, se in NT e` possibile avere
interrupt handler in user space (in kernel e` sicuramente
possibile) allora i driver possono essere anche in
user space (che e` quello che succede con i uK).
Questo apre la porta a tutta una serie di considerazioni
su cosa voglia dire "gestire un interrupt", pero` :-)
In particolare quale livello di "intelligenza" venga
dato all'interrupt handler...
bye,
-- 
  Piergiorgio Sartor

 un driver, ne` un daemon e nemmeno un server.
Non ho il dizionario informatico sottomano, ma credo che tu stia
estendendo un po' troppo il significato di "compilatore". E comunque, il
fatto che ghostscript possa essere un compilatore non significa che non
sia ANCHE un driver.
Driver vuol dire semplicemente "pilota". Ogni pezzo di sw che governa un
pezzo di HW è definibile come driver. Tutti i drivers per le stampanti
convertono dati in dati stampabili, e secondo la tua definizione ogni
driver per stampante è un compilatore, e siccome tu affermi che se è un
compilatore non può essere un driver si arriva all'assurdo che secondo la
tua definizione un driver per stampante non è un driver, il che invalida
la tua definizione.
Ora decici: o un driver per stampante non è un compilatore, oppure le due
cose non sono mutualmente esclusive. In entrambi i casi viene a cadere il
senso del tuo post...
Scusa, ma questa precisazione logica era doverosa :)
Fabio Alemagna

 Scusa, ma questa precisazione logica era doverosa :)
Non vedo alcuna logica in questa precisazione, se non confusione
di termini tra "filtri" e "driver".
Altrimenti anche la "bash" e` un driver, oppure X, oppure word.
Persino gcc e` un driver, dato che prende un file di testo e
lo rende "eseguibile" da una CPU: e` un driver per CPU.
bye,
-- 
  Piergiorgio Sartor

gestire almeno un interrupt (fisico o virtuale).
Un aggiunta decisamente arbitraria. Non tutti i device usano un IRQ.
Pensa alle schede sonore, per esempio: la vetusta sb poteva usare un IRQ
(ed era fortemente consigliato), ma non era affatto necessario.
Dell'hardware di oggi sono ignorante, ma non trovo che il concetto di un
dispositivo hardware privo di IRQ sia inconcepibile.
-- 
Saluti,
    Mardy

 dispositivo hardware privo di IRQ sia inconcepibile.
Aggiungerei anche i drivers della Voodoo2 . Come quelli delle prime matrox.
Saluti

Piergiorgio Sartor esternò:
 >E` il driver fornito dalla NVidia stessa, che sta facendo
 >un discreto lavoro per Linux & XFree.
Bene.
 >Il driver e` fornito in *binario* piu` un pezzo sorgente ...
Male.
--
Au revoir.
Lele...

potrebbe andare bene?
Sě, io l'ho sempre intesa cosě. 
-- 
Saluti,
    Mardy

 dispositivo hardware privo di IRQ sia inconcepibile.
Rispondo ora, perche` leggo ora :-)
Se rileggi bene quello che ho scritto, troverai:
"...interrupt (fisico o virtuale)".
Non e` necessario che la scheda sia collegata con un filo ad
un IRQ fisico, per essere interrupt driven.
Ad es. un task puo` far polling e generare un evento che, di fatto,
e` un interrupt.
Oppure si puo` usare la tecnica interrupt del DOS, in cui i
vari driver erano (sono?) attivati anche da interrupt SW, a
seconda di cosa erano responsabili.
bye,
-- 
  Piergiorgio Sartor

 un IRQ fisico, per essere interrupt driven.
Aggiungo: non e' necessario utilizzare piu' di un filo per gestire piu' 
dispositivi.
-- 
balrog ):E...

 dispositivi.
:-)
Ma questo e` gia` advanced hardware :-), non roba per PC :-)
bye,
-- 
  Piergiorgio Sartor