dove viene eseguito il codice del driver del dispositivo? Spazio del kernel o spazio utente?

Question

Parte 1:

Per le/unix linux esperti là fuori, la prego di aiutarmi comprensione sui driver di periferica. Come ho capito, un driver è un pezzo di codice che interagisce direttamente con l'hardware e espone alcuni apis per accedere al dispositivo. La mia domanda è: dove gira questo pezzo di codice, lo spazio dell'utente o lo spazio del kernel?

So che il codice che viene eseguito nello spazio del kernel ha alcuni privilegi extra come l'accesso a qualsiasi posizione di memoria (pls corretto se ho torto). Se installiamo un driver di terze parti e se viene eseguito nello spazio del kernel, questo non sarebbe dannoso per l'intero sistema? Come qualsiasi sistema operativo gestisce questo?

Parte 2:

Consente di prendere un esempio di dispositivo USB (fotocamera, tastiera ..), come il sistema riconosce questi dispositivi? come fa il sistema a sapere quale driver installare? In che modo il conducente conosce l'indirizzo del dispositivo per leggere e scrivere i dati?

(se questo è troppo grande per rispondere qui, pls fornire collegamenti di qualche buona documentazione o tutorial .., ho provato e non poteva trovare risposte per questi. Pls aiuto)

Answer 1

Parte 1

Su Linux, i driver vengono eseguiti nello spazio del kernel. E sì, come lei afferma che ci sono implicazioni di sicurezza significative a questo. La maggior parte delle eccezioni nei driver eliminerà il kernel, potenzialmente corrompendo la memoria del kernel (con ogni sorta di conseguenze). I driver buggy hanno anche un impatto sulla sicurezza del sistema e i driver dannosi possono fare assolutamente tutto ciò che vogliono.

Una tendenza osservata sui kernel MacOSX e Windows NT è driver di spazio utente. Da qualche tempo Microsoft sta spingendo lo Windows Userspace Driver Framework e MacOSX ha a lungo fornito le API dello spazio utente per i driver Firewire e USB e i driver conformi alla classe per molte periferiche USB. è abbastanza inusuale installare driver di dispositivo in modalità kernel di terze parti su MacOSX.

Probabilmente, la cattiva reputazione di Windows per i panici del kernel può essere attribuita ai driver in modalità kernel (spesso di scarsa qualità) forniti con ogni cellulare, fotocamera e stampante.

I driver di grafica per Linux sono praticamente tutti implementati nello spazio utente con una porzione minima residente al kernel e Fuse consente l'implementazione di sistemi di archiviazione nello spazio utente.

Parte 2

USB, Firewire, MCI (e anche PCI-e) hanno tutti i meccanismi di enumerazione attraverso il quale il conducente bus può abbinare il dispositivo a un driver. In pratica ciò significa che tutti i dispositivi espongono metadati che descrivono ciò che sono.

Contenuti all'interno dei metadati sono un DeviceID, un VendorID e una descrizione delle funzioni fornite dal dispositivo e ClassID associati. ClassIDs facilita il generico Class Drivers.

Concettualmente, il sistema operativo tenterà di trovare un driver che supporti in modo specifico il VendorID e DeviceID e quindi ricolleghi a uno che supporti i ClassID.

I dispositivi di corrispondenza con i driver sono un concetto centrale nel cuore di Linux Device Model ei criteri di corrispondenza esatti utilizzati per la corrispondenza sono la funzione match() nello specifico driver di bus.

Una volta che i driver di periferica sono legati a un dispositivo, utilizza il bus-driver (o di indirizzamento informazioni fornite da esso) per eseguire lettura e scrittura. Nel caso di PCI e Firewire, questa è una memoria mappata indirizzo IO. Per le informazioni di indirizzamento del bus USB.

Linux Documentation tree fornisce alcune informazioni sul design del modello di dispositivo Linux, ma non è realmente una lettura di livello base.

Consiglio anche la lettura Linux Device Driver (3rd Edition)