Lines Matching refs:di
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
15 qualità di questo codice che determinerà il successo finale del progetto.
17 Questa sezione esaminerà il processo di codifica. Inizieremo con uno sguardo
28 Il kernel ha da tempo delle norme sullo stile di codifica che sono descritte in
31 praticamente informativa. Ne risulta che ci sia una quantità sostanziale di
33 La presenza di quel codice conduce a due distinti pericoli per gli
36 Il primo di questi è credere che gli standard di codifica del kernel
40 riformulato prima che anche solo lo revisionino. Una base di codice larga
42 per gli sviluppatori una comprensione veloce di ogni sua parte. Non ci sono,
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
51 L’altra trappola è quella di pensare che il codice già presente nel kernel
52 abbia urgentemente bisogno di essere sistemato. Gli sviluppatori potrebbero
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.
64 nel limite di 80 colonne), fatelo e basta.
68 e per revisionare interi file per individuare errori nello stile di codifica,
76 Livelli di astrazione
80 I professori di Informatica insegnano ai propri studenti a fare ampio uso dei
81 livelli di astrazione nel nome della flessibilità e del nascondere informazioni.
83 di righe di codice potrebbe fare altrimenti e sopravvivere. Ma l'esperienza
85 al pari di una prematura ottimizzazione. L'astrazione dovrebbe essere usata
94 Oppure, quando sorge la necessità di avere più flessibilità, questo argomento
95 non la fornisce in maniera soddisfacente. Gli sviluppatori di Kernel,
99 I livelli di astrazione che nascondono l'accesso all'hardware -
104 D'altro canto, se vi ritrovate a dover copiare una quantità significativa di
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
115 Il preprocessore C sembra essere una fonte di attrazione per qualche
117 all'interno di un file sorgente. Ma il preprocessore non è scritto in C,
119 da leggere per gli altri e che rende più difficile il lavoro di verifica del
121 di un codice che necessita di un certo lavoro di pulizia.
125 quello di vedere il codice coperto solo da una leggera spolverata di
126 blocchi #ifdef. Come regola generale, quando possibile, l'uso di #ifdef
133 Le macro del preprocessore C presentano una serie di pericoli, inclusi
134 valutazioni multiple di espressioni che hanno effetti collaterali e non
136 una macro, considerate l'idea di creare invece una funzione inline. Il codice
138 non considerano i propri argomenti più volte, e permettono al compilatore di
139 effettuare controlli sul tipo degli argomenti e del valore di ritorno.
147 di una chiamata a funzione. Queste funzioni, tuttavia, possono ridurre le
151 può causare rallentamenti importanti. Le funzioni inline, di norma, dovrebbero
152 essere piccole e usate raramente. Il costo di una chiamata a funzione, dopo
153 tutto, non è così alto; la creazione di molte funzioni inline è il classico
154 esempio di un'ottimizzazione prematura.
170 Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
174 al di sotto degli standard; il sistema Deviscape offrì la promessa di una
178 Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto
181 sistema di rete (ora chiamato mac80211) potesse essere inserito, fu necessario
182 un lavoro sugli schemi di sincronizzazione.
185 ai problemi di concorrenza presenti nei sistemi multiprocessore. Ora,
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.
193 avere accesso simultaneo da più di un thread deve essere sincronizzato. Il
196 Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
197 le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
198 per eseguire un compito. Il codice che presenta una mancanza di attenzione
205 l'idea di eseguire un cambiamento (che potrebbe portare a grandi
207 Questa tipologia di cambiamento è chiamata "regressione", e le regressioni son
214 porta risolve più problemi di quanti non ne crei. Perché, dunque, non fare
227 Una particolare tipologia di regressione mal vista consiste in una qualsiasi
228 sorta di modifica all'ABI dello spazio utente. Una volta che un'interfaccia
230 Questo fatto rende la creazione di interfacce per lo spazio utente
237 Strumenti di verifica del codice
239 Almeno per ora la scrittura di codice priva di errori resta un ideale
240 irraggiungibile ai più. Quello che speriamo di poter fare, tuttavia, è
241 trovare e correggere molti di questi errori prima che il codice entri nel
243 mettere insieme una schiera impressionante di strumenti che possano
244 localizzare automaticamente un'ampia varietà di problemi. Qualsiasi problema
250 proveniente dal compilatore. Versioni moderne di gcc possono individuare
251 (e segnalare) un gran numero di potenziali errori. Molto spesso, questi
254 Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali
255 e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza
258 Tenete a mente che non tutti gli avvertimenti sono disabilitati di default.
261 Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging;
262 molti di queste sono trovano all'interno del sotto menu "kernel hacking".
263 La maggior parte di queste opzioni possono essere attivate per qualsiasi
264 kernel utilizzato per lo sviluppo o a scopo di test. In particolare dovreste
268 grandi di un dato valore. Il risultato generato da questi
272 - DEBUG_OBJECTS aggiungerà un codice per tracciare il ciclo di vita di
275 esporta) oggetti complessi propri, considerate l'aggiunta di un supporto
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.
282 numero di errori comuni di sincronizzazione.
284 Esistono ancora delle altre opzioni di debugging, di alcune di esse
285 discuteremo qui sotto. Alcune di esse hanno un forte impatto e non dovrebbero
287 le opzioni disponibili porterà ad un risparmio di tempo nel breve termine.
289 Uno degli strumenti di debugging più tosti è il *locking checker*, o
290 "lockdep". Questo strumento traccerà qualsiasi acquisizione e rilascio di
292 sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
297 casi, trovarsi in stallo. Questa tipologia di problema può essere grave
299 permette di trovare tali problemi automaticamente e in anticipo.
301 In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare
302 il valore di ritorno di ogni operazione (come l'allocazione della memoria)
304 di gestione degli errori, con grande probabilità, non sono mai stati
307 percorsi fossero stati verificati un po' di volte.
309 Il kernel fornisce un framework per l'inserimento di fallimenti che fa
310 esattamente al caso, specialmente dove sono coinvolte allocazioni di memoria.
312 di allocazione di memoria sarà destinata al fallimento; questi fallimenti
313 possono essere ridotti ad uno specifico pezzo di codice. Procedere con
314 l'inserimento dei fallimenti attivo permette al programmatore di verificare
319 Altre tipologie di errori possono essere riscontrati con lo strumento di
323 di un valore intero dove ci sia aspetta un gruppo di flag, e così via.
328 Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare
329 una vasta varietà di potenziali problemi di codifica; e può inoltre proporre
330 soluzioni per risolverli. Un buon numero di "patch semantiche" per il kernel
336 Altri errori di portabilità sono meglio scovati compilando il vostro codice
337 per altre architetture. Se non vi accade di avere un sistema S/390 o una
338 scheda di sviluppo Blackfin sotto mano, potete comunque continuare la fase
339 di compilazione. Un vasto numero di cross-compilatori per x86 possono
353 a facilitare l'inserimento di nuovo codice nel kernel, rende la vita più
357 La prima parte di documentazione per qualsiasi patch è il suo changelog.
358 Questi dovrebbero descrivere le problematiche risolte, la tipologia di
362 la patch; un numero sorprendente di sviluppatori sbaglia nel fornire tale
366 nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale
367 interfaccia così da permette agli sviluppatori dello spazio utente di sapere
369 descrizione di come questi documenti devono essere impostati e quali
373 descrive tutti i parametri di avvio del kernel. Ogni patch che aggiunga
376 Ogni nuova configurazione deve essere accompagnata da un testo di supporto
381 forma di commenti formattati in maniera particolare; questi commenti possono
383 "kernel-doc". Se state lavorando all'interno di un sottosistema che ha
388 del kernel. Il formato di questi commenti, assieme alle informazione su come
392 Chiunque legga un ammontare significativo di codice kernel noterà che, spesso,
395 inserire codice privo di commenti sarà più difficile. Detto ciò, va aggiunto
397 essere, di per sé, leggibile, con dei commenti che spieghino gli aspetti più
400 Determinate cose dovrebbero essere sempre commentate. L'uso di barriere
401 di memoria dovrebbero essere accompagnate da una riga che spieghi perché sia
402 necessaria. Le regole di sincronizzazione per le strutture dati, generalmente,
403 necessitano di una spiegazioni da qualche parte. Le strutture dati più
404 importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
405 Le dipendenze che non sono ovvie tra bit separati di codice dovrebbero essere
407 una "pulizia" incorretta, ha bisogno di un commento che dica perché è stato
414 rotta tranne che in circostanze eccezionali. L'interfaccia di programmazione
419 l'API ha bisogno di essere cambiata. In qualità di sviluppatore del kernel,
420 hai il potere di fare questo tipo di modifica.
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
427 essere sepolti all'interno di una patch più grande.
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
434 il lavoro svolto da altri sviluppatori. Non c'è bisogno di dire che questo
442 tutti gli usi di quell'interfaccia. Inoltre questo avviserà gli sviluppatori
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
446 più difficile del necessario la vita agli sviluppatori di questo codice.