Lines Matching full:per
30 Per la maggior parte del tempo, la politica descritta in quel file è stata
33 La presenza di quel codice conduce a due distinti pericoli per gli
42 per gli sviluppatori una comprensione veloce di ogni sua parte. Non ci sono,
43 quindi, più spazi per un codice formattato alla carlona.
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
63 (per esempio, una linea che diviene poco leggibile se divisa per rientrare
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
73 per maggiori dettagli
100 spesso per poter usare dei driver su diversi sistemi operativi - vengono
108 più elevato. Non c'è utilità nel replicare lo stesso codice per tutto
115 Il preprocessore C sembra essere una fonte di attrazione per qualche
116 programmatore C, che ci vede una via per ottenere una grande flessibilità
119 da leggere per gli altri e che rende più difficile il lavoro di verifica del
149 chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
171 sotto la licenza GPL e reso disponibile per la sua inclusione nella ramo
173 il supporto per le reti senza fili era considerata, nel migliore dei casi,
180 progettato per girare in un sistema multiprocessore. Prima che questo
187 Persino su sistemi a singolo processore, il lavoro svolto per incrementare
198 per eseguire un compito. Il codice che presenta una mancanza di attenzione
206 miglioramenti) che porterà ad alcune rotture per gli utenti esistenti.
215 un cambiamento se questo porta a nuove funzionalità a dieci sistemi per
230 Questo fatto rende la creazione di interfacce per lo spazio utente
232 incompatibilità, esse devono essere fatte bene al primo colpo. Per questa
239 Almeno per ora la scrittura di codice priva di errori resta un ideale
252 avvertimenti indicano problemi reali. Di regola, il codice inviato per la
254 Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali
259 Costruite il kernel con "make EXTRA_CFLAGS=-W" per ottenerli tutti.
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
267 - ENABLE_MUST_CHECK e FRAME_WARN per ottenere degli
271 preoccuparsi per gli avvertimenti provenienti da altre parti del kernel.
273 - DEBUG_OBJECTS aggiungerà un codice per tracciare il ciclo di vita di
299 (sia per gli sviluppatori che per gli utenti) in un sistema in uso; lockdep
310 Il kernel fornisce un framework per l'inserimento di fallimenti che fa
312 Con l'opzione per l'inserimento dei fallimenti abilitata, una certa percentuale
317 Documentation/fault-injection/fault-injection.rst per avere maggiori
331 soluzioni per risolverli. Un buon numero di "patch semantiche" per il kernel
334 qualsiasi problema trovato. Per maggiori informazioni, consultate
338 per altre architetture. Se non vi accade di avere un sistema S/390 o una
340 di compilazione. Un vasto numero di cross-compilatori per x86 possono
355 facile per gli altri sviluppatori e sarà utile per i vostri utenti. In molti
358 La prima parte di documentazione per qualsiasi patch è il suo changelog.
361 sulle prestazioni e tutto ciò che può servire per la comprensione della
369 con cosa stanno lavorando. Consultate: Documentation/ABI/README per avere una
381 Per molti sottosistemi le informazioni sull'API interna sono documentate sotto
386 per le funzioni disponibili esternamente. Anche in aree che non sono molto
387 documentate, non c'è motivo per non aggiungere commenti kerneldoc per il
388 futuro; infatti, questa può essere un'attività utile per sviluppatori novizi
390 creare modelli per kerneldoc, possono essere trovati in
394 i commenti si fanno maggiormente notare per la loro assenza. Ancora una volta,
397 che non si desiderano commenti prolissi per il codice. Il codice dovrebbe
398 essere, di per sé, leggibile, con dei commenti che spieghino gli aspetti più
403 necessaria. Le regole di sincronizzazione per le strutture dati, generalmente,
432 di tutto il codice del kernel che viene rotto per via della sua modifica.
433 Per una funzione ampiamente usata, questo compito può condurre letteralmente
444 di codice fuori dal kernel che c'è un cambiamento per il quale è necessario del