4.Coding.rst (25154B)
1.. include:: ../disclaimer-ita.rst 2 3:Original: :ref:`Documentation/process/4.Coding.rst <development_coding>` 4:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it> 5 6.. _it_development_coding: 7 8Scrivere codice corretto 9======================== 10 11Nonostante ci sia molto da dire sul processo di creazione, sulla sua solidità 12e sul suo orientamento alla comunità, la prova di ogni progetto di sviluppo 13del kernel si trova nel codice stesso. È il codice che sarà esaminato dagli 14altri sviluppatori ed inserito (o no) nel ramo principale. Quindi è la 15qualità di questo codice che determinerà il successo finale del progetto. 16 17Questa sezione esaminerà il processo di codifica. Inizieremo con uno sguardo 18sulle diverse casistiche nelle quali gli sviluppatori kernel possono 19sbagliare. Poi, l'attenzione si sposterà verso "il fare le cose 20correttamente" e sugli strumenti che possono essere utili in questa missione. 21 22Trappole 23-------- 24 25Lo stile del codice 26******************* 27 28Il kernel ha da tempo delle norme sullo stile di codifica che sono descritte in 29:ref:`Documentation/translations/it_IT/process/coding-style.rst <codingstyle>`. 30Per la maggior parte del tempo, la politica descritta in quel file è stata 31praticamente informativa. Ne risulta che ci sia una quantità sostanziale di 32codice nel kernel che non rispetta le linee guida relative allo stile. 33La presenza di quel codice conduce a due distinti pericoli per gli 34sviluppatori kernel. 35 36Il primo di questi è credere che gli standard di codifica del kernel 37non sono importanti e possono non essere applicati. La verità è che 38aggiungere nuovo codice al kernel è davvero difficile se questo non 39rispetta le norme; molti sviluppatori richiederanno che il codice sia 40riformulato prima che anche solo lo revisionino. Una base di codice larga 41quanto il kernel richiede una certa uniformità, in modo da rendere possibile 42per gli sviluppatori una comprensione veloce di ogni sua parte. Non ci sono, 43quindi, più spazi per un codice formattato alla carlona. 44 45Occasionalmente, lo stile di codifica del kernel andrà in conflitto con lo 46stile richiesto da un datore di lavoro. In alcuni casi, lo stile del kernel 47dovrà prevalere prima che il codice venga inserito. Mettere il codice 48all'interno del kernel significa rinunciare a un certo grado di controllo 49in differenti modi - incluso il controllo sul come formattare il codice. 50 51L’altra trappola è quella di pensare che il codice già presente nel kernel 52abbia urgentemente bisogno di essere sistemato. Gli sviluppatori potrebbero 53iniziare a generare patch che correggono lo stile come modo per prendere 54famigliarità con il processo, o come modo per inserire i propri nomi nei 55changelog del kernel – o entrambe. La comunità di sviluppo vede un attività 56di codifica puramente correttiva come "rumore"; queste attività riceveranno 57una fredda accoglienza. Di conseguenza è meglio evitare questo tipo di patch. 58Mentre si lavora su un pezzo di codice è normale correggerne anche lo stile, 59ma le modifiche di stile non dovrebbero essere fatte fini a se stesse. 60 61Il documento sullo stile del codice non dovrebbe essere letto come una legge 62assoluta che non può mai essere trasgredita. Se c’è un a buona ragione 63(per esempio, una linea che diviene poco leggibile se divisa per rientrare 64nel limite di 80 colonne), fatelo e basta. 65 66Notate che potete utilizzare lo strumento “clang-format” per aiutarvi con 67le regole, per una riformattazione automatica e veloce del vostro codice 68e per revisionare interi file per individuare errori nello stile di codifica, 69refusi e possibili miglioramenti. Inoltre è utile anche per classificare gli 70``#includes``, per allineare variabili/macro, per testi derivati ed altri 71compiti del genere. Consultate il file 72:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>` 73per maggiori dettagli 74 75 76Livelli di astrazione 77********************* 78 79 80I professori di Informatica insegnano ai propri studenti a fare ampio uso dei 81livelli di astrazione nel nome della flessibilità e del nascondere informazioni. 82Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni 83di righe di codice potrebbe fare altrimenti e sopravvivere. Ma l'esperienza 84ha dimostrato che un'eccessiva o prematura astrazione può rivelarsi dannosa 85al pari di una prematura ottimizzazione. L'astrazione dovrebbe essere usata 86fino al livello necessario e non oltre. 87 88Ad un livello base, considerate una funzione che ha un argomento che viene 89sempre impostato a zero da tutti i chiamanti. Uno potrebbe mantenere 90quell'argomento nell'eventualità qualcuno volesse sfruttare la flessibilità 91offerta. In ogni caso, tuttavia, ci sono buone possibilità che il codice 92che va ad implementare questo argomento aggiuntivo, sia stato rotto in maniera 93sottile, in un modo che non è mai stato notato - perché non è mai stato usato. 94Oppure, quando sorge la necessità di avere più flessibilità, questo argomento 95non la fornisce in maniera soddisfacente. Gli sviluppatori di Kernel, 96sottopongono costantemente patch che vanno a rimuovere gli argomenti 97inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti. 98 99I livelli di astrazione che nascondono l'accesso all'hardware - 100spesso per poter usare dei driver su diversi sistemi operativi - vengono 101particolarmente disapprovati. Tali livelli oscurano il codice e possono 102peggiorare le prestazioni; essi non appartengono al kernel Linux. 103 104D'altro canto, se vi ritrovate a dover copiare una quantità significativa di 105codice proveniente da un altro sottosistema del kernel, è tempo di chiedersi 106se, in effetti, non avrebbe più senso togliere parte di quel codice e metterlo 107in una libreria separata o di implementare quella funzionalità ad un livello 108più elevato. Non c'è utilità nel replicare lo stesso codice per tutto 109il kernel. 110 111 112#ifdef e l'uso del preprocessore in generale 113******************************************** 114 115Il preprocessore C sembra essere una fonte di attrazione per qualche 116programmatore C, che ci vede una via per ottenere una grande flessibilità 117all'interno di un file sorgente. Ma il preprocessore non è scritto in C, 118e un suo massiccio impiego conduce a un codice che è molto più difficile 119da leggere per gli altri e che rende più difficile il lavoro di verifica del 120compilatore. L'uso eccessivo del preprocessore è praticamente sempre il segno 121di un codice che necessita di un certo lavoro di pulizia. 122 123La compilazione condizionata con #ifdef è, in effetti, un potente strumento, 124ed esso viene usato all'interno del kernel. Ma esiste un piccolo desiderio: 125quello di vedere il codice coperto solo da una leggera spolverata di 126blocchi #ifdef. Come regola generale, quando possibile, l'uso di #ifdef 127dovrebbe essere confinato nei file d'intestazione. Il codice compilato 128condizionatamente può essere confinato a funzioni tali che, nel caso in cui 129il codice non deve essere presente, diventano vuote. Il compilatore poi 130ottimizzerà la chiamata alla funzione vuota rimuovendola. Il risultato è 131un codice molto più pulito, più facile da seguire. 132 133Le macro del preprocessore C presentano una serie di pericoli, inclusi 134valutazioni multiple di espressioni che hanno effetti collaterali e non 135garantiscono una sicurezza rispetto ai tipi. Se siete tentati dal definire 136una macro, considerate l'idea di creare invece una funzione inline. Il codice 137che ne risulterà sarà lo stesso, ma le funzioni inline sono più leggibili, 138non considerano i propri argomenti più volte, e permettono al compilatore di 139effettuare controlli sul tipo degli argomenti e del valore di ritorno. 140 141 142Funzioni inline 143*************** 144 145Comunque, anche le funzioni inline hanno i loro pericoli. I programmatori 146potrebbero innamorarsi dell'efficienza percepita derivata dalla rimozione 147di una chiamata a funzione. Queste funzioni, tuttavia, possono ridurre le 148prestazioni. Dato che il loro codice viene replicato ovunque vi sia una 149chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato. 150Questi, a turno, creano pressione sulla memoria cache del processore, e questo 151può causare rallentamenti importanti. Le funzioni inline, di norma, dovrebbero 152essere piccole e usate raramente. Il costo di una chiamata a funzione, dopo 153tutto, non è così alto; la creazione di molte funzioni inline è il classico 154esempio di un'ottimizzazione prematura. 155 156In generale, i programmatori del kernel ignorano gli effetti della cache a 157loro rischio e pericolo. Il classico compromesso tempo/spazio teorizzato 158all'inizio delle lezioni sulle strutture dati spesso non si applica 159all'hardware moderno. Lo spazio *è* tempo, in questo senso un programma 160più grande sarà più lento rispetto ad uno più compatto. 161 162I compilatori più recenti hanno preso un ruolo attivo nel decidere se 163una data funzione deve essere resa inline oppure no. Quindi l'uso 164indiscriminato della parola chiave "inline" potrebbe non essere non solo 165eccessivo, ma anche irrilevante. 166 167Sincronizzazione 168**************** 169 170Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna 171sotto la licenza GPL e reso disponibile per la sua inclusione nella ramo 172principale del kernel. Questa donazione fu una notizia bene accolta; 173il supporto per le reti senza fili era considerata, nel migliore dei casi, 174al di sotto degli standard; il sistema Deviscape offrì la promessa di una 175risoluzione a tale situazione. Tuttavia, questo codice non fu inserito nel 176ramo principale fino al giugno del 2007 (2.6.22). Cosa accadde? 177 178Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto 179a porte chiuse. Ma in particolare, un grosso problema fu che non fu 180progettato per girare in un sistema multiprocessore. Prima che questo 181sistema di rete (ora chiamato mac80211) potesse essere inserito, fu necessario 182un lavoro sugli schemi di sincronizzazione. 183 184Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare 185ai problemi di concorrenza presenti nei sistemi multiprocessore. Ora, 186comunque, questo documento è stato scritto su di un portatile dual-core. 187Persino su sistemi a singolo processore, il lavoro svolto per incrementare 188la capacità di risposta aumenterà il livello di concorrenza interno al kernel. 189I giorni nei quali il codice poteva essere scritto senza pensare alla 190sincronizzazione sono da passati tempo. 191 192Ogni risorsa (strutture dati, registri hardware, etc.) ai quali si potrebbe 193avere accesso simultaneo da più di un thread deve essere sincronizzato. Il 194nuovo codice dovrebbe essere scritto avendo tale accortezza in testa; 195riadattare la sincronizzazione a posteriori è un compito molto più difficile. 196Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene 197le primitive di sincronizzazione, in modo da sceglier lo strumento corretto 198per eseguire un compito. Il codice che presenta una mancanza di attenzione 199alla concorrenza avrà un percorso difficile all'interno del ramo principale. 200 201Regressioni 202*********** 203 204Vale la pena menzionare un ultimo pericolo: potrebbe rivelarsi accattivante 205l'idea di eseguire un cambiamento (che potrebbe portare a grandi 206miglioramenti) che porterà ad alcune rotture per gli utenti esistenti. 207Questa tipologia di cambiamento è chiamata "regressione", e le regressioni son 208diventate mal viste nel ramo principale del kernel. Con alcune eccezioni, 209i cambiamenti che causano regressioni saranno fermati se quest'ultime non 210potranno essere corrette in tempo utile. È molto meglio quindi evitare 211la regressione fin dall'inizio. 212 213Spesso si è argomentato che una regressione può essere giustificata se essa 214porta risolve più problemi di quanti non ne crei. Perché, dunque, non fare 215un cambiamento se questo porta a nuove funzionalità a dieci sistemi per 216ognuno dei quali esso determina una rottura? La migliore risposta a questa 217domanda ci è stata fornita da Linus nel luglio 2007: 218 219:: 220 Dunque, noi non sistemiamo bachi introducendo nuovi problemi. Quella 221 via nasconde insidie, e nessuno può sapere del tutto se state facendo 222 dei progressi reali. Sono due passi avanti e uno indietro, oppure 223 un passo avanti e due indietro? 224 225(http://lwn.net/Articles/243460/). 226 227Una particolare tipologia di regressione mal vista consiste in una qualsiasi 228sorta di modifica all'ABI dello spazio utente. Una volta che un'interfaccia 229viene esportata verso lo spazio utente, dev'essere supportata all'infinito. 230Questo fatto rende la creazione di interfacce per lo spazio utente 231particolarmente complicato: dato che non possono venir cambiate introducendo 232incompatibilità, esse devono essere fatte bene al primo colpo. Per questa 233ragione sono sempre richieste: ampie riflessioni, documentazione chiara e 234ampie revisioni dell'interfaccia verso lo spazio utente. 235 236 237Strumenti di verifica del codice 238-------------------------------- 239Almeno per ora la scrittura di codice priva di errori resta un ideale 240irraggiungibile ai più. Quello che speriamo di poter fare, tuttavia, è 241trovare e correggere molti di questi errori prima che il codice entri nel 242ramo principale del kernel. A tal scopo gli sviluppatori del kernel devono 243mettere insieme una schiera impressionante di strumenti che possano 244localizzare automaticamente un'ampia varietà di problemi. Qualsiasi problema 245trovato dal computer è un problema che non affliggerà l'utente in seguito, 246ne consegue che gli strumenti automatici dovrebbero essere impiegati ovunque 247possibile. 248 249Il primo passo consiste semplicemente nel fare attenzione agli avvertimenti 250proveniente dal compilatore. Versioni moderne di gcc possono individuare 251(e segnalare) un gran numero di potenziali errori. Molto spesso, questi 252avvertimenti indicano problemi reali. Di regola, il codice inviato per la 253revisione non dovrebbe produrre nessun avvertimento da parte del compilatore. 254Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali 255e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza 256però averne trovato la causa. 257 258Tenete a mente che non tutti gli avvertimenti sono disabilitati di default. 259Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti. 260 261Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging; 262molti di queste sono trovano all'interno del sotto menu "kernel hacking". 263La maggior parte di queste opzioni possono essere attivate per qualsiasi 264kernel utilizzato per lo sviluppo o a scopo di test. In particolare dovreste 265attivare: 266 267 - FRAME_WARN per ottenere degli avvertimenti su stack frame più 268 grandi di un dato valore. Il risultato generato da questi 269 avvertimenti può risultare verboso, ma non bisogna preoccuparsi per 270 gli avvertimenti provenienti da altre parti del kernel. 271 272 - DEBUG_OBJECTS aggiungerà un codice per tracciare il ciclo di vita di 273 diversi oggetti creati dal kernel e avvisa quando qualcosa viene eseguito 274 fuori controllo. Se state aggiungendo un sottosistema che crea (ed 275 esporta) oggetti complessi propri, considerate l'aggiunta di un supporto 276 al debugging dell'oggetto. 277 278 - DEBUG_SLAB può trovare svariati errori di uso e di allocazione di memoria; 279 esso dovrebbe esser usato dalla maggior parte dei kernel di sviluppo. 280 281 - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo 282 numero di errori comuni di sincronizzazione. 283 284Esistono ancora delle altre opzioni di debugging, di alcune di esse 285discuteremo qui sotto. Alcune di esse hanno un forte impatto e non dovrebbero 286essere usate tutte le volte. Ma qualche volta il tempo speso nell'capire 287le opzioni disponibili porterà ad un risparmio di tempo nel breve termine. 288 289Uno degli strumenti di debugging più tosti è il *locking checker*, o 290"lockdep". Questo strumento traccerà qualsiasi acquisizione e rilascio di 291ogni *lock* (spinlock o mutex) nel sistema, l'ordine con il quale i *lock* 292sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di 293interruzione, eccetera. Inoltre esso può assicurare che i *lock* vengano 294acquisiti sempre nello stesso ordine, che le stesse assunzioni sulle 295interruzioni si applichino in tutte le occasioni, e così via. In altre parole, 296lockdep può scovare diversi scenari nei quali il sistema potrebbe, in rari 297casi, trovarsi in stallo. Questa tipologia di problema può essere grave 298(sia per gli sviluppatori che per gli utenti) in un sistema in uso; lockdep 299permette di trovare tali problemi automaticamente e in anticipo. 300 301In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare 302il valore di ritorno di ogni operazione (come l'allocazione della memoria) 303poiché esso potrebbe fallire. Il nocciolo della questione è che i percorsi 304di gestione degli errori, con grande probabilità, non sono mai stati 305collaudati del tutto. Il codice collaudato tende ad essere codice bacato; 306potrete quindi essere più a vostro agio con il vostro codice se tutti questi 307percorsi fossero stati verificati un po' di volte. 308 309Il kernel fornisce un framework per l'inserimento di fallimenti che fa 310esattamente al caso, specialmente dove sono coinvolte allocazioni di memoria. 311Con l'opzione per l'inserimento dei fallimenti abilitata, una certa percentuale 312di allocazione di memoria sarà destinata al fallimento; questi fallimenti 313possono essere ridotti ad uno specifico pezzo di codice. Procedere con 314l'inserimento dei fallimenti attivo permette al programmatore di verificare 315come il codice risponde quando le cose vanno male. Consultate: 316Documentation/fault-injection/fault-injection.rst per avere maggiori 317informazioni su come utilizzare questo strumento. 318 319Altre tipologie di errori possono essere riscontrati con lo strumento di 320analisi statica "sparse". Con Sparse, il programmatore può essere avvisato 321circa la confusione tra gli indirizzi dello spazio utente e dello spazio 322kernel, un miscuglio fra quantità big-endian e little-endian, il passaggio 323di un valore intero dove ci sia aspetta un gruppo di flag, e così via. 324Sparse deve essere installato separatamente (se il vostra distribuzione non 325lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page); 326può essere attivato sul codice aggiungendo "C=1" al comando make. 327 328Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare 329una vasta varietà di potenziali problemi di codifica; e può inoltre proporre 330soluzioni per risolverli. Un buon numero di "patch semantiche" per il kernel 331sono state preparate nella cartella scripts/coccinelle; utilizzando 332"make coccicheck" esso percorrerà tali patch semantiche e farà rapporto su 333qualsiasi problema trovato. Per maggiori informazioni, consultate 334:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`. 335 336Altri errori di portabilità sono meglio scovati compilando il vostro codice 337per altre architetture. Se non vi accade di avere un sistema S/390 o una 338scheda di sviluppo Blackfin sotto mano, potete comunque continuare la fase 339di compilazione. Un vasto numero di cross-compilatori per x86 possono 340essere trovati al sito: 341 342 http://www.kernel.org/pub/tools/crosstool/ 343 344Il tempo impiegato nell'installare e usare questi compilatori sarà d'aiuto 345nell'evitare situazioni imbarazzanti nel futuro. 346 347 348Documentazione 349-------------- 350 351La documentazione è spesso stata più un'eccezione che una regola nello 352sviluppo del kernel. Nonostante questo, un'adeguata documentazione aiuterà 353a facilitare l'inserimento di nuovo codice nel kernel, rende la vita più 354facile per gli altri sviluppatori e sarà utile per i vostri utenti. In molti 355casi, la documentazione è divenuta sostanzialmente obbligatoria. 356 357La prima parte di documentazione per qualsiasi patch è il suo changelog. 358Questi dovrebbero descrivere le problematiche risolte, la tipologia di 359soluzione, le persone che lavorano alla patch, ogni effetto rilevante 360sulle prestazioni e tutto ciò che può servire per la comprensione della 361patch. Assicuratevi che il changelog dica *perché*, vale la pena aggiungere 362la patch; un numero sorprendente di sviluppatori sbaglia nel fornire tale 363informazione. 364 365Qualsiasi codice che aggiunge una nuova interfaccia in spazio utente - inclusi 366nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale 367interfaccia così da permette agli sviluppatori dello spazio utente di sapere 368con cosa stanno lavorando. Consultate: Documentation/ABI/README per avere una 369descrizione di come questi documenti devono essere impostati e quali 370informazioni devono essere fornite. 371 372Il file :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst <kernelparameters>` 373descrive tutti i parametri di avvio del kernel. Ogni patch che aggiunga 374nuovi parametri dovrebbe aggiungere nuove voci a questo file. 375 376Ogni nuova configurazione deve essere accompagnata da un testo di supporto 377che spieghi chiaramente le opzioni e spieghi quando l'utente potrebbe volerle 378selezionare. 379 380Per molti sottosistemi le informazioni sull'API interna sono documentate sotto 381forma di commenti formattati in maniera particolare; questi commenti possono 382essere estratti e formattati in differenti modi attraverso lo script 383"kernel-doc". Se state lavorando all'interno di un sottosistema che ha 384commenti kerneldoc dovreste mantenerli e aggiungerli, in maniera appropriata, 385per le funzioni disponibili esternamente. Anche in aree che non sono molto 386documentate, non c'è motivo per non aggiungere commenti kerneldoc per il 387futuro; infatti, questa può essere un'attività utile per sviluppatori novizi 388del kernel. Il formato di questi commenti, assieme alle informazione su come 389creare modelli per kerneldoc, possono essere trovati in 390:ref:`Documentation/translations/it_IT/doc-guide/ <doc_guide>`. 391 392Chiunque legga un ammontare significativo di codice kernel noterà che, spesso, 393i commenti si fanno maggiormente notare per la loro assenza. Ancora una volta, 394le aspettative verso il nuovo codice sono più alte rispetto al passato; 395inserire codice privo di commenti sarà più difficile. Detto ciò, va aggiunto 396che non si desiderano commenti prolissi per il codice. Il codice dovrebbe 397essere, di per sé, leggibile, con dei commenti che spieghino gli aspetti più 398sottili. 399 400Determinate cose dovrebbero essere sempre commentate. L'uso di barriere 401di memoria dovrebbero essere accompagnate da una riga che spieghi perché sia 402necessaria. Le regole di sincronizzazione per le strutture dati, generalmente, 403necessitano di una spiegazioni da qualche parte. Le strutture dati più 404importanti, in generale, hanno bisogno di una documentazione onnicomprensiva. 405Le dipendenze che non sono ovvie tra bit separati di codice dovrebbero essere 406indicate. Tutto ciò che potrebbe indurre un inserviente del codice a fare 407una "pulizia" incorretta, ha bisogno di un commento che dica perché è stato 408fatto in quel modo. E così via. 409 410Cambiamenti interni dell'API 411---------------------------- 412 413L'interfaccia binaria fornita dal kernel allo spazio utente non può essere 414rotta tranne che in circostanze eccezionali. L'interfaccia di programmazione 415interna al kernel, invece, è estremamente fluida e può essere modificata al 416bisogno. Se vi trovate a dover lavorare attorno ad un'API del kernel o 417semplicemente non state utilizzando una funzionalità offerta perché questa 418non rispecchia i vostri bisogni, allora questo potrebbe essere un segno che 419l'API ha bisogno di essere cambiata. In qualità di sviluppatore del kernel, 420hai il potere di fare questo tipo di modifica. 421 422Ci sono ovviamente alcuni punti da cogliere. I cambiamenti API possono essere 423fatti, ma devono essere giustificati. Quindi ogni patch che porta ad una 424modifica dell'API interna dovrebbe essere accompagnata da una descrizione 425della modifica in sé e del perché essa è necessaria. Questo tipo di 426cambiamenti dovrebbero, inoltre, essere fatti in una patch separata, invece di 427essere sepolti all'interno di una patch più grande. 428 429L'altro punto da cogliere consiste nel fatto che uno sviluppatore che 430modifica l'API deve, in generale, essere responsabile della correzione 431di tutto il codice del kernel che viene rotto per via della sua modifica. 432Per una funzione ampiamente usata, questo compito può condurre letteralmente 433a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con 434il lavoro svolto da altri sviluppatori. Non c'è bisogno di dire che questo 435può essere un lavoro molto grosso, quindi è meglio essere sicuri che la 436motivazione sia ben solida. Notate che lo strumento Coccinelle può fornire 437un aiuto con modifiche estese dell'API. 438 439Quando viene fatta una modifica API incompatibile, una persona dovrebbe, 440quando possibile, assicurarsi che quel codice non aggiornato sia trovato 441dal compilatore. Questo vi aiuterà ad essere sicuri d'avere trovato, 442tutti gli usi di quell'interfaccia. Inoltre questo avviserà gli sviluppatori 443di codice fuori dal kernel che c'è un cambiamento per il quale è necessario del 444lavoro. Il supporto al codice fuori dal kernel non è qualcosa di cui gli 445sviluppatori del kernel devono preoccuparsi, ma non dobbiamo nemmeno rendere 446più difficile del necessario la vita agli sviluppatori di questo codice.