Perché C viene utilizzato per lo sviluppo dei driver anziché C#?

Question

Eventuali duplicati:
C# driver development?

Perché usiamo C per sviluppo di device driver, piuttosto che C#?

Answer 1

Poiché i programmi C# non possono essere eseguiti in modalità kernel (Ring 0).

Answer 2

Il motivo principale è che C è molto più adatto per lo sviluppo di basso livello (vicino all'hardware) di C#. C è stato progettato come una forma di codice di assemblaggio portatile. Inoltre, molte volte potrebbe essere difficile o non sicuro usare C#. Il momento chiave è quando i driver vengono eseguiti su ring-0 o kernel mode. La maggior parte delle applicazioni non è pensata per essere eseguita in questa modalità, incluso il runtime .NET.

Anche se teoricamente è possibile farlo, molte volte C è più adatto all'attività. Alcuni dei motivi sono un controllo più stretto su quale codice macchina viene prodotto e avvicinarsi al processore è quasi sempre migliore quando si lavora direttamente con l'hardware.

Answer 3

Perché C# è un linguaggio di alto livello e non può parlare direttamente con i processori. Il codice C viene compilato direttamente nel codice nativo che un processore può comprendere.

Answer 4

La C è un linguaggio che supporta di più per l'interfaccia con altre periferiche. Quindi C è usato per sviluppare i System Software. L'unico problema è che è necessario gestire la memoria. È un incubo per gli sviluppatori. Ma in C# la gestione della memoria può essere fatta in modo semplice e automatico (ci sono n numero di differenze tra c e C# , prova googling).

Answer 5

Ignorare le limitazioni del linguaggio gestito di C# per un po ', i linguaggi orientati agli oggetti, come C#, spesso fanno cose sotto il cofano che potrebbero intralciare lo sviluppo dei driver. Lo sviluppo del driver - in realtà la lettura e la manipolazione di bit nell'hardware - spesso ha vincoli temporali serrati e fa uso di pratiche di programmazione che vengono evitate in altri tipi di programmazione, come i puntatori occupati e il dereferenziamento impostati da valori costanti interi. I driver di dispositivo sono spesso scritti in un mix di C e assemblaggio in linea (o si avvalgono di qualche altro metodo di rilascio delle istruzioni che i compilatori C normalmente non producono). I meccanismi di blocco di basso livello da soli (scritti in assembly) sono sufficienti per rendere difficile l'uso di C#. C# ha un sacco di funzionalità di blocco, ma quando si scava sono al livello di threading. I driver devono essere in grado di bloccare interrupt e altri thread per preformare alcune attività.

I linguaggi orientati agli oggetti tendono anche a allocare e deallocare (tramite garbage collection) molta memoria ripetutamente. All'interno di un gestore di interrupt, tuttavia, la possibilità di accedere alla funzionalità di allocazione dell'heap è severamente limitata. Ciò è dovuto al fatto che l'allocazione dell'heap può attivare la garbage collection (costosa) e poiché è necessario evitare e gestire sia il codice di interrupt che il codice di non interrupt che tenta di allocare contemporaneamente. Senza molte limitazioni poste su questo codice, sull'output del compilatore e su qualunque cosa stia gestendo il codice (VM o eventualmente compilato in modo nativo e usando solo le librerie), probabilmente si avranno degli errori molto strani.

Le lingue gestite devono essere gestite da qualcuno. Questa gestione si basa probabilmente su un sistema operativo sottostante funzionante. Ciò produce un problema di bootstrap per l'utilizzo del codice gestito per molti (ma non tutti) driver.

È completamente possibile scrivere driver di periferica in C#.Se stai guidando un dispositivo seriale, come un dispositivo GPS, allora potrebbe essere banale (anche se utilizzerai un chip UART o un driver USB da qualche parte più in basso, che è probabilmente scritto in C o assembly) poiché può essere fatto come una domanda. Se stai scrivendo una scheda ethernet (che non è utilizzata per l'avvio dalla rete), potrebbe essere (teoricamente) possibile utilizzare C# per alcune parti di questo, ma probabilmente dovresti fare molto affidamento su librerie scritte in altre lingue e/o utilizzo della funzionalità del driver userspace di un sistema operativo.

C viene utilizzato per i driver perché ha un output relativamente prevedibile. Se si conosce un po 'di assembly per un processore, è possibile scrivere del codice in C, compilare per quel processore e avere una buona idea su come sarà l'assemblaggio. Saprai anche il determinismo di quelle istruzioni. Nessuno di loro ti sorprenderà e darà il via al garbage collector o chiamerà un distruttore (o finalizzato).

Answer 6

Ecco l'onesta verità. Le persone che tendono ad essere bravi nelle interfacce hardware o hardware, non sono programmatori molto sofisticati. Tendono ad attenersi a linguaggi più semplici come C. Altrimenti, si sarebbero evoluti dei framework che permettessero l'uso di linguaggi come C++ o C# a livello del kernel. Interi sistemi operativi sono stati scritti in C++ (ECOS). Quindi, IMHO, è principalmente tradizione.

Ora, lo è alcuni argomenti legittimi contro l'utilizzo di linguaggi più sofisticati in codice esigente come driver/kernel. C'è l'aspetto visibilità. I compilatori C# e C++ fanno molto dietro le quinte. Una dichiarazione di assegnazione innocua può nascondere uno shitload di codice (override dell'operatore, proprietà). Il costo delle eccezioni potrebbe non essere chiaramente visibile. La garbage collection rende poco chiara la durata degli oggetti/della memoria. Tutte le funzionalità che semplificano la programmazione sono anche una corda con cui impiccarti.

Quindi è necessario l'ecosistema per la lingua. Se le caratteristiche richieste coinvolgono troppi componenti, la dimensione da sola potrebbe diventare un fattore. Se i primitivi nella lingua tendono ad essere pesanti (per utili astrazioni del software), è un onere che i driver e i kernel potrebbero non essere disposti a portare.

Answer 7

Solo per costruire un po 'la risposta di Darin Dimitrov. Sì, i programmi C# non possono essere eseguiti in modalità kernel.

Ma perché non possono?

In Patrick Dussud interview per Behind the Code descrive un tentativo durante lo sviluppo di Vista di includere il CLR a un livello basso *. Il muro che hanno colpito è che il CLR prende dipendenza dalla libreria di sicurezza del sistema operativo, che a sua volta prende dipendenze dal livello dell'interfaccia utente. Non erano in grado di risolvere questo per Vista. A parte la singolarità, non conosco altri sforzi per farlo.

* Si noti che mentre "basso livello" potrebbe non essere stato sufficiente per poter scrivere i driver in C# era quanto meno necessario.