Driver, questi illustri sconosciuti

Visualizzazione dei risultati da 1 a 8 su 8
  1. #1
    Nexthardware Staff L'avatar di brugola.x
    Registrato
    Feb 2007
    Località
    1/2 lombardo
    Età
    51
    Messaggi
    18,800
    configurazione

    Predefinito Driver, questi illustri sconosciuti




    Driver croce e delizia, chi ha un pc sà di cosa stò parlando.. da quello che ho potuto vedere però imparare un minimo a gestirli correttamente spesso e volentieri questo ci mette al coperto da certe situzioni che possono effettivamente diventare se non difficili perlomeno complicate.
    E' un argomento non banale e che credo possa essere di comune interesse quindi perfavore non fate i timidi e datemi una mano a fare un pò di luce sull'argomento. Voglio parlare di come aggiornare un driver in modo corretto, di come gestire l'installazione e la disinstallazione del driver grafico, di quello del mause o di quello della stampante, voglio che mi aiutate a parlare di driver.
    Sono ben coscitente del fatto che stò aprendo un vaso di pandora ma sono altresì convinto che se con questo post riesco a "catturare" anche solo il 10% del "sapere" e delle informazioni utili che girano quì sul forum questo thread rischia di poter essere d'aiuto a molti quindi ragazzi parliamone di questi driver!!

    Io inizierei piantando subito qualche bel paletto:

    Cos'è un driver? a cosa serve? come lo posso aggiornare? cos'è la pulizia driver e a cosa serve?

    Sono domande più che lecite e per rispondere mi faccio aiutare da un dizionario e da Wikipedia che magari non sarà la bibbia del sapere umano ma credo che riesca comunque a spiegarci quello che ci serve sapere su questo argomento per iniziare a parlarne con un minimo di cognizione di causa.

    Cos'è un driver?

    ecco cosa dice il dizionario:

    driver ‹dràivë› s. ingl. [propr. «chi spinge o guida o colpisce», der. di (to) drive «guidare, spingere»] (pl. drivers ‹dràivë∫›), usato in ital. al maschile.
    1. Il guidatore nelle gare ippiche di trotto.
    2. Tipo di bastone da golf di legno elastico.
    3. In informatica, programma, contenuto in un programma principale, per controllare e gestire un’unità periferica di un calcolatore elettronico (stampante, ecc.), talora consentendo all’unità periferica di comunicare con il sitema operativo del calcolatore.
    Proviamo a vedere cosa dice Wikipedia:

    In informatica, è detto driver l'insieme di procedure, spesso scritte in assembly, che permette ad un sistema operativo di pilotare un dispositivo hardware. Il driver permette al sistema operativo di utilizzare l'hardware senza sapere come esso funzioni, ma dialogandoci attraverso un'interfaccia standard, i registri del controllore della periferica, che astrae dall'implementazione dell'hardware e che ne considera solo il funzionamento logico. In questo modo hardware diverso costruito da produttori diversi può essere utilizzato in modo intercambiabile.

    Ne consegue che un driver è specifico sia dal punto di vista dell'hardware che pilota, sia dal punto di vista del sistema operativo per cui è scritto. Non è possibile utilizzare driver scritti per un sistema operativo su uno differente, perché l'interfaccia è generalmente diversa.

    Il driver è scritto solitamente dal produttore del dispositivo hardware, dato che è necessaria un'approfondita conoscenza dell'hardware per poter scrivere un driver funzionante. A volte, i driver vengono scritti da terze parti sulla base della documentazione tecnica rilasciata dal produttore, se questa è disponibile.(fonte: wiki)

    Cos'è un driver WHQL?

    Windows Hardware Quality Labs è una certificazione concessa dalla Microsoft a quei prodotti informatici hardware o software che hanno superato un test di compatibilità eseguito dai Microsoft Compatibility Labs. La certificazione ottenuta da un prodotto è indicata dal logo Certified for Windows, che può riferirsi anche a qualche specifica versione di tale sistema operativo.

    Alcuni driver che hanno ottenuto tale certificazione vengono resi disponibili per il download dalla Microsoft stessa attraverso Windows Update, che ne segnala la disponibilità se e quando rileva che su un computer è installata una versione meno aggiornata. (fonte: wiki)

    Allora, come abbiamo potuto vedere quì sopra i principali driver necessari per il funzionamento del nostro pc ci vengono direttamente proposti dal sistema operativo stesso.
    Windows di suo nel disco d'installazione contiene già dei driver più o meno generici necessari per l'installazione stessa del sistema operativo, ad esempio il driver grafico base, quello della tastiera o quello del mause ma in realtà "mille" altri driver lavorano in background garantendovi da prima le funzioni elementari poi se aggiornati a dovere vi forniranno il massimo delle prestazioni e del controllo della periferica in oggetto.
    I driver spesso li possiamo trovare in un cd a corredo della periferica stessa oppure li possiamo recuperare direttamente dal sito del produttore presso la sezione download dove vi sarà possibile scaricare la versione più aggiornata. Questo vale anche per driver di terze parti.

    Driver Registro di Sistema e Pulizia

    I driver per comunicare inseriscono nel registro di sistema del sistema operativo una serie di informazioni necessarie per l'identificazione della periferica. Un esempio pratico, quando colleghiamo per la prima volta una periferica il sistema operativo si adopererà per riconoscere l'UFO utilizzando i driver base. Se non ci riesce sono necessari quelli di terze parti.
    Tutto questo avviene solo al primo collegamento perchè da lì in poi la periferica in oggetto diverrà immediatamente riconosciuta e fruibile dal sistema operativo.
    Driver nuovi, driver vecchi, come le elimino le eventuali traccie delle precedenti installazioni? Lo si può fare in modo manuale ma vi consiglio di affidarvi a degli appositi software che permettono il massimo del massimo con il minimo sbattimento.
    Io mi trovo benissimo con un programma freeware che si chiama CCleaner ma in rete ne troverete molti altri e altrettanto efficaci.

    Driver Registro di Sistema e Pulizia Driver Grafico

    work in progress..
    Ultima modifica di brugola.x : 23-12-2013 a 21:37

  2. #2
    Nexthardware Staff L'avatar di brugola.x
    Registrato
    Feb 2007
    Località
    1/2 lombardo
    Età
    51
    Messaggi
    18,800
    configurazione

    Predefinito

    se ho detto cose inesatte, se volete contribuire alla discussione approfondendo o sviluppando uno dei punti proposti, se volete aggiungerne altri, se avete cose da chiedere.. fatelo! ditemi la vostra!!

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    44
    Messaggi
    23,415
    configurazione

    Predefinito

    Personalmente tendo a dare questo tipo di "interpretazione" per spiegare in modo semplice il funzionamento e la funzione di un driver: Facendo un parallelismo con l'interpretariato, se il sistema operativo è l'interprete che traduce i comandi che l'utente vuole impartire alla macchina, il "driver" è il dizionario che permette al traduttore di esprimere i comandi in un linguaggio comprensibile ai vari dispositivi hardware.
    Il driver deve quindi essere scritto in un linguaggio che sia comprensibile al traduttore perchè lo possa utilizzare (architettura compatibile) e, contemporaneamente, per poter sfruttare completamente le capacità dell'hardware deve essere calibrato sul dispositivo per supportarne a pieno tutte le funzionalità. Grosso modo, questo si può approssimare in un dizionario bilingue che da una parte parli la lingua dell'interprete (Windows piuttosto che Linux o MacOS) e che sia sufficientemente completo da permettere all'interprete di usare sempre l'espressione giusta per permettere all'hardware di eseguire i comandi impartiti nel modo più efficiente ed efficace possibile.

    Un driver generico è approssimabile ad un dizionario tascabile: Supporta le funzionalità di base, magari anche bene, ma probabilmente non è in grado di rendere tutte le possibili sfumature linguistiche necessarie a sostituire il driver specifico.

    Ogni componente hardware ha bisogno di un driver, dal cicalino di sistema al controller di storage più evoluto: Ormai ogni sistema operativo dispone di un set di driver generici che gli permette di eseguire le funzionalità di base su qualunque hardware. Per i dispositivi più semplici il "dizionario incorporato" è ormai sufficientemente forbito da non richiederne la sostituzione con un driver specifico mentre per le periferiche più nuove o complesse/specialistiche è necessario un driver ad hoc.

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #4
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Sarebbe un'impresa titanica scrivere tutto quanto possa servire a focalizzare nel dettaglio il
    lavoro dei driver e la loro importanza vitale per le funzionalità di un s.o..

    In ambiente Windows, a partire da Windows XP/2003 (Plug and Play drivers) Microsoft ha previsto
    un'architettura a strati per ciò che concerne i device driver: questa comprende non solo i drivers
    ma anche gli oggetti creati, dai drivers stessi, nella fase di gestione dei dispositivi.

    Il Plug and Play gestisce tre differenti tipi di drivers:
    1. Function Drivers (gestiscono i singoli dispositivi);
    2. Filters Drivers (filtrano le richieste di I/O per i dispositivi, per le classi dei dispositivi e i bus);
    3. Bus Drivers (servono i controller dei bus, gli adattatori e i chip che fungono da bridge).


    Un driver può creare i propri Device objects (DO) per ogni dispositivo controllato: si può pertanto
    assumere che ogni device object rappresenta, in definitiva, il vero e proprio dispositivo per il driver.

    La struttura del Plug and Play riconosce tre diversi tipologie di device objects:
    1. Physical Device Objects (PDO): rappresentano i singoli dispositivi per i Bus Driver;
    2. Functional Device Objects (FDO): rappresentano i singoli dispositivi per i Function Drivers;
    3. filter Device Objects (f-DO): rappresentano i singoli dispositivi per i Filter Drivers.


    Nell'immagine seguente è rappresentata la catena funzionale degli oggetti e dei drivers di un
    generico dispositivo Plug and Play:

    Nome:   WindowsDeviceStack.jpg
Visite:  642
Grandezza:  12.8 KB
    I componenti utilizzati per i Device Objects nel Device Stack sono due:
    1. Lower-level filter driver
    2. Upper-level filter driver


    Per entrambi i level filter driver esistono due tipi di filtri:

    1. Device-specific
    2. per-Class


    Un Lower-level filter driver viene caricato immediatamente dopo il relativo bus driver e qualsiasi relativo
    filtro.

    Un filtro Device-specific controlla e modifica le richieste di I/O per un particolare dispositivo. In buona
    sostanza il suo compito è quello di verificare che il comportamento del dispositivo si mantenga entro
    le proprie specifiche. Da par suo, un filtro per-Class controlla e modifica le richieste comuni di I/O per
    un'intera classe di dispositivi.

    Un Upper-level filter driver viene invece caricato solo dopo il relativo function driver, e connette il
    proprio device objects sul Functional Device Objects.

    Come per un lower-filter, anche un Upper-level Device-specific controlla e modifica le richieste di I/O
    per un particolare dispositivo. In buona sostanza il suo compito è quello di verificare che il comportamento
    del dispositivo si mantenga entro le proprie specifiche. Da par suo, un filtro per-Class controlla e modifica
    le richieste comuni di I/O per un'intera classe di dispositivi.

  5. #5
    Nexthardware Staff L'avatar di brugola.x
    Registrato
    Feb 2007
    Località
    1/2 lombardo
    Età
    51
    Messaggi
    18,800
    configurazione

    Predefinito

    tantaroba, a nome di tutti grazie per il contributo
    per quanto mi riguarda purtroppo devo mettere questa dei driver in standby, il mio pc piuttosto che funzionare con i catalyst 13,12 si è suicidato, evidentemente noi vecchietti (io e la mia mobo) proprio non le reggiamo più certe cose... quindi, per ora quasi tutti i miei appunti utili allo sviluppo della discussione non sono raggiungibili. Appena possibile non tarderò a dare il mio contributo alla discussione, portate pazienza và

  6. #6
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Ampliando un po il concetto del sistema di I/O applicato in Windows che supporta, come
    appurato in precedenza, un'architettura a partire da un modello funzionale a struttura
    stratificata, si potrebbe aggiungere qualcos'altro.

    Le applicazioni e i servizi in modalità utente mostrano da una parte le richieste di I/O
    attraverso le chiamate effettuate dalle API Win32 e, dall'altra, comunicano col gestore
    PnP (sempre in modalità utente) per portare a termine sia le necessarie attività di alimentazione
    che quelle Plug and Play.

    Le API Win32 ed il gestore della modalità PnP, a loro volta, comunicano con il sistema di
    I/O in kernel mode: tale sistema comprende il gestore della modalità kernel di I/O, il
    gestore del PnP e quello di alimentazione.

    Solo il sistema di I/O in Modalità kernel può infine comunicare con i driver in modalità kernel:
    questo è il motivo per cui anche il modello dei driver è disposto a strati.

    Molti dispositivi sono controllati nella loro completezza non solo da uno ma da diversi drivers:
    ognuno di essi appare stratificato in cima a quello successivo. Tutta la serie di drivers che
    gestisce un particolare dispositivo, insieme, è chiamato device stack o, talvolta, driver stack.

    Partendo dalla parte più in basso dello stack (quella più significativa) vi è un bus driver,
    preposto a controllare uno specifico bus ed elencare i dispositivi ad esso collegati.

    Uno strato sopra il bus driver vi sono i filter drivers (driver di filtro) e i function drivers
    (driver funzionali). Il function driver rappresenta quello principale per il dispositivo ed ha il
    compito di esporre l'interfaccia del dispositivo stesso all'I/O manager.

    Abbiamo visto in precedenza come i driver di filtro possono, a loro volta, essere stratificati
    sia al di sopra che al di sotto del driver di funzione: hanno infatti la capacità di fornire
    funzionalità aggiuntive, come quelle di crittografia o di sicurezza, e possono provvedere
    a modificare il comportamento di un dispositivo.


    Ogni driver nel device stack è rappresentato, in conclusione (come detto nel post precedente),
    da un oggetto di periferica (device object): tale oggetto risulta in definitiva una struttura
    di dati che contiene tutte le informazioni sul driver e sul dispositivo gestito.


    Clicca sull'immagine per ingrandirla

Nome:   Windows_Input-Output_System.jpg
Visite: 212
Dimensione:   44.5 KB
ID: 14538



    I drivers ricevono funzionalmente le richieste di I/O, di Plug and Play e di gestione
    dell'alimentazione sotto forma di pacchetti di richiesta di I/O, detti IRP.

    Quando l'I/O manager di Windows riceve una richiesta di I/O da un programma o da un
    servizio in esecuzione, provvede per prima cosa a determinare quale device stack
    corrisponda al file virtuale del dispositivo specificato nella richiesta. Appurato ciò, l'I/O
    manager impacchetta la richiesta in un IRP e la inoltra al device object destinatario.

    Come si diceva, oltre le normali richieste di I/O, anche le notifiche per la gestione di
    alimentazione e Plug and Play vengono impacchettate all'interno di IRP, funzionalità
    che dà modo ai drivers di mettersi in comunicazione tra loro, inviando opportuni IRP.

    Nel momento in cui un driver ricevesse un IRP, può prendere tutte le necessarie azioni per
    soddisfare e completare la richiesta. A volte, tuttavia, un driver non è in grado di soddisfare
    da sé le richieste contenute in un un IRP, giuntogli da uno degli strati superiori del device
    stack.

    Se il driver non fosse in grado di completare l'IRP, tipicamente lo passa più in basso nel
    device stack, alla tipologia di driver successivo nello stesso. Una volta passato il pacchetto
    di richesta può anche impostare, opzionalmente, un flag di completamento di routine di I/O,
    utile per ricevere la notifica al momento che l'IRP sia stato definitivamento completato da
    uno dei drivers che si trovano ai livelli inferiori.

    Alla fine, il RIP deve per forza di cose giungere ad un livello in cui uno dei driver riesce a
    soddisfare e completare le attività richieste.

    Solo a questo punto, l'I/O manager, notiziato direttamente dal driver che ha completato la
    richiesta, effettua una chiamata di callback verso tutte le routine di completamento, che i
    driver avevano in precedenza impostato come richiesta di notifica via via giù per il percorso
    dello stack del dispositivo.

    L'ordine di chiamata sarà inverso a quello nel quale sono stati impostati, snodando quindi in
    su il salvataggio precedente dello stato del device stack.

  7. #7
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    44
    Messaggi
    23,415
    configurazione

    Predefinito

    Ma quali sono i reali vantaggi di un struttura così complessa, confrontati con un modello a chiamata diretta (intendo dalle Windows API/PnP Usermode al livello del bus driver)?
    Così a pelle mi viene in mente solo una maggiore semplicità di programmazione del driver ma a fronte di un aumento delle complessità architetturale notevole...

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #8
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Lo svantaggio, proprio dovuto alla maggior complessità (non solo nel numero superiore di linee
    di codice necessarie) per come l'hai individuata, è quello relativo ad una diminuita velocità
    complessiva nell'esecuzione di questa catena di molteplici chiamate, apportata da verosimili
    overhead.

    Ritengo, però, che questa (relativa) limitazione non si traduca oggigiorno in svantaggi così
    evidenti, stante alla enorme capacità elaborative delle cpu multicore più recenti.

    Questo metodo meno diretto, invece, il quale prevede implementata internamente ai driver stessi
    l'intera loro logica di controllo di stato, può portare in primis al beneficio della mancata esposizione
    delle strutture dei dati più interne del s.o. al codice lato utente sviluppato, volutamente o meno,
    in malo modo.

    In maniera concomitante produrrà non solo maggior sicurezza ma anche altri aspetti positivi:
    1. minori rischi che l'anomalia di un driver possa portare, da sola, ad un crash del kernel
    2. la non dispersione dei driver in un numero altamente elevato di modelli differenti
    3. più solidità intrinseca in virtù di una diminuita possibilità di errata programmazione

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022