xref: /linux-master/Documentation/translations/it_IT/process/4.Coding.rst

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/4.Coding.rst <development_coding>`
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>

.. _it_development_coding:

Scrivere codice corretto
========================

Nonostante ci sia molto da dire sul processo di creazione, sulla sua solidit��
e sul suo orientamento alla comunit��, la prova di ogni progetto di sviluppo
del kernel si trova nel codice stesso.  �� il codice che sar�� esaminato dagli
altri sviluppatori ed inserito (o no) nel ramo principale. Quindi �� la
qualit�� di questo codice che determiner�� il successo finale del progetto.

Questa sezione esaminer�� il processo di codifica.  Inizieremo con uno sguardo
sulle diverse casistiche nelle quali gli sviluppatori kernel possono
sbagliare.  Poi, l'attenzione si sposter�� verso "il fare le cose
correttamente" e sugli strumenti che possono essere utili in questa missione.

Trappole
--------

Lo stile del codice
*******************

Il kernel ha da tempo delle norme sullo stile di codifica che sono descritte in
:ref:`Documentation/translations/it_IT/process/coding-style.rst <codingstyle>`.
Per la maggior parte del tempo, la politica descritta in quel file �� stata
praticamente informativa.  Ne risulta che ci sia una quantit�� sostanziale di
codice nel kernel che non rispetta le linee guida relative allo stile.
La presenza di quel codice conduce a due distinti pericoli per gli
sviluppatori kernel.

Il primo di questi �� credere che gli standard di codifica del kernel
non sono importanti e possono non essere applicati.  La verit�� �� che
aggiungere nuovo codice al kernel �� davvero difficile se questo non
rispetta le norme; molti sviluppatori richiederanno che il codice sia
riformulato prima che anche solo lo revisionino.  Una base di codice larga
quanto il kernel richiede una certa uniformit��, in modo da rendere possibile
per gli sviluppatori una comprensione veloce di ogni sua parte.  Non ci sono,
quindi, pi�� spazi per un codice formattato alla carlona.

Occasionalmente, lo stile di codifica del kernel andr�� in conflitto con lo
stile richiesto da un datore di lavoro.  In alcuni casi, lo stile del kernel
dovr�� prevalere prima che il codice venga inserito.  Mettere il codice
all'interno del kernel significa rinunciare a un certo grado di controllo
in differenti modi - incluso il controllo sul come formattare il codice.

L���altra trappola �� quella di pensare che il codice gi�� presente nel kernel
abbia urgentemente bisogno di essere sistemato.  Gli sviluppatori potrebbero
iniziare a generare patch che correggono lo stile come modo per prendere
famigliarit�� con il processo, o come modo per inserire i propri nomi nei
changelog del kernel ��� o entrambe.  La comunit�� di sviluppo vede un attivit��
di codifica puramente correttiva come "rumore"; queste attivit�� riceveranno
una fredda accoglienza.  Di conseguenza �� meglio evitare questo tipo di patch.
Mentre si lavora su un pezzo di codice �� normale correggerne anche lo stile,
ma le modifiche di stile non dovrebbero essere fatte fini a se stesse.

Il documento sullo stile del codice non dovrebbe essere letto come una legge
assoluta che non pu�� mai essere trasgredita.  Se c����� un a buona ragione
(per esempio, una linea che diviene poco leggibile se divisa per rientrare
nel limite di 80 colonne), fatelo e basta.

Notate che potete utilizzare lo strumento ���clang-format��� per aiutarvi con
le regole, per una riformattazione automatica e veloce del vostro codice
e per revisionare interi file per individuare errori nello stile di codifica,
refusi e possibili miglioramenti.  Inoltre �� utile anche per classificare gli
``#includes``, per allineare variabili/macro, per testi derivati ed altri
compiti del genere.  Consultate il file
:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
per maggiori dettagli


Livelli di astrazione
*********************


I professori di Informatica insegnano ai propri studenti a fare ampio uso dei
livelli di astrazione nel nome della flessibilit�� e del nascondere informazioni.
Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni
di righe di codice potrebbe fare altrimenti e sopravvivere.  Ma l'esperienza
ha dimostrato che un'eccessiva o prematura astrazione pu�� rivelarsi dannosa
al pari di una prematura ottimizzazione.  L'astrazione dovrebbe essere usata
fino al livello necessario e non oltre.

Ad un livello base, considerate una funzione che ha un argomento che viene
sempre impostato a zero da tutti i chiamanti.  Uno potrebbe mantenere
quell'argomento nell'eventualit�� qualcuno volesse sfruttare la flessibilit��
offerta.  In ogni caso, tuttavia, ci sono buone possibilit�� che il codice
che va ad implementare questo argomento aggiuntivo, sia stato rotto in maniera
sottile, in un modo che non �� mai stato notato - perch�� non �� mai stato usato.
Oppure, quando sorge la necessit�� di avere pi�� flessibilit��, questo argomento
non la fornisce in maniera soddisfacente.  Gli sviluppatori di Kernel,
sottopongono costantemente patch che vanno a rimuovere gli argomenti
inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti.

I livelli di astrazione che nascondono l'accesso all'hardware -
spesso per poter usare dei driver su diversi sistemi operativi - vengono
particolarmente disapprovati.  Tali livelli oscurano il codice e possono
peggiorare le prestazioni; essi non appartengono al kernel Linux.

D'altro canto, se vi ritrovate a dover copiare una quantit�� significativa di
codice proveniente da un altro sottosistema del kernel, �� tempo di chiedersi
se, in effetti, non avrebbe pi�� senso togliere parte di quel codice e metterlo
in una libreria separata o di implementare quella funzionalit�� ad un livello
pi�� elevato.  Non c'�� utilit�� nel replicare lo stesso codice per tutto
il kernel.


#ifdef e l'uso del preprocessore in generale
********************************************

Il preprocessore C sembra essere una fonte di attrazione per qualche
programmatore C, che ci vede una via per ottenere una grande flessibilit��
all'interno di un file sorgente.  Ma il preprocessore non �� scritto in C,
e un suo massiccio impiego conduce a un codice che �� molto pi�� difficile
da leggere per gli altri e che rende pi�� difficile il lavoro di verifica del
compilatore.  L'uso eccessivo del preprocessore �� praticamente sempre il segno
di un codice che necessita di un certo lavoro di pulizia.

La compilazione condizionata con #ifdef ��, in effetti, un potente strumento,
ed esso viene usato all'interno del kernel.  Ma esiste un piccolo desiderio:
quello di vedere il codice coperto solo da una leggera spolverata di
blocchi #ifdef.  Come regola generale, quando possibile, l'uso di #ifdef
dovrebbe essere confinato nei file d'intestazione.  Il codice compilato
condizionatamente pu�� essere confinato a funzioni tali che, nel caso in cui
il codice non deve essere presente, diventano vuote.  Il compilatore poi
ottimizzer�� la chiamata alla funzione vuota rimuovendola.  Il risultato ��
un codice molto pi�� pulito, pi�� facile da seguire.

Le macro del preprocessore C presentano una serie di pericoli, inclusi
valutazioni multiple di espressioni che hanno effetti collaterali e non
garantiscono una sicurezza rispetto ai tipi.  Se siete tentati dal definire
una macro, considerate l'idea di creare invece una funzione inline.  Il codice
che ne risulter�� sar�� lo stesso, ma le funzioni inline sono pi�� leggibili,
non considerano i propri argomenti pi�� volte, e permettono al compilatore di
effettuare controlli sul tipo degli argomenti e del valore di ritorno.


Funzioni inline
***************

Comunque, anche le funzioni inline hanno i loro pericoli.  I programmatori
potrebbero innamorarsi dell'efficienza percepita derivata dalla rimozione
di una chiamata a funzione.  Queste funzioni, tuttavia, possono ridurre le
prestazioni.  Dato che il loro codice viene replicato ovunque vi sia una
chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
Questi, a turno, creano pressione sulla memoria cache del processore, e questo
pu�� causare rallentamenti importanti.  Le funzioni inline, di norma, dovrebbero
essere piccole e usate raramente.  Il costo di una chiamata a funzione, dopo
tutto, non �� cos�� alto; la creazione di molte funzioni inline �� il classico
esempio di un'ottimizzazione prematura.

In generale, i programmatori del kernel ignorano gli effetti della cache a
loro rischio e pericolo.  Il classico compromesso tempo/spazio teorizzato
all'inizio delle lezioni sulle strutture dati spesso non si applica
all'hardware moderno.  Lo spazio *��* tempo, in questo senso un programma
pi�� grande sar�� pi�� lento rispetto ad uno pi�� compatto.

I compilatori pi�� recenti hanno preso un ruolo attivo nel decidere se
una data funzione deve essere resa inline oppure no.  Quindi l'uso
indiscriminato della parola chiave "inline" potrebbe non essere non solo
eccessivo, ma anche irrilevante.

Sincronizzazione
****************

Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
sotto la licenza GPL e reso disponibile per la sua inclusione nella ramo
principale del kernel.  Questa donazione fu una notizia bene accolta;
il supporto per le reti senza fili era considerata, nel migliore dei casi,
al di sotto degli standard; il sistema Deviscape offr�� la promessa di una
risoluzione a tale situazione.  Tuttavia, questo codice non fu inserito nel
ramo principale fino al giugno del 2007 (2.6.22). Cosa accadde?

Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto
a porte chiuse.  Ma in particolare, un grosso problema fu che non fu
progettato per girare in un sistema multiprocessore.  Prima che questo
sistema di rete (ora chiamato mac80211) potesse essere inserito, fu necessario
un lavoro sugli schemi di sincronizzazione.

Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare
ai problemi di concorrenza presenti nei sistemi multiprocessore.  Ora,
comunque, questo documento �� stato scritto su di un portatile dual-core.
Persino su sistemi a singolo processore, il lavoro svolto per incrementare
la capacit�� di risposta aumenter�� il livello di concorrenza interno al kernel.
I giorni nei quali il codice poteva essere scritto senza pensare alla
sincronizzazione sono da passati tempo.

Ogni risorsa (strutture dati, registri hardware, etc.) ai quali si potrebbe
avere accesso simultaneo da pi�� di un thread deve essere sincronizzato.  Il
nuovo codice dovrebbe essere scritto avendo tale accortezza in testa;
riadattare la sincronizzazione a posteriori �� un compito molto pi�� difficile.
Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
per eseguire un compito.  Il codice che presenta una mancanza di attenzione
alla concorrenza avr�� un percorso difficile all'interno del ramo principale.

Regressioni
***********

Vale la pena menzionare un ultimo pericolo: potrebbe rivelarsi accattivante
l'idea di eseguire un cambiamento (che potrebbe portare a grandi
miglioramenti) che porter�� ad alcune rotture per gli utenti esistenti.
Questa tipologia di cambiamento �� chiamata "regressione", e le regressioni son
diventate mal viste nel ramo principale del kernel.  Con alcune eccezioni,
i cambiamenti che causano regressioni saranno fermati se quest'ultime non
potranno essere corrette in tempo utile.  �� molto meglio quindi evitare
la regressione fin dall'inizio.

Spesso si �� argomentato che una regressione pu�� essere giustificata se essa
porta risolve pi�� problemi di quanti non ne crei.  Perch��, dunque, non fare
un cambiamento se questo porta a nuove funzionalit�� a dieci sistemi per
ognuno dei quali esso determina una rottura?  La migliore risposta a questa
domanda ci �� stata fornita da Linus nel luglio 2007:

::
   Dunque, noi non sistemiamo bachi introducendo nuovi problemi. Quella
   via nasconde insidie, e nessuno pu�� sapere del tutto se state facendo
   dei progressi reali. Sono due passi avanti e uno indietro, oppure
   un passo avanti e due indietro?

(http://lwn.net/Articles/243460/).

Una particolare tipologia di regressione mal vista consiste in una qualsiasi
sorta di modifica all'ABI dello spazio utente.  Una volta che un'interfaccia
viene esportata verso lo spazio utente, dev'essere supportata all'infinito.
Questo fatto rende la creazione di interfacce per lo spazio utente
particolarmente complicato: dato che non possono venir cambiate introducendo
incompatibilit��, esse devono essere fatte bene al primo colpo.  Per questa
ragione sono sempre richieste: ampie riflessioni, documentazione chiara e
ampie revisioni dell'interfaccia verso lo spazio utente.


Strumenti di verifica del codice
--------------------------------
Almeno per ora la scrittura di codice priva di errori resta un ideale
irraggiungibile ai pi��.  Quello che speriamo di poter fare, tuttavia, ��
trovare e correggere molti di questi errori prima che il codice entri nel
ramo principale del kernel.  A tal scopo gli sviluppatori del kernel devono
mettere insieme una schiera impressionante di strumenti che possano
localizzare automaticamente un'ampia variet�� di problemi.  Qualsiasi problema
trovato dal computer �� un problema che non affligger�� l'utente in seguito,
ne consegue che gli strumenti automatici dovrebbero essere impiegati ovunque
possibile.

Il primo passo consiste semplicemente nel fare attenzione agli avvertimenti
proveniente dal compilatore.  Versioni moderne di gcc possono individuare
(e segnalare) un gran numero di potenziali errori.  Molto spesso, questi
avvertimenti indicano problemi reali.  Di regola, il codice inviato per la
revisione non dovrebbe produrre nessun avvertimento da parte del compilatore.
Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali
e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza
per�� averne trovato la causa.

Tenete a mente che non tutti gli avvertimenti sono disabilitati di default.
Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti.

Il kernel fornisce differenti opzioni che abilitano funzionalit�� di debugging;
molti di queste sono trovano all'interno del sotto menu "kernel hacking".
La maggior parte di queste opzioni possono essere attivate per qualsiasi
kernel utilizzato per lo sviluppo o a scopo di test.  In particolare dovreste
attivare:

 - FRAME_WARN per ottenere degli avvertimenti su stack frame pi��
   grandi di un dato valore.  Il risultato generato da questi
   avvertimenti pu�� risultare verboso, ma non bisogna preoccuparsi per
   gli avvertimenti provenienti da altre parti del kernel.

 - DEBUG_OBJECTS aggiunger�� un codice per tracciare il ciclo di vita di
   diversi oggetti creati dal kernel e avvisa quando qualcosa viene eseguito
   fuori controllo.  Se state aggiungendo un sottosistema che crea (ed
   esporta) oggetti complessi propri, considerate l'aggiunta di un supporto
   al debugging dell'oggetto.

 - DEBUG_SLAB pu�� trovare svariati errori di uso e di allocazione di memoria;
   esso dovrebbe esser usato dalla maggior parte dei kernel di sviluppo.

 - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo
   numero di errori comuni di sincronizzazione.

Esistono ancora delle altre opzioni di debugging, di alcune di esse
discuteremo qui sotto.  Alcune di esse hanno un forte impatto e non dovrebbero
essere usate tutte le volte.  Ma qualche volta il tempo speso nell'capire
le opzioni disponibili porter�� ad un risparmio di tempo nel breve termine.

Uno degli strumenti di debugging pi�� tosti �� il *locking checker*, o
"lockdep".  Questo strumento traccer�� qualsiasi acquisizione e rilascio di
ogni *lock* (spinlock o mutex) nel sistema, l'ordine con il quale i *lock*
sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
interruzione, eccetera.  Inoltre esso pu�� assicurare che i *lock* vengano
acquisiti sempre nello stesso ordine, che le stesse assunzioni sulle
interruzioni si applichino in tutte le occasioni, e cos�� via.  In altre parole,
lockdep pu�� scovare diversi scenari nei quali il sistema potrebbe, in rari
casi, trovarsi in stallo.  Questa tipologia di problema pu�� essere grave
(sia per gli sviluppatori che per gli utenti) in un sistema in uso; lockdep
permette di trovare tali problemi automaticamente e in anticipo.

In qualit�� di programmatore kernel diligente, senza dubbio, dovrete controllare
il valore di ritorno di ogni operazione (come l'allocazione della memoria)
poich�� esso potrebbe fallire.  Il nocciolo della questione �� che i percorsi
di gestione degli errori, con grande probabilit��, non sono mai stati
collaudati del tutto.  Il codice collaudato tende ad essere codice bacato;
potrete quindi essere pi�� a vostro agio con il vostro codice se tutti questi
percorsi fossero stati verificati un po' di volte.

Il kernel fornisce un framework per l'inserimento di fallimenti che fa
esattamente al caso, specialmente dove sono coinvolte allocazioni di memoria.
Con l'opzione per l'inserimento dei fallimenti abilitata, una certa percentuale
di allocazione di memoria sar�� destinata al fallimento; questi fallimenti
possono essere ridotti ad uno specifico pezzo di codice.  Procedere con
l'inserimento dei fallimenti attivo permette al programmatore di verificare
come il codice risponde quando le cose vanno male.  Consultate:
Documentation/fault-injection/fault-injection.rst per avere maggiori
informazioni su come utilizzare questo strumento.

Altre tipologie di errori possono essere riscontrati con lo strumento di
analisi statica "sparse".  Con Sparse, il programmatore pu�� essere avvisato
circa la confusione tra gli indirizzi dello spazio utente e dello spazio
kernel, un miscuglio fra quantit�� big-endian e little-endian, il passaggio
di un valore intero dove ci sia aspetta un gruppo di flag, e cos�� via.
Sparse deve essere installato separatamente (se il vostra distribuzione non
lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page);
pu�� essere attivato sul codice aggiungendo "C=1" al comando make.

Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) �� in grado di trovare
una vasta variet�� di potenziali problemi di codifica; e pu�� inoltre proporre
soluzioni per risolverli.  Un buon numero di "patch semantiche" per il kernel
sono state preparate nella cartella scripts/coccinelle; utilizzando
"make coccicheck" esso percorrer�� tali patch semantiche e far�� rapporto su
qualsiasi problema trovato.  Per maggiori informazioni, consultate
:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`.

Altri errori di portabilit�� sono meglio scovati compilando il vostro codice
per altre architetture.  Se non vi accade di avere un sistema S/390 o una
scheda di sviluppo Blackfin sotto mano, potete comunque continuare la fase
di compilazione.  Un vasto numero di cross-compilatori per x86 possono
essere trovati al sito:

	http://www.kernel.org/pub/tools/crosstool/

Il tempo impiegato nell'installare e usare questi compilatori sar�� d'aiuto
nell'evitare situazioni imbarazzanti nel futuro.


Documentazione
--------------

La documentazione �� spesso stata pi�� un'eccezione che una regola nello
sviluppo del kernel.  Nonostante questo, un'adeguata documentazione aiuter��
a facilitare l'inserimento di nuovo codice nel kernel, rende la vita pi��
facile per gli altri sviluppatori e sar�� utile per i vostri utenti.  In molti
casi, la documentazione �� divenuta sostanzialmente obbligatoria.

La prima parte di documentazione per qualsiasi patch �� il suo changelog.
Questi dovrebbero descrivere le problematiche risolte, la tipologia di
soluzione, le persone che lavorano alla patch, ogni effetto rilevante
sulle prestazioni e tutto ci�� che pu�� servire per la comprensione della
patch.  Assicuratevi che il changelog dica *perch��*, vale la pena aggiungere
la patch; un numero sorprendente di sviluppatori sbaglia nel fornire tale
informazione.

Qualsiasi codice che aggiunge una nuova interfaccia in spazio utente - inclusi
nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale
interfaccia cos�� da permette agli sviluppatori dello spazio utente di sapere
con cosa stanno lavorando.  Consultate: Documentation/ABI/README per avere una
descrizione di come questi documenti devono essere impostati e quali
informazioni devono essere fornite.

Il file :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst <kernelparameters>`
descrive tutti i parametri di avvio del kernel.  Ogni patch che aggiunga
nuovi parametri dovrebbe aggiungere nuove voci a questo file.

Ogni nuova configurazione deve essere accompagnata da un testo di supporto
che spieghi chiaramente le opzioni e spieghi quando l'utente potrebbe volerle
selezionare.

Per molti sottosistemi le informazioni sull'API interna sono documentate sotto
forma di commenti formattati in maniera particolare; questi commenti possono
essere estratti e formattati in differenti modi attraverso lo script
"kernel-doc".  Se state lavorando all'interno di un sottosistema che ha
commenti kerneldoc dovreste mantenerli e aggiungerli, in maniera appropriata,
per le funzioni disponibili esternamente.  Anche in aree che non sono molto
documentate, non c'�� motivo per non aggiungere commenti kerneldoc per il
futuro; infatti, questa pu�� essere un'attivit�� utile per sviluppatori novizi
del kernel.  Il formato di questi commenti, assieme alle informazione su come
creare modelli per kerneldoc, possono essere trovati in
:ref:`Documentation/translations/it_IT/doc-guide/ <doc_guide>`.

Chiunque legga un ammontare significativo di codice kernel noter�� che, spesso,
i commenti si fanno maggiormente notare per la loro assenza.  Ancora una volta,
le aspettative verso il nuovo codice sono pi�� alte rispetto al passato;
inserire codice privo di commenti sar�� pi�� difficile.  Detto ci��, va aggiunto
che non si desiderano commenti prolissi per il codice.  Il codice dovrebbe
essere, di per s��, leggibile, con dei commenti che spieghino gli aspetti pi��
sottili.

Determinate cose dovrebbero essere sempre commentate.  L'uso di barriere
di memoria dovrebbero essere accompagnate da una riga che spieghi perch�� sia
necessaria.  Le regole di sincronizzazione per le strutture dati, generalmente,
necessitano di una spiegazioni da qualche parte.  Le strutture dati pi��
importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
Le dipendenze che non sono ovvie tra bit separati di codice dovrebbero essere
indicate.  Tutto ci�� che potrebbe indurre un inserviente del codice a fare
una "pulizia" incorretta, ha bisogno di un commento che dica perch�� �� stato
fatto in quel modo.  E cos�� via.

Cambiamenti interni dell'API
----------------------------

L'interfaccia binaria fornita dal kernel allo spazio utente non pu�� essere
rotta tranne che in circostanze eccezionali.  L'interfaccia di programmazione
interna al kernel, invece, �� estremamente fluida e pu�� essere modificata al
bisogno.  Se vi trovate a dover lavorare attorno ad un'API del kernel o
semplicemente non state utilizzando una funzionalit�� offerta perch�� questa
non rispecchia i vostri bisogni, allora questo potrebbe essere un segno che
l'API ha bisogno di essere cambiata.  In qualit�� di sviluppatore del kernel,
hai il potere di fare questo tipo di modifica.

Ci sono ovviamente alcuni punti da cogliere.  I cambiamenti API possono essere
fatti, ma devono essere giustificati.  Quindi ogni patch che porta ad una
modifica dell'API interna dovrebbe essere accompagnata da una descrizione
della modifica in s�� e del perch�� essa �� necessaria.  Questo tipo di
cambiamenti dovrebbero, inoltre, essere fatti in una patch separata, invece di
essere sepolti all'interno di una patch pi�� grande.

L'altro punto da cogliere consiste nel fatto che uno sviluppatore che
modifica l'API deve, in generale, essere responsabile della correzione
di tutto il codice del kernel che viene rotto per via della sua modifica.
Per una funzione ampiamente usata, questo compito pu�� condurre letteralmente
a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con
il lavoro svolto da altri sviluppatori.  Non c'�� bisogno di dire che questo
pu�� essere un lavoro molto grosso, quindi �� meglio essere sicuri che la
motivazione sia ben solida.  Notate che lo strumento Coccinelle pu�� fornire
un aiuto con modifiche estese dell'API.

Quando viene fatta una modifica API incompatibile, una persona dovrebbe,
quando possibile, assicurarsi che quel codice non aggiornato sia trovato
dal compilatore.  Questo vi aiuter�� ad essere sicuri d'avere trovato,
tutti gli usi di quell'interfaccia.  Inoltre questo avviser�� gli sviluppatori
di codice fuori dal kernel che c'�� un cambiamento per il quale �� necessario del
lavoro.  Il supporto al codice fuori dal kernel non �� qualcosa di cui gli
sviluppatori del kernel devono preoccuparsi, ma non dobbiamo nemmeno rendere
pi�� difficile del necessario la vita agli sviluppatori di questo codice.