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