it_IT/process/4.Coding.rst

1 .. include:: ../disclaimer-ita.rst
13 del kernel si trova nel codice stesso.  È il codice che sarà esaminato dagli
18 sulle diverse casistiche nelle quali gli sviluppatori kernel possono
20 correttamente" e sugli strumenti che possono essere utili in questa missione.
23 --------
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
32 codice nel kernel che non rispetta le linee guida relative allo stile.
34 sviluppatori kernel.
36 Il primo di questi è credere che gli standard di codifica del kernel
38 aggiungere nuovo codice al kernel è davvero difficile se questo non
41 quanto il kernel richiede una certa uniformità, in modo da rendere possibile
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
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.
51 L’altra trappola è quella di pensare che il codice già presente nel kernel
55 changelog del kernel – o entrambe.  La comunità di sviluppo vede un attività
66 Notate che potete utilizzare lo strumento “clang-format” per aiutarvi con
72 :ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
86 Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni
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.
99 non la fornisce in maniera soddisfacente.  Gli sviluppatori di Kernel,
101 inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti.
103 I livelli di astrazione che nascondono l'accesso all'hardware -
104 spesso per poter usare dei driver su diversi sistemi operativi - vengono
106 peggiorare le prestazioni; essi non appartengono al kernel Linux.
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
113 il kernel.
116 #ifdef e l'uso del preprocessore in generale
121 all'interno di un file sorgente.  Ma il preprocessore non è scritto in C,
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:
132 condizionatamente può essere confinato a funzioni tali che, nel caso in cui
153 chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
160 In generale, i programmatori del kernel ignorano gli effetti della cache a
163 all'hardware moderno.  Lo spazio *è* tempo, in questo senso un programma
174 Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
176 principale del kernel.  Questa donazione fu una notizia bene accolta;
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
188 Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare
190 comunque, questo documento è stato scritto su di un portatile dual-core.
192 la capacità di risposta aumenterà il livello di concorrenza interno al kernel.
198 nuovo codice dovrebbe essere scritto avendo tale accortezza in testa;
200 Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
201 le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
212 diventate mal viste nel ramo principale del kernel.  Con alcune eccezioni,
214 potranno essere corrette in tempo utile.  È molto meglio quindi evitare
231 Una particolare tipologia di regressione mal vista consiste in una qualsiasi
242 --------------------------------
246 ramo principale del kernel.  A tal scopo gli sviluppatori del kernel devono
249 trovato dal computer è un problema che non affliggerà l'utente in seguito,
263 Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti.
265 Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging;
266 molti di queste sono trovano all'interno del sotto menu "kernel hacking".
268 kernel utilizzato per lo sviluppo o a scopo di test.  In particolare dovreste
271  - FRAME_WARN per ottenere degli avvertimenti su stack frame più
274    gli avvertimenti provenienti da altre parti del kernel.
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
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.
285  - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo
296 sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
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.
305 In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare
313 Il kernel fornisce un framework per l'inserimento di fallimenti che fa
320 Documentation/fault-injection/fault-injection.rst per avere maggiori
326 kernel, un miscuglio fra quantità big-endian e little-endian, il passaggio
329 lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page);
332 Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare
334 soluzioni per risolverli.  Un buon numero di "patch semantiche" per il kernel
338 :ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`.
343 di compilazione.  Un vasto numero di cross-compilatori per x86 possono
346 	http://www.kernel.org/pub/tools/crosstool/
353 --------------
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
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
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
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
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>`.
396 Chiunque legga un ammontare significativo di codice kernel noterà che, spesso,
408 importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
412 fatto in quel modo.  E così via.
415 ----------------------------
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
423 l'API ha bisogno di essere cambiata.  In qualità di sviluppatore del kernel,
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
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.
437 a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con
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