Newsgroup: it.comp.os.dibattiti
Titolo: La grafica dove la metto?

ar...@logic.it
 wrote:
 >Mi confermi, dunque, che Linux resta sempre tutto in kernel space?
Tutto cosa? In kernel space gira il minimo indispensabile, cose come
le schede grafiche, gli scanner, il mouse, le stampanti eccetera hanno
"driver" che girano in user space.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | "You're one of those condescending Unix computer users!"
<<<>>>| "Here's a nickel, kid. Get yourself a better computer" -- Dilbert

"driver" che girano in user space.
Mi sa che quelle virgolette nascondono qualcosa... ;-))
L'accesso all'hardware non è fatto in modo supervisore (kernel, o come
vuoi chiamarlo)?
Bye,
  Dario
Fidonet 2:331/101.25
ICQ# 11871099

ar...@logic.it
 wrote:
 >> >Mi confermi, dunque, che Linux resta sempre tutto in kernel space?
 >>Tutto cosa? In kernel space gira il minimo indispensabile
 >Be', se fosse davvero il minimo indispensabile, sarebbe un microK! ;-)
Dipende dal tuo concetto di indispensabile. E` tutta una questione di
trade off, e quelli di linux mi sembrano perfettamente accettabili.
Non ho mai ben capito che me ne faccio di avere il driver del file
system che gira in user space, tanto se si pianta quello il resto dei
programmi mica continua a funzionare...
 >>cose come
 >>le schede grafiche, gli scanner, il mouse, le stampanti eccetera hanno
 >>"driver" che girano in user space.
 >Mi sa che quelle virgolette nascondono qualcosa... ;-))
Solo il fatto che si tratta di normali processi, e quindi non e`
corretto chiamarli driver.
 >L'accesso all'hardware non è fatto in modo supervisore (kernel, o come
 >vuoi chiamarlo)?
No. Il programma (che gira con i permessi opportuni) dice al kernel:
"ioperm(unsigned  long  from,  unsigned  long num, int turn_on);",
il kernel gli risponde 0 e il programma puo` iniziare a usare in e out
secondo necessita`.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

da processi in user space.
Sembrerebbe percio' che a differenza di NT, che gestisce i driver dei
dispositivi
grafici in modalità Kernel ("per semplificare l'accesso alla grafica, per
ridurre le richieste di memoria e
per aumentare le prestazioni." cosi' dice Microsoft), Unix e Linux fanno
girare tali driver in modalità utente.
Risultato: un driver grafico mal costruito può far bloccare NT, ma ne' Unix
ne' Linux? In questi al massimo si blocca l'applicazione?
Roberto B.

bergon...@mail.aitec.it
 wrote:
 >per aumentare le prestazioni." cosi' dice Microsoft), Unix e Linux fanno
 >girare tali driver in modalità utente.
Dipende dai driver, alcuni devono girare in kernel space o per motivi di
prestazioni o perche` altrimenti non potrebbero arbitrare l'accesso
all'hardware.
 >Risultato: un driver grafico mal costruito può far bloccare NT, ma ne' Unix
 >ne' Linux? In questi al massimo si blocca l'applicazione?
Esatto. Sempre che la scheda grafica non si appropri del bus e quindi
blocchi la macchina senza speranza.


In questi al massimo si blocca l'applicazione?
Tutte quelle grafiche.


'grafica localizzata' e saturano meno la banda  :-)))
Questo č verissimo.


secondo necessita`.
'Spetta che 'sta cosa mi interessa e la voglio approfondire. Facciamo
un passo alla volta: cosa impedisce ad un'applicazione di fare
direttamente I/O senza chiedere il permesso?


ar...@logic.it
 wrote:
 >in user space. Le particolarità di Linux, soprattuto degli ultimi
 >anni, non le conosco; so, però, che Unix è nato come un blocco unico,
 >in cui era tutto nel kernel.
*No*. Kernel monolitico NON significa quello.


ar...@logic.it
 wrote:
 >>Non ho mai ben capito che me ne faccio di avere il driver del file
 >>system che gira in user space, tanto se si pianta quello il resto dei
 >>programmi mica continua a funzionare...
 >- facilità nel porting (adegui solo il kernel, il "driver" del FS lo
 >lasci com'è)
 >- puoi mettere e togliere FS a piacimento
Sono due cose fattibili indifferentemente che il driver giri in user
space o in kernel space. Proprio ti assicuro che non cambia nulla.
 >>No. Il programma (che gira con i permessi opportuni) dice al kernel:
 >>"ioperm(unsigned  long  from,  unsigned  long num, int turn_on);",
 >>il kernel gli risponde 0 e il programma puo` iniziare a usare in e out
 >>secondo necessita`.
 >'Spetta che 'sta cosa mi interessa e la voglio approfondire. Facciamo
 >un passo alla volta: cosa impedisce ad un'applicazione di fare
 >direttamente I/O senza chiedere il permesso?
Il bitmap di permessi che il processore consulta per ogni processo.
Naturalmente ioperm puo` essere usato solo se il programma gira con
UID=root o possiede la capability relativa.


*No*. Kernel monolitico NON significa quello.
Vabe', ma se dicessi subito quello che hai da dire non faremmo prima?
:)


UID=root o possiede la capability relativa.
Quindi diciamo che comunque sono programmi privilegiati, giusto?


ar...@logic.it
 wrote:
 >> >- facilità nel porting (adegui solo il kernel, il "driver" del FS lo
 >> >lasci com'è)
 >> >- puoi mettere e togliere FS a piacimento
 >>Sono due cose fattibili indifferentemente che il driver giri in user
 >>space o in kernel space. Proprio ti assicuro che non cambia nulla.
 >Per il primo si può discutere quanto sia la quantità di codice da
 >cambiare, ma dovrebbe essere sicuramente minore.
Non e` vero. Puoi avere driver non portabili su un OS a microkernel e
viceversa.
 >Per la seconda mi pare che non ci sia proprio storia: se il FS è
 >compilato dentro all'OS, c'hai poco da cambiare.
Linux e` monolitico eppure si possono caricare e scaricare dinamicamente
e automaticamente tutti i driver.
 >E dopo che l'ha consultata? Voglio dire: facciamo il caso di dove
 >scrivere un byte su una porta mappata in RAM; se un programma chiede
 >il permesso, può accedere direttamente a quella locazione di memoria?
Le porte memory mapped su IA32 non sono gestite dal processore e quindi
si tratta della normale protezione della memoria. In ogni caso si accede
alle porte tramite una macro in modo da non essere dipendenti dal tipo
di architettura (es: alcuni sistemi hanno porte solo memory mapped
gestite direttamente dal chipset e nessuna istruzione IN e OUT).
 >Mi pare una cosa piuttosto brutta!
Tu hai idee migliori? Se un programma deve accedere all'hardware o lo
fa direttamente o lo fa attraverso un driver in kernel space che crea
uno strato di astrazione.
 >>Naturalmente ioperm puo` essere usato solo se il programma gira con
 >>UID=root o possiede la capability relativa.
 >Quindi diciamo che comunque sono programmi privilegiati, giusto?
Certo, un normale processo di un utente non puo` accedere direttamente
all'hardware.


all'hardware.
Questo va sicuramente nella direzione del microK: l'applicativo
comunica attraverso il kernel con un altro processo in user space in
grado di fornire il servizio. Solo che quest'ultimo dovrebbe poi
utilizzare ancora il mircoK per accedere all'HW... ;-)


ar...@logic.it
 wrote:
 >Se usiamo questa "definizione", è palese che un driver ha portabilità
 >0 poichè dipende strettamente dall'HW sottostante.
Non e` affatto palese, per esempio i driver delle schede PCI di linux
sono tra la roba comune e funzionano su tutte le architetture che
hanno PCI. Idem per altri tipi di dispositivi (seriali, parallele,
schede video (che non sono nel kernel), eccetera).
 >restano comunque portabilissime. Se però mantieni il FS come processo
 >"utente" a parte, è impossibile che tu vada ad utilizzare chiamate
 >"sporche", cosa che potrebbe succedere in ambiente tutto kernel (e
 >quindi ci guadagna la portabilità).
E` impossibile anche se te lo vieti tu. Non mi pare una grande
argomentazione questa.
 >Si, il link dinamico dei moduli è un espediente alternativo, ma è una
 >soluzione meno elegante e pulita del microK: in sostanza sono pezzi di
No, e` una soluzione /diversa/. E` semplicemente un modo per caricare
e scaricare dinamicamente pezzi di codice senza tenerli in memoria
per tutto il tempo.
 >Adesso non mi ricordo più cosa puoi mettere in modulo sotto Linux:
 >puoi farlo anche con i file systems?
Certo. Lo puoi fare con qualsiasi cosa puoi mettere nel kernel.
 >>Le porte memory mapped su IA32 non sono gestite dal processore e quindi
 >>si tratta della normale protezione della memoria.
 >Appunto: è questo che mi lascia perplesso... Cosa succede? Si cambia
 >lo spazio di indirizzamento di un processo al volo?? Come fa il
Non capisco. Lo spazio di indirizzamento e` separato per ogni processo.
 >processo a indirizzare in modo corretto, se il suo spazio cambia? I
Esistono delle strutture gestite dal processore, i dettagli li trovi
sui libri di intel.
 >processi su Linux dovrebbero avere un indirizzamento lineare, no?
Certo.
 >>Certo, un normale processo di un utente non puo` accedere direttamente
 >>all'hardware.
 >Questo va sicuramente nella direzione del microK: l'applicativo
No, questa e` semplicemente protezione della memoria e dei processi.


Non capisco. Lo spazio di indirizzamento e` separato per ogni processo.
Si, non facciamo confusione: questa è un'altra faccenda. Vedo di
spiegarmi meglio... Facciamo il caso che la porta in questione è
all'indirizzo fisico 100; un programma che viene caricato e avviato,
se ne sbatte e vede tutti i 32 bit di indirizzamento in modo lineare
tutti per lui (poi saranno mappati sulle varie pagine fisiche/swappate
dall'OS): questo vuol dire che per il programma l'indirizzo 100
(logico) corrisponderà ad un indirizzo fisico che (solo) l'OS sa
qual'è ma che comunque non corrisponde alla porta; perchè il programma
possa accedere alla porta, occore rimappare l'indirizzamento logico su
quello fisico, in modo che l'indirizzo 100 per il programma
corrisponda esattamente all'indirizzo fisico 100 e consentirgli
l'accesso solo a quell'indirizzo (già non so se si possa lavorare sul
singolo byte)... Insomma: un gran casino! ;-)
Se invece usi il kernel mode, dove l'indirizzamento fisico è
visibilissimo, tutto 'sto macello (non so nemmeno se fattibile) non
serve.


ar...@logic.it
 wrote:
 >> >Se usiamo questa "definizione", è palese che un driver ha portabilità
 >> >0 poichè dipende strettamente dall'HW sottostante.
 >>Non e` affatto palese
 >Argh! E come fanno? Sei hai hw diverso da astrarre, dovrai pur farlo
 >in modo diverso, no? ;-)
Una scheda di rete rimane sempre la stessa che stia in un PC o in un
mac. L'hardware e` lo stesso.
 >>per esempio i driver delle schede PCI di linux
 >>sono tra la roba comune e funzionano su tutte le architetture che
 >>hanno PCI
 >No, non ho mica capito. Cosa vuol dire che sono "tra la roba comune"?
Tra quella scritta solo in C e che non ha parti dipendenti
dall'architettura (cioe` tutto quanto non sta in /usr/src/linux/arch/).
 >E poi non fai altro che dire che dipende dalla scheda grafica: se la
 >cambi, cambi driver... Non vedo la contraddizione...
Non capisco.
 >Non ho ben capito a cosa tu ti stia riferendo, così faccio un esempio
 >io: per poter utilizzare un tipo di CD o un altro (IDE, SB, altra
 >marca) devi compilare il kernel in modo adeguato.
Posso anche usare un kernel con i vari moduli e caricare automaticamente
e/o dinamicamente quello che serve a seconda dell'hardware installato.
Le distribuzioni migliori lo fanno senza problemi.
 >Si, ho capito, ma è come dire che puoi programmare ad oggetti in ASM:
 >fattibilissimo, ma un po' scomodo e rischioso, no? ;-)
E` un paragone senza senso.
 >quello fisico, in modo che l'indirizzo 100 per il programma
 >corrisponda esattamente all'indirizzo fisico 100 e consentirgli
 >l'accesso solo a quell'indirizzo (già non so se si possa lavorare sul
 >singolo byte)... Insomma: un gran casino! ;-)
Il processo "driver" (perche` se deve accedere a delle porte si tratta
di questo, anche se non sta nel kernel) riesce a trovare dove stanno le
porte facendo dell'autoprobe, chiedendolo al bus PCI o leggendolo nella
propria configurazione.


propria configurazione.
No, non ci siamo proprio capiti: il problema che sollevo non è quello
di trovare un indirizzo di una porta, ma quello di accedere ad un
indirizzo fuori dal proprio indirizzamento...
Se vuoi provo con un'altro esempio...


ar...@logic.it
 wrote:
 >Bah... Mi pare proprio che stai dicendo quello che dico io... Mi sa
 >che non ci capiamo... Se l'HW non cambia -> non cambi driver; se cambi
 >l'HW -> cambi il driver. Non stiamo dicendo la stess cosa?
Mi sembrava che dicessi che il driver e` dipendente anche dalla
architettura hardware.
 >finchè non servono (ripeto: vedi overlay); nei microK non sono pezzi
 >di kernel che vengono caricati all'occorrenza, ma veri e propri
 >normali processi, con il loro spazio di indirizzamento e tutto il
 >resto.
Si, e a causa di questo si paga un forte prezzo di velocita`. Bisogna
decidere oltre quale punto non e` piu` conveniente spostare un servizio
in user space, e IMHO i microkernel sono troppo in la`.
 >No, non ci siamo proprio capiti: il problema che sollevo non è quello
 >di trovare un indirizzo di una porta, ma quello di accedere ad un
 >indirizzo fuori dal proprio indirizzamento...
E` chiaro, non si puo`. Il kernel deve provvedere a rendere disponibile
al driver in user space i servizi di cui ha bisogno.
 >Se vuoi provo con un'altro esempio...
E` meglio.


E` meglio.
Be', mi pare che ci siamo... L'istruzione ASM che fa la write sulla
porta, dovrebbe essere all'interno del kernel, con processore in
modalità k.


ar...@logic.it
 wrote:
 >In quest'ottica andrebbe anche valutata la scelta di MS per quanto
 >riguarda i driver video di NT, fermo restando che un server dovrebbe
 >fare il serve e basta.
Gia` fatto, e la risposta e` che in kernel space deve esserci solo
il minimo indispensabile necessario ad arbitrare l'accesso alle porte,
non i toolkit che disegnano le finestre e nemmeno il driver video a
basso livello.
 >le modalità richieste dal processo. Se questo è quello che accade,
 >allora non è il processo ad accedere alla porta, ma il kernel (cioè
 >con il processore in modalità kernel).
No. Quando l'hardware fornisce porte memory mapped il kernel si limita
a permettere al processo di scrivere in quella zona di memoria, che
comunque e` gia` parte dello spazio di indirizzamento di tutti i processi
(ma normalmente e` protetta in lettura e scrittura).
 >Be', mi pare che ci siamo... L'istruzione ASM che fa la write sulla
 >porta, dovrebbe essere all'interno del kernel, con processore in
 >modalità k.
No. Questo e` ancora piu` semplice: il processo chiede al kernel con
iopl(2) o ioperm(3) di scrivere nel bitmap di protezione specifico del
processo che quelle porte sono accessibili. Le in/out vengono comunque
fatte dal processo.


(ma normalmente e` protetta in lettura e scrittura).
Riesci sempre a stupirmi! ;-))) Come sarebbe a dire che le porte fanno
già parte dello spazio di indirizzamento di tutti i processi? Vuoi
dire che quando scrivi un programma su Linux c'è una zona di memoria
che sai già essere il mapping di tutte le vaire porte? Allora non è un
indirizzamento lineare ma c'è un buco da qualche parte...
Esempio: se devo scrivere sulla parallela, cosa devo fare?


Esempio: se devo scrivere sulla parallela, cosa devo fare?
Usare un pennarello.
Saluti,
Francesco

ar...@logic.it
 wrote:
 >Argh... Ogni volta una notizia diversa... ;-) Dunque, se il kernel ti
Piu` o meno abbiamo scritto la stessa cosa, non so bene se la pagina
con dentro le porte MM e` nello spazio del processo gia` da subito o
solo dopo che viene caricato il kernel driver ma questo fatto non e`
significativo ai fini di questa discussione.
 >rimappa l'indirizzo fisico e tu accedi ad un nuovo indirizzo
 >fittizzio, vuol dire che una scrittura sul secondo viene ripetuta su
 >quello fisico dal kernel stesso...
Dario, a questo punto io sospetto che tu non sappia come funziona una
MMU. Se dico alla MMU di rendere disponibile a un certo indirizzo logico
una pagina (che in questo caso contiene i registri MM) allora questa
e` vera memoria assolutamente uguale a tutta l'altra memoria usata dal
programma (anche questa mappata dalla MMU dove necessario).


MMU.
Secondo me non ci capiamo perchè io non sto dicendo che il problema è
nella MMU, ma in quello che un processo si aspetta di trovare ad un
certo indirizzo.
Ho capito il tuo discorso sulla MMU, niente di nuovo. Spero di non
stancarti troppo... ;-) (se ti va di piantarla, fa pure).
Cerco di farti capire cosa intendo.
Innanzitutto chiariamo che sto ragionando a livello di codice
macchina: se tutti i processi sanno che ad un certo indirizzo ci sono
le porte, allora ho capito come funziona la cosa; vuol dire che lo
spazio delle porte è una zona di memoria fisica condivisa da tutti i
processi e gli accessi sono governati dalla MMU. Però mi resta un
dubbio un po' grossetto... La MMU degli x86 arriva a stabilire i
permessi di accesso fino al singolo byte (o eventualmente bit)?
Io, però, sapevo la cosa in modo un po' diverso: tutti i processi
hanno uno spazio di indirizzamento da 0 a 2^32 tutto per loro; non ci
sono buchi per le porte, possono indirizzare dove vogliono per mettere
i loro dati. Questo significa che non possono accedere direttamente
alle porte, perchè sono fuori dal loro spazio di inirizzamento: in
pratica non le vedono proprio. Per fare un'operazione di I/O il
processo chiede un servizio all'OS, il quale si occuperà di fare
l'accesso ad una zona di memoria che lui vede (quella della porta) e
poi restituirà il risultato. Questo avviene in modo kernel.
Non so, tu che dici?


ar...@logic.it
 wrote:
 >macchina: se tutti i processi sanno che ad un certo indirizzo ci sono
 >le porte, allora ho capito come funziona la cosa; vuol dire che lo
Lo sanno perche` e` scritto nella loro configurazione, l'indirizzo
dipende dalle singole schede.
 >spazio delle porte è una zona di memoria fisica condivisa da tutti i
 >processi e gli accessi sono governati dalla MMU. Però mi resta un
Si, la memoria fisica e` completamente mappata nello spazio di
indirizzamento di ogni processo.
 >dubbio un po' grossetto... La MMU degli x86 arriva a stabilire i
 >permessi di accesso fino al singolo byte (o eventualmente bit)?
Naturalmente no, e` per pagina.
 >Io, però, sapevo la cosa in modo un po' diverso: tutti i processi
 >hanno uno spazio di indirizzamento da 0 a 2^32 tutto per loro; non ci
 >sono buchi per le porte, possono indirizzare dove vogliono per mettere
 >i loro dati. Questo significa che non possono accedere direttamente
Proprio no. In linux (salvo modifiche fatte in casa per scopi
particolari) ogni processo ha 2 GB user space piu` 2 GB di kernel
space.
 >alle porte, perchè sono fuori dal loro spazio di inirizzamento: in
 >pratica non le vedono proprio. Per fare un'operazione di I/O il
No, sono dentro perche` come ho scritto tutta la memoria fisica e`
mappata (ma non per questo e` accessibile).
 >processo chiede un servizio all'OS, il quale si occuperà di fare
 >l'accesso ad una zona di memoria che lui vede (quella della porta) e
 >poi restituirà il risultato. Questo avviene in modo kernel.
Questo puo` succedere, ma allora si tratta di un driver in kernel
space che non e` quello di cui stiamo parlando.


space che non e` quello di cui stiamo parlando.
Infatti è proprio per quello che a me era venuto il dubbio di come
potesse funzionare un driver non in kernel. Sono contento di aver
scoperto qualcosa in più! ;-)


ar...@logic.it
 wrote:
 >Ecco: qui rimane l'unico inghippo... Se concedi l'accesso a tutta una
 >pagina, implictamente dai l'accesso a tutte le porta mappate lě
 >dentro... Quindi il controllo non č fatto sulla singola porta ma a
 >gruppi, giusto?
Si, ma non ci sono problemi, non vedo perche` voler dare accesso solo
ad alcune delle porte di una scheda. Di sicuro ogni dispositivo
mappera` le sue porte in una pagina diversa.


ar...@logic.it
 wrote:
 >Non sono mica tanto d'accordo... Metti che io ho due periferiche
 >diverse attaccate alle due seriali: gli indirizzi sono vicini (penso
 >nella stessa pagina, no?) e potrei benissimo farli governare da due
 >driver diversi...
Le seriali non hanno porte mmapped quindi il problema non si pone.
Inoltre le seriali hanno gia` un proprio driver in kernel space.
So che alcune architetture (MIPS, forse AXP) hanno tutte le porte
mmapped, quindi esiste una soluzione.


mmapped, quindi esiste una soluzione.
Sai mica quale?


ar...@logic.it
 wrote:
 >>Le seriali non hanno porte mmapped quindi il problema non si pone.
 >ARGH! :-D Sei sempre una fonte inesauribile di sorprese! ;-)) Come
 >sarebbe a dire che le seriali non sono mappate in memoria? 3F8 e 2F8
 >non ti dico niente? ;-)
Certo: sono gli indirizzi di I/O di base delle prime due seriali e
infatti non sono memory mapped (almeno su i386). Se fossero indirizzi
di memoria sarebbero sopra la IDT, e sarebbe abbastanza strano...
 >>So che alcune architetture (MIPS, forse AXP) hanno tutte le porte
 >>mmapped, quindi esiste una soluzione.
 >Sai mica quale?
No. Iscriviti a linux-kernel(a)
vger.rutgers.edu
 e chiedi li`.


di memoria sarebbero sopra la IDT, e sarebbe abbastanza strano...
Non vedo perchč... I device puoi mapparli all'indirizzo che ti pare...
(IDT= Interrupt <qualcosa> Table?)


ar...@logic.it
 wrote:
 
 >>Certo: sono gli indirizzi di I/O di base delle prime due seriali e
 >>infatti non sono memory mapped (almeno su i386).
 >AFAIK (e credo di avere un certo margine di sicurezza) questa tua
 >affermazione č contraddittoria...
In che modo? Non potresti studiare un po' come funziona un PC invece che
portare avanti per settimane una discussione cosi`? Perderemmo entrambi
meno tempo.
 >>Se fossero indirizzi
 >>di memoria sarebbero sopra la IDT, e sarebbe abbastanza strano...
 >Non vedo perchč... I device puoi mapparli all'indirizzo che ti pare...
Se 3F8 e 2F8 fossero indirizzi di memoria allora le porte sarebbero
sopra la IDT. Se sono semplicemente il numero della porta a cui accedere
con IN e OUT (come infatti e`) non ci sarebbero problemi.


con IN e OUT (come infatti e`) non ci sarebbero problemi.
Se usi IN e OUT (operazioni per la memoria), stai usando device
mappati... Ho controllato adesso e ho letto che quegli indirizzi sono
decodificati dal BUS, quindi il processore ci accede come normali zone
di RAM.
Mi pare che anche tu dica che non usa operazioni o registri
appositi...


ar...@logic.it
 wrote:
 >> >>Certo: sono gli indirizzi di I/O di base delle prime due seriali e
 >> >>infatti non sono memory mapped (almeno su i386).
 >> >AFAIK (e credo di avere un certo margine di sicurezza) questa tua
 >> >affermazione è contraddittoria...
 >>In che modo?
 >Semplice: se hai indirizzi di I/O, vuol dire che sono dispositivi
 >mappati in memoria, quasi tautologico!
Ripeto: Dario, perche` non lo ammetti che non sai nulla su come e` fatto
un PC? Non e` una vergogna...
Se hai indirizzi di IO allora NON avrai accesso tramite la memoria.
Altrimenti avresti dei puntatori alla ram da usare con MOV e non degli
indirizzi da usare con IN e OUT.
 >Se usi IN e OUT (operazioni per la memoria), stai usando device
 >mappati... Ho controllato adesso e ho letto che quegli indirizzi sono
 >decodificati dal BUS, quindi il processore ci accede come normali zone
 >di RAM.
No. Non so cosa hai controllato e/o capito, ma:
1) e` ovvio che qualunque cosa comunichi con l'esterno usi un bus
2) il fatto che venga usato un bus non implica che si acceda alla ram.
Ripeto: Se 3F8 e 2F8 fossero indirizzi di memoria allora le porte
sarebbero sopra la IDT. Questo dovrebbe bastare a farti capire che non
si tratta di porte memory mapped ma di semplice IO.
L'architettura dei PC *NON* prevede IO memory mapped, a meno che qualche
scheda non se lo gestisca per conto suo riservando dall'OS una zona di
memoria e facendo quello che deve fare quando il processore vi accede.


L'architettura dei PC *NON* prevede IO memory mapped
Scusa, ma tu cosa intendi per memory mapped?


ar...@logic.it
 wrote:
 >Semplicemente perchè non è vero. Ciò non significa che io sappia tutto.
Ecco, per esempio non sai come funziona l'IO.
 >>Se hai indirizzi di IO allora NON avrai accesso tramite la memoria.
 >Non ho detto "tramite", la cosa è ben diversa.
Hai parlato di porte di IO memory mapped. Nel mio mondo il mmio e` un
sistema per usare accessi alla memoria invece che istruzioni
specializzate.
 >>Altrimenti avresti dei puntatori alla ram da usare con MOV e non degli
 >>indirizzi da usare con IN e OUT.
 >Una delle cose che non conosco del PC è il suo Assembly, quindi non
 >conosco le differenze tra le istruzioni che citi.
Non c'e` molto da capire, la prima istruzione mette qualcosa in memoria
o in un registro e le altre mettono o prendono un registro in/da una
porta di IO.
 >>No. Non so cosa hai controllato e/o capito, ma:
 >>1) e` ovvio che qualunque cosa comunichi con l'esterno usi un bus
 >E` ovvio se ti riferisci ad un PC...
Non mi sembrava che discutessimo di altro.
 >>2) il fatto che venga usato un bus non implica che si acceda alla ram.
 >Guarda che non ho scritto che "devi accedere alla RAM". Io (e non
 >solo...) per memory mapped intendo una cosa diversa, ovvero il fatto
 >che la CPU usa degli indirizzi di memoria per accedere ai registri
 >della periferica; il più delle volte a quegli indirizzi non
Si, mi sono espresso male.
 >Un'altra soluzione è scrivere nella RAM da cui poi la periferica
 >preleverà i dati, ma sempre memory mapped resta.
No, questo e` DMA ed e` una cosa ancora diversa e per nulla simile al
IO tramite porte o memory mapped.
 >>Ripeto: Se 3F8 e 2F8 fossero indirizzi di memoria allora le porte
 >>sarebbero sopra la IDT.
 >Credo che tu stia dicendo che a quegli indirizzi non corrisponde RAM
 >fisica e su questo non sollevo alcun dubbio; ma quelli restano
 >_indirizzi di memoria_ che sono rimappati sulle periferiche.
No. Io sto tentando di spiegarti che a 0x2F8 e 0x3F8 c'e` della RAM vera
e che questa e` gia` usata dalla IDT e quindi e` impossibile che ci
siano anche delle porte memory mapped.
 >Come ripeto, per quel che ne so, la soluzione di avere istruz/registri
 >CPU dedicati a periferiche è inapplicabile in un ambito quale quello
 >dei PC.
Non lo sai, perche` l'architettura IA32 usa proprio due istruzioni
dedicate: IN e OUT.
 >>L'architettura dei PC *NON* prevede IO memory mapped
 >Scusa, ma tu cosa intendi per memory mapped?
Scrivo il mio dato in memoria a un certo indirizzo e l'hardware
automaticamente lo legge e ci fa quello che deve. La circuiteria
standard dei PC non lo fa. Alcune schede (di solito schede grafiche) si.


siano anche delle porte memory mapped.
AAAAAAAAAAAAAHhhhhhhhh!!! Ostrega, scusa, ma io continuavo a leggere
quel "sopra" come ad intendere che la IDT aveva degli indirizzi più
bassi! :-DD Per quello che non capivo dove stesse il problema! ;-)
Stando così le cose, mi riprometto di andare a picchiare chi mi ha
spacciato per indirizzi di RAM quei codici... e chiedo scusa per la
caparbietà!
A parziale scusa, posso dire che il mio libro di testo riporta che
molti processori, tra cui i 680x0, usano il memory mapped. Pare che
abbia capito male io, ma pensavo si riferisse alle CPU general
porpouse.
