La sconfitta del drago

Per un programmatore di sistema, una delle attività più rognose e purtroppo anche più frequenti, è la programmazione di un device driver.

Cos'è un device driver?
Avete presente quando comprate un nuovo computer e vi danno un CD o DVD con i "driver"? Quelle cose che rischiano di far piantare tutto? Insomma, quelle cose che stanno facendo fallire il nuovo Windows Vista. No, eh? Va beh, proviamo a spiegarlo per bene in 2 righe (ossimoro).
Un device driver è un modulo di codice software che fa da interfaccia fra il processore principale e un dispositivo esterno. Ad esempio, un modem è un dispositivo esterno che connette il computer alla linea telefonica. Sulla linea telefonica passano segnali analogici; il modem li trasforma in segnali digitali; il software di controllo del modem li carica nella memoria del computer perché possano essere elaborati. Il mouse, il video, la scheda sonora, la scheda wireless, sono tutti esempi di dispositivi esterni che necessitano di un "driver".
Il driver dipende dal modello del dispositivo esterno: modem diversi (cioè di marche diverse, o modelli diversi di una stessa marca) funzionano in modo differente, e quindi necessitano di un programma di controllo differente.

Capito? no? va beh, non importa, potete continuare a leggere comunque.

Si diceva che scrivere sto maledetto codice per i "driver" è rognoso. Qualche volta può essere anche molto semplice, come: 1, 2, 3, fatto. Alle volte è come... catturare un drago armati solo di spada e corda! (*). Quello che ci è capitato questa settimana era come un draghetto, se così si può dire.

Mesi fa abbiamo aquistato una scheda di rete per il nostro sistema "embedded" da utilizzare in un progetto ('sto troiaio qui). Ci arriva la scheda da montare con il solito CD contenente il codice del driver. Indovina? mai funzionato veramente. Prove su prove: riceveva dei dati per un po', poi inspiegabilmente si piantava. Filippo, il ragazzo che ci lavorava era quasi alla disperazione. Alcuni mesi dopo la scadenza del progetto, la scheda ancora non funziona, e abbiamo ormai l'acqua alla gola. Che si fa? La settimana scorsa chiamo Filippo, parliamo un po' e poi la decisione: "Filippo! Si riscrive il codice del driver da capo, dai!". Filippo mi ha guardato come se lo avessi appena condannato a morte, mandandolo a combattere contro il Leviatano in persona.

Filippo è un programmatore inesperto. E' con noi da poco, mai fatto il programmatore di sistema. Esperienze precedenti: programmazione in Visual Basic, Web, robetta così insomma. Scrivere device driver non l'aveva mai fatto. Per questo era terrorizzato: si vedeva altri 3 - 4 mesi legato a quella sedia a sputare bit. Allora ho deciso di affiancarlo, quattro occhi vedono meglio di 2, e poi un pochinino di esperienza in più di Filippo ce l'ho. Lunedì ci siamo imbarcati in questa insana impresa.

Parentesi: scrivere device driver è anche un po' un'arte. Ci vuole esperienza, e pazienza. Il paragone con il drago non è tanto fantasioso. Quando si scrive il codice di un programma normale (ad esempio un'applicazione web), il programmatore ha a disposizione un bel po' di strumenti sofisticati. Se il codice non funziona, pazienza, correggi l'errore e si riparte subito.
Il programmatore di device driver invece è come lavorasse a mani nude (pardon: a cervello nudo): spesso non riesce neanche a vedere le stampe a video perché il PC ti si pianta completamente prima di vedere qualcosa.

C'è poi un altro problema. Di solito, per scrivere un device driver, si comincia prendendo il manuale tecnico del dispositivo per capire come funziona. Sapete che c'è? che il manuale non collima mai con il dispositivo. Mai. Sembra che gli ingegneri elettronici che progettano queste schede lo facciano apposta per odio contro gli ingegneri informatici che devono scrivere il device driver. Se per cominciare a trasferire un dato bisogna scrivere il valore "5" nella locazione di memoria "13678", sul manuale ci sarà scritto che invece bisogna scriverci "10". Naturalmente, provi a scriverci 10, e non funziona. Allora partono e-mail imploranti verso il support tecnico che, trattandoti da pezza di piedi, ti dice che bisogna scrivere "5" e non "10", non hai letto la FAQ sulla pagina del loro sito web, accessibile cliccando sul link seminascosto in basso a destra? quale link? quello in basso a destra... che non funziona! Insomma, mi avete capito.

Partiamo lunedì, dicevo. Giorni per studiarlo prima da lontano, poi per stanarlo, accerchiarlo. Una lotta acerrima a colpi di LOG_error, e interrupt disable, e interrupt mask, e buffer, e poi giovedì sera il colpo finale: "disabilitiamo gli interrupt in questo punto!", e pochi minuti dopo il drago è caduto.

Giovedì sera il nostro codice ha ricevuto ininterrottamente 5 milioni di pacchetti dati senza mai piantarsi. Non è che sia un codice perfetto: il fornitore dichiara una velocità di trasferimento di 25 Mbit (seee buonanotte), noi se va bene sfioriamo gli 8Mbit. Ah, funziona solo in una modalità, nelle altre si pianta sempre. Però funziona!

Catturare draghi sarà pure difficile, ma il sorriso stampato sulla faccia stanca di Filippo giovedì sera mi ha ripagato di tutto! Vai, avanti il prossimo!

(*) scusate l'analogia, sono stato Dungeon Master da giovane