Newsgroup: it.comp.os.dibattiti
Titolo: FORSE OT: WINNT-WIN2000

Su Windows se ne dicono di cotte e di crude. In particolare ci se la prende
per la manifesta incapacità del kernel di caricare dinamicamente i moduli.
Tuttavia su questa cosa cosa sono piuttosto perplesso.. Non è forse vero che
in fase di installazione NT è in grado di agganciarsi i driver necessari al
riconoscimento dell' hardware?
Ma allora come stanno veramente le cose?
Ciao
UltraSparc

UltraSPARC ha scritto:


Me lo sono sempre chiesto. Ma forse fra le altre cose c'e' di mezzo la
configurazione ed il relativo registro. Per il resto passo la palla a persone
decisamente piu' esperte di me.
bye G.L.

 Ma allora come stanno veramente le cose?
Il problema e' che non conosco sotto NT l'equivalente di 
# modprobe smbfs
(carica il modulo per il file system Samba e tutti i moduli da cui dipende)
A quanto ne so e ho sperimentato, NT non e' capace di caricare
dinamicamente i moduli del kernel se non all'inizio dell'installazione
(anche se mi sembra che sia un procedimento abbastanza stupido, su un PC
senza SCSI, mi caricava anche i moduli per controller SCSI, quindi 
suppongo che lui carichi comunque tutto)
Forse con i servizi riesci a fare qualcosa, ma ne dubito molto fortemente
bye
Gianluca
-- 
Home Page                	Contro i brevetti sw     Boicotta Microsoft
www.infinito.it/utenti/chewbe
 
no-patents.prosa.it/
 
www.boycott-ms.org/
 
"If we have to file a thousand lawsuits a day, we'll do it.
It's less expensive than losing CONTROL of YOUR creative works."
---Jack Valenti, President and CEO, Motion Picture Association of America

 suppongo che lui carichi comunque tutto)
Non li carica, TENTA di caricarli. Se la periferica non c'e', non rimangono ne'
attivi ne' in memoria (per cosa, per intercettare ad esempio interrupts
inesistenti e far crashare il sistema?).
bye G.L.

 suppongo che lui carichi comunque tutto)
Fai attenzione perché volendo puoi specificare ulteriori driver che vengono
agganciati al volo.
Ciao
UltraSparc

inesistenti e far crashare il sistema?).
All'installazione carica in memoria driver dei controller disco
supportati (scsi e non), 
- testa il sistema
- ti mostra la lista dei dispositivi rilevati sul sistema
- ti chiede si vuoi specificare un driver aggiuntivo e caricarlo da
dischetto 
- infine installa _solo_ i driver specificati nella lista +,
eventualmente, quello aggiunto da te.
Ciao
Francesco

 eventualmente, quello aggiunto da te.
Si, volevo dire che il tutto e' a livello di determinazione dell'hardware durante
l'installazione: i drivers caricati e inizializzati con successo si suppone siano
l'hardware di cui dispone la macchina, il resto non puo' rimanere come moduli del
kernel.
bye G.L.

 agganciati al volo.
Mmmm, non saprei. Secondo me c'e' qualcosa di base che non funziona nel 
ragionamento. Se NON ho un controller SCSI, come mai lo carica ? E 
i driver aggiuntivi li puoi caricare al volo durante l'uso del sistema
senza fare un reboot ?


 inesistenti e far crashare il sistema?).
Quando mi crashava NT durante l'installazione, nel dump si vedevano un paio
di driver per roba SCSI (AICxxxx e un altro che non mi ricordo), anche
se NON avevo roba SCSI installata (per la cronaca, crashava per colpa
del processore, un AMD DX4100)


kernel.
Hemm, ti ricordo che Nt e' un microkernel, per cui tecnicamente i
driver non sono nel kernel, anche se girano allo stesso livello
(almeno quelli del controller disco e video)
Ciao
Francesco


Scusa l' ignoranza in materia...
Ha senso un microkernel con i driver che girano nello stesso ring del
sistema operativo?
Se girano a ring 0 non sono abilitati a fare danni irreparabili?
Ciao
UltraSparc

 senza fare un reboot ?
E proprio questo il punto che non capisco. In fase di installazione puoi
specificare ulteriori driver da caricare per vedere dispositivi particolari,
mentre a sistema avviato non puoi. Il quesito che mi pongo e' il sequente:
l' incapacità di caricare un driver dipende dal kernel o dalle interazioni
che questo ha con tutto il resto del software?
Ciao
UltraSparc

 (almeno quelli del controller disco e video)
Oddio, non arrivo a questo grado di conoscenza, ma nt non e' proprio microkernel nel
senso stretto. Non e' un kernel compilato staticamente, questo e' indubbio, e non so
sinceramente se i moduli vadano a far parte integrante dello spazio del kernel, come
mi sembra avvenga in linux. Girano a ring 0, questo si (e mi sembra difficile
ipotizzare il contrario). Se e' inesatta l'ultima affermazione (il resto non puo...)
rettifico: gli altri drivers di cui si e' fatto il "probe" non mi risulta che
rimangano in memoria.
bye G.L.


A questo punto, o e' strano, o mi sto sbagliando... Sei sicuro di non avere un
controller in piastra base, anche se non vi e' nulla collegato (il connettore su mb e
basta)? E possibile che magari sia disabilitato dal bios: alcuni bios lo disattivano
per modo di dire, sembra che rimanga una "periferica fantasma" e non correttamente
funzionante. Oppure e' l'amd...
bye G.L.

 Oppure e' l'amd...
In effetti ho notato che il problema lo dava con _quella_ famiglia di processori...
Era uno spasso, ogni crash era dovuto a qualche problema in qualche sub-system
diverso, perfino la tastiera...


Se girano a ring 0 non sono abilitati a fare danni irreparabili?
Si.
Pero', anche se cosi' non fosse, se si pianta il driver dell'io su
disco alla fine del sistema te ne fai poco.
Ciao
Francesco

del processore, un AMD DX4100)
Probabilmente si piantava durante la rilevazione automatica del
controller disco (magari proprio durante il test delle schede scsi).
Forse riuscivi a bypassare il problema non facendo il riconoscimento
automatico e scegliendo a mano dall'elenco il driver ide.
Ciao
Francesco

 disco alla fine del sistema te ne fai poco.
Anche su questo sono perplesso: supponiamo di avere un microkernel e che il
modulo che gestisce lo SCSI si incasini. Il kernel sarebbe obbligato a
killarlo, ma al successivo IO potrebbe ricaricarlo senza grossi problemi. Si
avrebbe qualche incoerenza a livello di filesystem, ma con delle
funzionalità di journaling ben implementate si ridurrebbe di molto questa
possibilità...
C'e' qualcosa che non va nel mio ragionamento?
Ciao
UltraSparc

 C'e' qualcosa che non va nel mio ragionamento?
Hemm, calma, stai andando fuori dalla mia portata.
Ci vuole qualcuno decisamente piu' esperto di me sulle architetture dei
kernel per riponderti.
Ciao
Francesco

possibilità...
Si perderebbero *comunque* dei dati, lo scopo del journaling non e`
questo, ma evitare un completo fsck al reboot. E comunque bisognerebbe
perdere del tempo a terminare le transazioni rimaste nel journal.
Considerando che le prestazioni sarebbero pietose, vedi tu se ne vale la
pena.
-- 
ciao, |
Marco | "You're one of those condescending Unix computer users!"
      | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 operazioni che stavano facendo).
Non è assolutamente detto. Dipende.
Saluti,
Fabio Alemagna

 perdere del tempo a terminare le transazioni rimaste nel journal.
Rimango ancora nel campo dei se...
Se esistesse un meccanismo di buffering si perderebbero comunque dati?
Ciao
UltraSparc

 Se esistesse un meccanismo di buffering si perderebbero comunque dati?
come sopra.
Saluti,
Fabio Alemagna

 non venga riattivato.
Tu dai per scontato che il crash del driver e l' operazione di
lettura/scrittura avvengano in tempi diversi. Immagina invece che il driver
cada contemporaneamente ad una operazione di IO. Cosa accade allora. L'
operazione è stata completa correttamente?
Un risultato aleatorio può stare bene ad ./hello > hello.out ma sicuramente
non ad un applicazione più sofisticata. Per questo pensavo ad un meccanismo
di buffering svincolato dal driver che potesse accodare richieste e portarle
a termine in un secondo tempo a driver ricaricato...
Ciao
UltraSparc

 a termine in un secondo tempo a driver ricaricato...
Un journaling a livello di kernell, insomma. Transazioni. Ma questo
implica una duplice copia, un duplice rallentamento.
Saluti,
Fabio Alemagna

 implica una duplice copia, un duplice rallentamento.
Non credo sia necessariamente detto un rallentamento. Le scritture
bufferizzate esistono gią e sono parte integrante dei sistemi operativi...
Purtroppo oltre non arrivo
Ciao
UltraSparc

Non è assolutamente detto. Dipende.
Avanti, allora spiegami come risolveresti il problema.


Un qualcosa di analogo alla cache WB
Non capisco cosa intendi, ma credo che tu non abbia capito il problema
che ho descritto.


non venga riattivato.
E il nuovo demone come fa a sapere che deve completare delle operazioni?


 Avanti, allora spiegami come risolveresti il problema.
Per caso se fallisce una read() o una write() devi uccidere il processo?
Saluti,
Fabio Alemagna

 E il nuovo demone come fa a sapere che deve completare delle operazioni?
Il nuovo demone non deve completare niente, perchè le operazioni
precedenti sono fallite.
E' sempre buona norma ricordare di controllare il valore di ritorno di
una write() o una read()...
Ciao,
Fabio Alemagna

 operazioni che stavano facendo).
Oddio, ucciderli mi pare eccessivo, diciamo che bisognerebbe
rendereli partecipi della disgrazia avvenuta...
Se un servizio non e` piu` disponibile, non si uccide il mica il
processo, semplicemente si ritorna un errore.
Qui, naturalmente, saltano fuori problemi su "chi fa cosa", cioe`
quanto il uK debba ficcare il naso neglio affari tra processi &
driver...
bye,
-- 
  Piergiorgio Sartor

 E il nuovo demone come fa a sapere che deve completare delle operazioni?
Interrogando il pool dei lavori tenuto dal kernel che intelligentemente
tiene nota dello stato di tutti i lavori e delle
risorse usate dai vari lavori.
Solo che ritorniamo all'annosa questione microkernel contro macrokernel
e della comunicazione fra moduli a mezzo messaggi.
Saluti.

risorse usate dai vari lavori.
Ah... Ma allora devi mettere nel kernel mezzo driver.


Per caso se fallisce una read() o una write() devi uccidere il processo?
La maggior parte dei programmi quando riceve un EIO muore malamente,
perche` tanto non c'e` piu` molto di salvabile.
A questo punto rimane ancora da garantire la coerenza del file system.
E non dimenticare che bus e dispositivi devono essere riportati in uno
stato in cui si possa continuare ad usarli.


 stato in cui si possa continuare ad usarli.
be', non vedo la difficoltà...
Saluti,
Fabio Alemagna

 Ah... Ma allora devi mettere nel kernel mezzo driver.
no no, non serve tutto 'sto bordello...
Saluti,
Fabio Alemagna

 Ah... Ma allora devi mettere nel kernel mezzo driver.
No. Bastano le strutture dati manipolate dai driver.
Saluti.