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>`
82 Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni
91 offerta.  In ogni caso, tuttavia, ci sono buone possibilità che il codice
92 che va ad implementare questo argomento aggiuntivo, sia stato rotto in maniera
93 sottile, in un modo che non è mai stato notato - perché non è mai stato usato.
95 non la fornisce in maniera soddisfacente.  Gli sviluppatori di Kernel,
97 inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti.
99 I livelli di astrazione che nascondono l'accesso all'hardware -
100 spesso per poter usare dei driver su diversi sistemi operativi - vengono
102 peggiorare le prestazioni; essi non appartengono al kernel Linux.
105 codice proveniente da un altro sottosistema del kernel, è tempo di chiedersi
106 se, in effetti, non avrebbe più senso togliere parte di quel codice e metterlo
107 in una libreria separata o di implementare quella funzionalità ad un livello
109 il kernel.
112 #ifdef e l'uso del preprocessore in generale
117 all'interno di un file sorgente.  Ma il preprocessore non è scritto in C,
123 La compilazione condizionata con #ifdef è, in effetti, un potente strumento,
124 ed esso viene usato all'interno del kernel.  Ma esiste un piccolo desiderio:
128 condizionatamente può essere confinato a funzioni tali che, nel caso in cui
149 chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
156 In generale, i programmatori del kernel ignorano gli effetti della cache a
159 all'hardware moderno.  Lo spazio *è* tempo, in questo senso un programma
170 Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
172 principale del kernel.  Questa donazione fu una notizia bene accolta;
178 Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto
179 a porte chiuse.  Ma in particolare, un grosso problema fu che non fu
180 progettato per girare in un sistema multiprocessore.  Prima che questo
184 Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare
186 comunque, questo documento è stato scritto su di un portatile dual-core.
188 la capacità di risposta aumenterà il livello di concorrenza interno al kernel.
194 nuovo codice dovrebbe essere scritto avendo tale accortezza in testa;
196 Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
197 le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
208 diventate mal viste nel ramo principale del kernel.  Con alcune eccezioni,
210 potranno essere corrette in tempo utile.  È molto meglio quindi evitare
227 Una particolare tipologia di regressione mal vista consiste in una qualsiasi
238 --------------------------------
242 ramo principale del kernel.  A tal scopo gli sviluppatori del kernel devono
245 trovato dal computer è un problema che non affliggerà l'utente in seguito,
259 Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti.
261 Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging;
262 molti di queste sono trovano all'interno del sotto menu "kernel hacking".
264 kernel utilizzato per lo sviluppo o a scopo di test.  In particolare dovreste
267  - FRAME_WARN per ottenere degli avvertimenti su stack frame più
270    gli avvertimenti provenienti da altre parti del kernel.
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
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.
281  - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo
292 sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
295 interruzioni si applichino in tutte le occasioni, e così via.  In altre parole,
296 lockdep può scovare diversi scenari nei quali il sistema potrebbe, in rari
297 casi, 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
299 permette di trovare tali problemi automaticamente e in anticipo.
301 In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare
309 Il kernel fornisce un framework per l'inserimento di fallimenti che fa
316 Documentation/fault-injection/fault-injection.rst per avere maggiori
322 kernel, un miscuglio fra quantità big-endian e little-endian, il passaggio
325 lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page);
328 Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare
330 soluzioni per risolverli.  Un buon numero di "patch semantiche" per il kernel
334 :ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`.
339 di compilazione.  Un vasto numero di cross-compilatori per x86 possono
342 	http://www.kernel.org/pub/tools/crosstool/
349 --------------
352 sviluppo del kernel.  Nonostante questo, un'adeguata documentazione aiuterà
353 a facilitare l'inserimento di nuovo codice nel kernel, rende la vita più
354 facile per gli altri sviluppatori e sarà utile per i vostri utenti.  In molti
365 Qualsiasi codice che aggiunge una nuova interfaccia in spazio utente - inclusi
366 nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale
372 Il file :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst <kernelparameters>`
373 descrive tutti i parametri di avvio del kernel.  Ogni patch che aggiunga
381 forma di commenti formattati in maniera particolare; questi commenti possono
382 essere estratti e formattati in differenti modi attraverso lo script
383 "kernel-doc".  Se state lavorando all'interno di un sottosistema che ha
384 commenti kerneldoc dovreste mantenerli e aggiungerli, in maniera appropriata,
385 per le funzioni disponibili esternamente.  Anche in aree che non sono molto
388 del kernel.  Il formato di questi commenti, assieme alle informazione su come
389 creare modelli per kerneldoc, possono essere trovati in
390 :ref:`Documentation/translations/it_IT/doc-guide/ <doc_guide>`.
392 Chiunque legga un ammontare significativo di codice kernel noterà che, spesso,
404 importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
408 fatto in quel modo.  E così via.
411 ----------------------------
413 L'interfaccia binaria fornita dal kernel allo spazio utente non può essere
414 rotta tranne che in circostanze eccezionali.  L'interfaccia di programmazione
415 interna al kernel, invece, è estremamente fluida e può essere modificata al
416 bisogno.  Se vi trovate a dover lavorare attorno ad un'API del kernel o
419 l'API ha bisogno di essere cambiata.  In qualità di sviluppatore del kernel,
425 della modifica in sé e del perché essa è necessaria.  Questo tipo di
426 cambiamenti dovrebbero, inoltre, essere fatti in una patch separata, invece di
430 modifica l'API deve, in generale, essere responsabile della correzione
431 di tutto il codice del kernel che viene rotto per via della sua modifica.
433 a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con
443 di codice fuori dal kernel che c'è un cambiamento per il quale è necessario del
444 lavoro.  Il supporto al codice fuori dal kernel non è qualcosa di cui gli
445 sviluppatori del kernel devono preoccuparsi, ma non dobbiamo nemmeno rendere