diff options
Diffstat (limited to 'Documentation/translations/it_IT')
25 files changed, 793 insertions, 405 deletions
diff --git a/Documentation/translations/it_IT/riscv/patch-acceptance.rst b/Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst index 2d7afb1f6959..e0ad63643f1b 100644 --- a/Documentation/translations/it_IT/riscv/patch-acceptance.rst +++ b/Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-ita.rst +.. include:: ../../disclaimer-ita.rst -:Original: :doc:`../../../arch/riscv/patch-acceptance` +:Original: :doc:`../../../../arch/riscv/patch-acceptance` :Translator: Federico Vaga <federico.vaga@vaga.pv.it> arch/riscv linee guida alla manutenzione per gli sviluppatori @@ -22,6 +22,26 @@ sperimentale. Desideriamo estendere questi stessi principi al codice relativo all'architettura RISC-V che verrà accettato per l'inclusione nel kernel. +Patchwork +--------- + +RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch: + + https://patchwork.kernel.org/project/linux-riscv/list/ + +Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V +hanno probabilmente richiesto delle modifiche o si aspettano che venga applicata +a un altro albero. + +Il processo automatico viene eseguito su questa istanza di patchwork, costruendo +e collaudando le patch man mano che arrivano. Il processo applica le patch al +riferimento HEAD corrente dei rami `for-next` e `fixes` dei sorgenti RISC-V, +questo a seconda che la patch sia stata o meno individuata come correzione. In +caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è +stata applicata una serie di patch sarà annotato su patchwork. È improbabile che +vengano applicate Le patch che non passano i controlli, nella maggior parte dei +casi dovranno essere ripresentate. + In aggiunta alla lista delle verifiche da fare prima di inviare una patch ------------------------------------------------------------------------- diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index 17abc25ee4c1..6ee713988531 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -43,7 +43,7 @@ Tenete presente che per via dell'espansione delle macro questo argomento deve essere un simbolo di preprocessore. Per esempio per esportare il simbolo ``usb_stor_suspend`` nello spazio dei nomi ``USB_STORAGE`` usate:: - EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + EXPORT_SYMBOL_NS(usb_stor_suspend, "USB_STORAGE"); Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce rappresentata dalla struttura ``kernel_symbol`` che avrà il campo @@ -69,7 +69,7 @@ Per esempio per esportare tutti i simboli definiti in usb-common nello spazio dei nomi USB_COMMON, si può aggiungere la seguente linea in drivers/usb/common/Makefile:: - ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE='"USB_COMMON"' Questo cambierà tutte le macro EXPORT_SYMBOL() ed EXPORT_SYMBOL_GPL(). Invece, un simbolo esportato con EXPORT_SYMBOL_NS() non verrà cambiato e il simbolo @@ -79,7 +79,7 @@ Una seconda possibilità è quella di definire il simbolo di preprocessore direttamente nei file da compilare. L'esempio precedente diventerebbe:: #undef DEFAULT_SYMBOL_NAMESPACE - #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + #define DEFAULT_SYMBOL_NAMESPACE "USB_COMMON" Questo va messo prima di un qualsiasi uso di EXPORT_SYMBOL. @@ -94,7 +94,7 @@ dei nomi che contiene i simboli desiderati. Per esempio un modulo che usa il simbolo usb_stor_suspend deve importare lo spazio dei nomi USB_STORAGE usando la seguente dichiarazione:: - MODULE_IMPORT_NS(USB_STORAGE); + MODULE_IMPORT_NS("USB_STORAGE"); Questo creerà un'etichetta ``modinfo`` per ogni spazio dei nomi importato. Un risvolto di questo fatto è che gli spazi dei diff --git a/Documentation/translations/it_IT/process/clang-format.rst b/Documentation/translations/it_IT/dev-tools/clang-format.rst index 29f83c198025..6fab07772da0 100644 --- a/Documentation/translations/it_IT/process/clang-format.rst +++ b/Documentation/translations/it_IT/dev-tools/clang-format.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :ref:`Documentation/process/clang-format.rst <clangformat>` +:Original: :ref:`Documentation/dev-tools/clang-format.rst <clangformat>` :Translator: Federico Vaga <federico.vaga@vaga.pv.it> .. _it_clangformat: diff --git a/Documentation/translations/it_IT/dev-tools/index.rst b/Documentation/translations/it_IT/dev-tools/index.rst new file mode 100644 index 000000000000..3d3ed9d15ea1 --- /dev/null +++ b/Documentation/translations/it_IT/dev-tools/index.rst @@ -0,0 +1,17 @@ +.. include:: ../disclaimer-ita.rst + +:Original: Documentation/dev-tools/index.rst + +=================================== +Strumenti di sviluppo per il kernel +=================================== + +Qui raccogliamo i vari documenti riguardanti gli strumenti di sviluppo che +possono essere usati per lavorare col kernel . Per ora, questa è una raccolta +senza un particolare struttura; si accettano patch! + +.. toctree:: + :caption: Tabella dei contenuti + :maxdepth: 2 + + clang-format diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst index 5cece223b46b..aa0e31d353d6 100644 --- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst +++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst @@ -180,9 +180,9 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome se provate a formattare bene il vostro testo come nel seguente esempio:: * Return: - * 0 - OK - * -EINVAL - invalid argument - * -ENOMEM - out of memory + * %0 - OK + * %-EINVAL - invalid argument + * %-ENOMEM - out of memory le righe verranno unite e il risultato sarà:: @@ -192,8 +192,8 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome utilizzare una lista ReST, ad esempio:: * Return: - * * 0 - OK to runtime suspend the device - * * -EBUSY - Device should not be runtime suspended + * * %0 - OK to runtime suspend the device + * * %-EBUSY - Device should not be runtime suspended #) Se il vostro testo ha delle righe che iniziano con una frase seguita dai due punti, allora ognuna di queste frasi verrà considerata come il nome @@ -370,6 +370,50 @@ Anche i tipi di dato per prototipi di funzione possono essere documentati:: */ typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2); +Documentazione di macro simili a oggetti +---------------------------------------- + +Le macro simili a oggetti si distinguono dalle macro simili a funzione. Esse si +distinguono in base al fatto che il nome della macro simile a funzione sia +immediatamente seguito da una parentesi sinistra ('(') mentre in quelle simili a +oggetti no. + +Le macro simili a funzioni sono gestite come funzioni da ``scripts/kernel-doc``. +Possono avere un elenco di parametri. Le macro simili a oggetti non hanno un +elenco di parametri. + +Il formato generale di un commento kernel-doc per una macro simile a oggetti è:: + + /** + * define object_name - Brief description. + * + * Description of the object. + */ + +Esempio:: + + /** + * define MAX_ERRNO - maximum errno value that is supported + * + * Kernel pointers have redundant information, so we can use a + * scheme where we can return either an error code or a normal + * pointer with the same return value. + */ + #define MAX_ERRNO 4095 + +Esempio:: + + /** + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \ + * Initializes struct drm_plane_helper_funcs for VRAM handling + * + * This macro initializes struct drm_plane_helper_funcs to use the + * respective helper functions. + */ + #define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \ + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \ + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb + Marcatori e riferimenti ----------------------- diff --git a/Documentation/translations/it_IT/doc-guide/parse-headers.rst b/Documentation/translations/it_IT/doc-guide/parse-headers.rst index c7076a21667a..026a23e49767 100644 --- a/Documentation/translations/it_IT/doc-guide/parse-headers.rst +++ b/Documentation/translations/it_IT/doc-guide/parse-headers.rst @@ -63,7 +63,7 @@ DESCRIZIONE *********** Converte un file d'intestazione o un file sorgente C (C_FILE) in un testo -ReStructuredText incluso mediante il blocco ..parsed-literal +reStructuredText incluso mediante il blocco ..parsed-literal con riferimenti alla documentazione che descrive l'API. Opzionalmente, il programma accetta anche un altro file (EXCEPTIONS_FILE) che descrive quali elementi debbano essere ignorati o il cui riferimento diff --git a/Documentation/translations/it_IT/i2c/summary.rst b/Documentation/translations/it_IT/i2c/summary.rst index 1535e13a32e2..99a5b36cfb44 100644 --- a/Documentation/translations/it_IT/i2c/summary.rst +++ b/Documentation/translations/it_IT/i2c/summary.rst @@ -3,21 +3,17 @@ Introduzione a I2C e SMBus ========================== I²C (letteralmente "I al quadrato C" e scritto I2C nella documentazione del -kernel) è un protocollo sviluppato da Philips. É un protocollo lento a 2 fili -(a velocità variabile, al massimo 400KHz), con un'estensione per le velocità -elevate (3.4 MHz). Questo protocollo offre un bus a basso costo per collegare -dispositivi di vario genere a cui si accede sporadicamente e utilizzando -poca banda. Alcuni sistemi usano varianti che non rispettano i requisiti -originali, per cui non sono indicati come I2C, ma hanno nomi diversi, per -esempio TWI (Interfaccia a due fili), IIC. +kernel) è un protocollo sviluppato da Philips. É un protocollo a 2 fili (a +velocità variabile, solitamente fino a 400KHz, e in modalità alta velocità fino +a 5 MHz). Questo protocollo offre un bus a basso costo per collegare dispositivi +di vario genere a cui si accede sporadicamente e utilizzando poca banda. I2C è +ampiamente usato nei sistemi integrati. Alcuni sistemi usano varianti che non +rispettano i requisiti originali, per cui non sono indicati come I2C, ma hanno +nomi diversi, per esempio TWI (Interfaccia a due fili), IIC. L'ultima specifica ufficiale I2C è la `"Specifica I2C-bus e manuale utente" -(UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_ -pubblicata da NXP Semiconductors. Tuttavia, è necessario effettuare il login -al sito per accedere al PDF. Una versione precedente della specifica -(revisione 6) è archiviata -`qui <https://web.archive.org/web/20210813122132/ -https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_. +(UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_ pubblicata da +NXP Semiconductors, al momento della scrittura si tratta della versione 7 SMBus (Bus per la gestione del sistema) si basa sul protocollo I2C ed è principalmente un sottoinsieme di protocolli e segnali I2C. Molti dispositivi @@ -27,38 +23,62 @@ SMBus. I più comuni dispositivi collegati tramite SMBus sono moduli RAM configurati utilizzando EEPROM I2C, e circuiti integrati di monitoraggio hardware. -Poiché SMBus è principalmente un sottoinsieme del bus I2C, -possiamo farne uso su molti sistemi I2C. Ci sono però sistemi che non -soddisfano i vincoli elettrici sia di SMBus che di I2C; e altri che non possono -implementare tutta la semantica o messaggi comuni del protocollo SMBus. +Poiché SMBus è principalmente un sottoinsieme del bus I2C, possiamo farne uso su +molti sistemi I2C. Ci sono però sistemi che non soddisfano i vincoli elettrici +sia di SMBus che di I2C; e altri che non possono implementare tutta la semantica +o messaggi comuni del protocollo SMBus. Terminologia ============ -Utilizzando la terminologia della documentazione ufficiale, il bus I2C connette -uno o più circuiti integrati *master* e uno o più circuiti integrati *slave*. +Il bus I2C connette uno o più circuiti integrati controllori a dei dispositivi. .. kernel-figure:: ../../../i2c/i2c_bus.svg - :alt: Un semplice bus I2C con un master e 3 slave + :alt: Un semplice bus I2C con un controllore e 3 dispositivi Un semplice Bus I2C -Un circuito integrato **master** è un nodo che inizia le comunicazioni con gli -slave. Nell'implementazione del kernel Linux è chiamato **adattatore** o bus. I -driver degli adattatori si trovano nella sottocartella ``drivers/i2c/busses/``. +Un circuito integrato **controllore** (*controller*) è un nodo che inizia le +comunicazioni con i dispositivi (*targets*). Nell'implementazione del kernel +Linux è chiamato **adattatore** o bus. I driver degli adattatori si trovano +nella sottocartella ``drivers/i2c/busses/``. Un **algoritmo** contiene codice generico che può essere utilizzato per implementare una intera classe di adattatori I2C. Ciascun driver dell' adattatore specifico dipende da un driver dell'algoritmo nella sottocartella ``drivers/i2c/algos/`` o include la propria implementazione. -Un circuito integrato **slave** è un nodo che risponde alle comunicazioni -quando indirizzato dal master. In Linux è chiamato **client** (dispositivo). I -driver dei dispositivi sono contenuti in una cartella specifica per la +Un circuito integrato **dispositivo** è un nodo che risponde alle comunicazioni +quando indirizzato dal controllore. In Linux è chiamato **client**. Nonostante i +dispositivi siano circuiti integrati esterni al sistema, Linux può agire come +dispositivo (se l'hardware lo permette) e rispondere alla richieste di altri +controllori sul bus. Questo verrà chiamato **dispositivo locale** (*local +target*). Negli altri casi si parla di **dispositivo remoto** (*remote target*). + +I driver dei dispositivi sono contenuti in una cartella specifica per la funzionalità che forniscono, ad esempio ``drivers/media/gpio/`` per espansori GPIO e ``drivers/media/i2c/`` per circuiti integrati relativi ai video. Per la configurazione di esempio in figura, avrai bisogno di un driver per il tuo adattatore I2C e driver per i tuoi dispositivi I2C (solitamente un driver per ciascuno dispositivo). + +Sinonimi +-------- + +Come menzionato precedentemente, per ragioni storiche l'implementazione I2C del +kernel Linux usa "adatattore" (*adapter*) per i controllori e "client" per i +dispositivi. Un certo numero di strutture dati usano questi sinonimi nei loro +nomi. Dunque, durante le discussioni riguardanti l'implementazione dovrete +essere a coscienza anche di questi termini. Tuttavia si preferiscono i termini +ufficiali. + +Terminologia obsoleta +--------------------- + +Nelle prime specifiche di I2C, il controllore veniva chiamato "master" ed i +dispositivi "slave". Questi termini sono stati resi obsoleti con la versione 7 +della specifica. Inoltre, il loro uso viene scoraggiato dal codice di condotta +del kernel Linux. Tuttavia, potreste ancora trovare questi termini in pagine non +aggiornate. In generale si cerca di usare i termini controllore e dispositivo. diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index 70ccd23b2cde..afa680607750 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -103,9 +103,11 @@ sviluppatori del kernel. .. toctree:: :maxdepth: 1 - process/license-rules - doc-guide/index - kernel-hacking/index + Regole sulle licenze <process/license-rules> + Scrivere la documentazione <doc-guide/index> + Strumenti di sviluppo <dev-tools/index> + La guida all'*hacking*<kernel-hacking/index> + Documentazione per gli utenti ============================= @@ -132,4 +134,4 @@ Documentazione varia Ci sono documenti che sono difficili da inserire nell'attuale organizzazione della documentazione; altri hanno bisogno di essere migliorati e/o convertiti -nel formato *ReStructured Text*; altri sono semplicamente troppo vecchi. +nel formato *reStructuredText*; altri sono semplicamente troppo vecchi. diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst index 25cd00351c03..6262c3908665 100644 --- a/Documentation/translations/it_IT/process/2.Process.rst +++ b/Documentation/translations/it_IT/process/2.Process.rst @@ -424,10 +424,10 @@ o entrambi. Molte delle liste di discussione del Kernel girano su vger.kernel.org; l'elenco principale lo si trova sul sito: - http://vger.kernel.org/vger-lists.html + https://subspace.kernel.org -Esistono liste gestite altrove; un certo numero di queste sono in -redhat.com/mailman/listinfo. +Tuttavia, esistono liste gestite altrove; controllare il file MAINTAINERS per +trovare la lista relativa ad un sottosistema specifico. La lista di discussione principale per lo sviluppo del kernel è, ovviamente, linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono @@ -462,9 +462,12 @@ linux-kernel: di far domande. Molti sviluppatori possono divenire impazienti con le persone che chiaramente non hanno svolto i propri compiti a casa. -- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra - alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta - difficile da leggere e genera scarsa impressione. +- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle + vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di + rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli + leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst + <it_interleaved_replies>`. + - Chiedete nella lista di discussione corretta. Linux-kernel può essere un punto di incontro generale, ma non è il miglior posto dove trovare diff --git a/Documentation/translations/it_IT/process/4.Coding.rst b/Documentation/translations/it_IT/process/4.Coding.rst index 54fd255b77d0..3126342c4b4a 100644 --- a/Documentation/translations/it_IT/process/4.Coding.rst +++ b/Documentation/translations/it_IT/process/4.Coding.rst @@ -69,9 +69,13 @@ e per revisionare interi file per individuare errori nello stile di codifica, refusi e possibili miglioramenti. Inoltre è utile anche per classificare gli ``#includes``, per allineare variabili/macro, per testi derivati ed altri compiti del genere. Consultate il file -:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>` +:ref:`Documentation/translations/it_IT/dev-tools/clang-format.rst <clangformat>` per maggiori dettagli +Se utilizzate un programma compatibile con EditorConfig, allora alcune +configurazioni basilari come l'indentazione e la fine delle righe verranno +applicate automaticamente. Per maggiori informazioni consultate la pagina: +https://editorconfig.org/ Livelli di astrazione ********************* diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst index a7e2a3238415..3b9b4db6fb9a 100644 --- a/Documentation/translations/it_IT/process/5.Posting.rst +++ b/Documentation/translations/it_IT/process/5.Posting.rst @@ -208,11 +208,6 @@ di commit in un sistema di controllo di versione. Sarà seguito da: l'opzione "-p" assocerà alla modifica il nome della funzione alla quale si riferisce, rendendo il risultato più facile da leggere per gli altri. -Dovreste evitare di includere nelle patch delle modifiche per file -irrilevanti (quelli generati dal processo di generazione, per esempio, o i file -di backup del vostro editor). Il file "dontdiff" nella cartella Documentation -potrà esservi d'aiuto su questo punto; passatelo a diff con l'opzione "-X". - Le etichette sopracitate danno un'idea di come una patch prende vita e sono descritte nel dettaglio nel documento :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`. @@ -223,8 +218,9 @@ Un'etichetta ci può dire quale commit ha introdotto il problema che viene corre Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti -maggiori informazioni, per esempio un rapporto circa il baco risolto dalla -patch, oppure un documento con le specifiche implementate dalla patch:: +maggiori informazioni, per esempio una discussione avvenuta precedentemente +circa il baco risolto dalla patch, oppure un documento con le specifiche +implementate dalla patch:: Link: https://example.com/somewhere.html optional-other-stuff @@ -233,7 +229,19 @@ alla più recente discussione pubblica. A volte questo è fatto automaticamente alcuni strumenti come b4 or un *hook* git come quello descritto qui 'Documentation/translations/it_IT/maintainer/configure-git.rst' -Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo + +Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch, +allora usate l'etichetta "Closes:":: + + Closes: https://example.com/issues/1234 optional-other-stuff + +Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere +automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni +automatismi che monitorano la liste di discussione possono anche tracciare +queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono +proibiti. + +Un altro tipo di etichetta viene usato per indicare chi ha contribuito allo sviluppo della patch. Tutte queste etichette seguono il formato:: tag: Full Name <email address> optional-other-stuff @@ -267,7 +275,13 @@ Le etichette in uso più comuni sono: - Reported-by: menziona l'utente che ha riportato il problema corretto da questa patch; quest'etichetta viene usata per dare credito alle persone che hanno verificato il codice e ci hanno fatto sapere quando le cose non - funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora + funzionavano correttamente. Questa etichetta dovrebbe essere seguita da + quella Closes: con un indirizzo al rapporto, a meno che questo non sia + disponibile sul web. L'etichetta Link: può essere usata in alternativa a + Closes: se la patch corregge solo in parte il problema riportato nel + rapporto. + + Se esiste un rapporto disponibile sul web, allora L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto diff --git a/Documentation/translations/it_IT/process/6.Followthrough.rst b/Documentation/translations/it_IT/process/6.Followthrough.rst index df7d5fb28832..685eee5690f3 100644 --- a/Documentation/translations/it_IT/process/6.Followthrough.rst +++ b/Documentation/translations/it_IT/process/6.Followthrough.rst @@ -60,6 +60,13 @@ resa molto più facile se tenete presente alcuni dettagli: stanno lavorando per la creazione del miglior kernel possibile; non stanno cercando di creare un disagio ad aziende concorrenti. + - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di + codifica e a richieste di trasferire parte del vostro codice in parti + condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere + lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma + nel vostro driver per aggirare un problema deve diventare una caratteristica + generalizzata del kernel pronta per essere riutilizzata. + Quello che si sta cercando di dire è che, quando i revisori vi inviano degli appunti dovete fare attenzione alle osservazioni tecniche che vi stanno facendo. Non lasciate che il loro modo di esprimersi o il vostro orgoglio diff --git a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst index dffd813a0910..b3d8b62f3b57 100644 --- a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst +++ b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst @@ -160,6 +160,8 @@ preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano, e verificherà che vi siate ricordati di pubblicare quelle patch su un server pubblico. +.. _development_advancedtopics_reviews_it: + Revisionare le patch -------------------- @@ -180,6 +182,13 @@ i commenti come domande e non come critiche. Chiedere "Come viene rilasciato il *lock* in questo percorso?" funziona sempre molto meglio che "qui la sincronizzazione è sbagliata". +In caso di disaccordi, può essere utile chiedere una terza opinione. Se dopo +pochi scambi la discussione raggiunge un punto morto, allora chiedete ai +manutentori o altri revisori di partecipare esprimendo la loro opinione. Spesso +vige un silenzio assenso per cui gli altri revisori non intervengono se non gli +viene richiesto esplicitamente. L'opinione di più persone avrà sicuramente un +peso maggiore. + Diversi sviluppatori revisioneranno il codice con diversi punti di vista. Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno @@ -189,3 +198,13 @@ l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben accetta e di valore, se porta ad avere un codice migliore nel kernel. + +Non esistono requisiti particolarmente stringenti per l'uso di etichette come +``Reviewed-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un +qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è +appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai +manutentori di prendere conoscenza circa una revisione avvenuta per davvero. + +Per finire, la revisione delle patch può diventare un processo negativo, troppo +focalizzato sulla ricerca dei problemi. Provate a fare qualche complimento di +tanto in tanto, specialmente con i nuovi arrivati. diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index f37c53f8b524..c7d05e2fff15 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -33,14 +33,16 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. Programma Versione minima Comando per verificare la versione ====================== ================= ======================================== GNU C 5.1 gcc --version -Clang/LLVM (optional) 11.0.0 clang --version -GNU make 3.81 make --version +Clang/LLVM (optional) 13.0.0 clang --version +Rust (opzionale) 1.78.0 rustc --version +bindgen (opzionale) 0.65.1 bindgen --version +GNU make 4.0 make --version bash 4.2 bash --version binutils 2.25 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version -util-linux 2.10o fdformat --version +util-linux 2.10o mount --version kmod 13 depmod -V e2fsprogs 1.41.4 e2fsck -V jfsutils 1.1.3 fsck.jfs -V @@ -59,8 +61,12 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 1.7 sphinx-build --version +Sphinx\ [#f1]_ 2.4.4 sphinx-build --version cpio any cpio --version +GNU tar 1.28 tar --version +gtags (opzionale) 6.6.5 gtags --version +mkimage (opzionale) 2017.01 mkimage --version +Python (opzionale) 3.5.x python3 --version ====================== ================= ======================================== .. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel @@ -84,10 +90,25 @@ potremmo rimuovere gli espedienti che abbiamo implementato per farli funzionare. Per maggiori informazioni :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. +Rust (opzionale) +---------------- + +È necessaria una versione recente del compilatore Rust. + +Verificate le istruzioni Documentation/rust/quick-start.rst su come soddisfare i +requisiti per compilare code Rust. In particolare, la regola ``rustavailable`` +nel ``Makefile`` è utile per verificare perché gli strumenti di compilazione non +vengono trovati. + +bindgen (opzionale) +------------------- + +``bindgen`` viene usato per generare il collegamento (binding) da Rust al lato C del kernel. Dipende da ``libclang``. + Make ---- -Per compilare il kernel vi servirà GNU make 3.81 o successivo. +Per compilare il kernel vi servirà GNU make 4.0 o successivo. Bash ---- @@ -151,6 +172,28 @@ Se la firma dei moduli è abilitata, allora vi servirà openssl per compilare il kernel 3.7 e successivi. Vi serviranno anche i pacchetti di sviluppo di openssl per compilare il kernel 4.3 o successivi. +Tar +--- + +GNU Tar è necessario per accedere ai file d'intestazione del kernel usando sysfs +(CONFIG_IKHEADERS) + +gtags / GNU GLOBAL (opzionale) +------------------------------ + +Il programma GNU GLOBAL versione 6.6.5, o successiva, è necessario quando si +vuole eseguire ``make gtags`` e generare i relativi indici. Internamente si fa +uso del parametro gtags ``-C (--directory)`` che compare in questa versione. + +mkimage +------- + +Questo strumento viene usato per produrre un *Flat Image Tree* (FIT), +tipicamente usato su sistemi ARM. Questo strumento è disponibile tramite il +pacchetto ``u-boot-tools`` oppure può essere compilato dal codice sorgente di +U-Boot. Consultate le istruzioni +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux + Strumenti di sistema ******************** @@ -434,7 +477,7 @@ E2fsprogs JFSutils -------- -- <http://jfs.sourceforge.net/> +- <https://jfs.sourceforge.net/> Reiserfsprogs ------------- @@ -455,7 +498,7 @@ Pcmciautils Quota-tools ----------- -- <http://sourceforge.net/projects/linuxquota/> +- <https://sourceforge.net/projects/linuxquota/> Microcodice Intel P6 @@ -476,7 +519,7 @@ FUSE mcelog ------ -- <http://www.mcelog.org/> +- <https://www.mcelog.org/> cpio ---- @@ -497,7 +540,8 @@ PPP NFS-utils --------- -- <http://sourceforge.net/project/showfiles.php?group_id=14> +- <https://sourceforge.net/project/showfiles.php?group_id=14> +- <https://nfs.sourceforge.net/> Iptables -------- @@ -512,12 +556,7 @@ Ip-route2 OProfile -------- -- <http://oprofile.sf.net/download/> - -NFS-Utils ---------- - -- <http://nfs.sourceforge.net/> +- <https://oprofile.sf.net/download/> Documentazione del kernel ************************* diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 284a75ac19f8..c0dc786b8474 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -214,7 +214,7 @@ Non usate inutilmente le graffe dove una singola espressione è sufficiente. e -.. code-block:: none +.. code-block:: c if (condition) do_this(); @@ -620,18 +620,6 @@ Lo stile preferito per i commenti più lunghi (multi-riga) è: * with beginning and ending almost-blank lines. */ -Per i file in net/ e in drivers/net/ lo stile preferito per i commenti -più lunghi (multi-riga) è leggermente diverso. - -.. code-block:: c - - /* The preferred comment style for files in net/ and drivers/net - * looks like this. - * - * It is nearly the same as the generally preferred comment style, - * but there is no initial almost-blank line. - */ - È anche importante commentare i dati, sia per i tipi base che per tipi derivati. A questo scopo, dichiarate un dato per riga (niente virgole per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo @@ -652,7 +640,7 @@ Quindi, potete sbarazzarvi di GNU emacs, o riconfigurarlo con valori più sensati. Per fare quest'ultima cosa, potete appiccicare il codice che segue nel vostro file .emacs: -.. code-block:: none +.. code-block:: elisp (defun c-lineup-arglist-tabs-only (ignored) "Line up argument lists by tabs, not spaces" @@ -726,8 +714,12 @@ di stile, refusi e possibilmente anche delle migliorie. È anche utile per ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire il testo e altre cose simili. Per maggiori dettagli, consultate il file -:ref:`Documentation/translations/it_IT/process/clang-format.rst <it_clangformat>`. +:ref:`Documentation/translations/it_IT/dev-tools/clang-format.rst <it_clangformat>`. +Se utilizzate un programma compatibile con EditorConfig, allora alcune +configurazioni basilari come l'indentazione e la fine delle righe verranno +applicate automaticamente. Per maggiori informazioni consultate la pagina: +https://editorconfig.org/ 10) File di configurazione Kconfig ---------------------------------- @@ -823,6 +815,29 @@ blocco do - while: do_this(b, c); \ } while (0) +Le macro che sembrano funzioni con parametri non usati dovrebbero essere +sostituite da funzioni inline per evitare il problema. + +.. code-block:: c + + static inline void fun(struct foo *foo) + { + } + +Per motivi storici, molti file usano ancora l'approccio "cast a (void)" per +valutare i parametri. Tuttavia, non è raccomandato. Le funzioni inline risolvono +i problemi di "espressioni con effetti avversi valutate più di una volta", +variabili non utilizzate, e in genere per qualche motivo sono documentate +meglio. + +.. code-block:: c + + /* + * Avoid doing this whenever possible and instead opt for static + * inline functions + */ + #define macrofun(foo) do { (void) (foo); } while (0) + Cose da evitare quando si usano le macro: 1) le macro che hanno effetti sul flusso del codice: @@ -898,7 +913,9 @@ usare per assicurarvi che i messaggi vengano associati correttamente ai dispositivi e ai driver, e che siano etichettati correttamente: dev_err(), dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad alcun dispositivo, <linux/printk.h> definisce pr_info(), pr_warn(), pr_err(), -eccetera. +eccetera. Quando tutto funziona correttamente, non dovrebbero esserci stampe, +per cui preferite dev_dbg/pr_debug a meno che non sia qualcosa di sbagliato +da segnalare. Tirar fuori un buon messaggio di debug può essere una vera sfida; e quando l'avete può essere d'enorme aiuto per risolvere problemi da remoto. diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index ba0ed7dc154c..d4ab76e9be49 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -86,7 +86,7 @@ da kcalloc(). Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate le funzioni del tipo *saturate-on-overflow*:: - bar = vmalloc(array_size(count, size)); + bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL); Un altro tipico caso da evitare è quello di calcolare la dimensione di una struttura seguita da un vettore di altre strutture, come nel seguente caso:: diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst index 76ca3226c8cd..9f8fe8abab4a 100644 --- a/Documentation/translations/it_IT/process/email-clients.rst +++ b/Documentation/translations/it_IT/process/email-clients.rst @@ -95,7 +95,7 @@ Nella sezione :menuselection:`Sending Preferences`: - :menuselection:`Strip Whitespace Before Sending` deve essere ``disabled`` Quando state scrivendo un messaggio, il cursore dev'essere posizionato -dove volete che la patch inizi, poi premendo :kbd:`CTRL-R` vi verrà chiesto +dove volete che la patch inizi, poi premendo `CTRL-R` vi verrà chiesto di selezionare il file patch da inserire nel messaggio. Claws Mail (GUI) @@ -104,7 +104,7 @@ Claws Mail (GUI) Funziona. Alcune persone riescono ad usarlo con successo per inviare le patch. Per inserire una patch usate :menuselection:`Messaggio-->Inserisci file` -(:kbd:`CTRL-I`) oppure un editor esterno. +(`CTRL-I`) oppure un editor esterno. Se la patch che avete inserito dev'essere modificata usando la finestra di scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia @@ -117,10 +117,10 @@ Alcune persone riescono ad usarlo con successo per inviare le patch. Quando state scrivendo una lettera selezionate: Preformattato da :menuselection:`Formato-->Stile del paragrafo-->Preformattato` - (:kbd:`CTRL-7`) o dalla barra degli strumenti + (`CTRL-7`) o dalla barra degli strumenti Poi per inserire la patch usate: -:menuselection:`Inserisci--> File di testo...` (:kbd:`ALT-N x`) +:menuselection:`Inserisci--> File di testo...` (`ALT-N x`) Potete anche eseguire ``diff -Nru old.c new.c | xclip``, selezionare :menuselection:`Preformattato`, e poi usare il tasto centrale del mouse. @@ -228,7 +228,7 @@ Mutt è molto personalizzabile. Qui di seguito trovate la configurazione minima per iniziare ad usare Mutt per inviare patch usando Gmail:: # .muttrc - # ================ IMAP ==================== + # ================ IMAP ==================== set imap_user = 'yourusername@gmail.com' set imap_pass = 'yourpassword' set spoolfile = imaps://imap.gmail.com/INBOX @@ -365,27 +365,12 @@ un editor esterno. Un altro problema è che Gmail usa la codifica base64 per tutti quei messaggi che contengono caratteri non ASCII. Questo include cose tipo i nomi europei. -Proton Mail -*********** +HacKerMaiL (TUI) +**************** -Il servizio Proton Mail ha una funzionalità che cripta tutti i messaggi verso -ogni destinatario per cui è possibile trovare una chiave usando il *Web Key -Directory* (WKD). Il servizio kernel.org pubblica il WKD per ogni sviluppatore -in possesso di un conto kernel.org. Di conseguenza, tutti i messaggi inviati -usando Proton Mail verso indirizzi kernel.org verranno criptati. - -Proton Mail non fornisce alcun meccanismo per disabilitare questa funzionalità -perché verrebbe considerato un problema per la riservatezza. Questa funzionalità -è attiva anche quando si inviano messaggi usando il Proton Mail Bridge. Dunque -tutta la posta in uscita verrà criptata, incluse le patch inviate con ``git -send-email``. - -I messaggi criptati sono una fonte di problemi; altri sviluppatori potrebbero -non aver configurato i loro programmi, o strumenti, per gestire messaggi -criptati; inoltre, alcuni programmi di posta elettronica potrebbero criptare le -risposte a messaggi criptati per tutti i partecipanti alla discussione, inclusa -la lista di discussione stessa. - -A meno che non venga introdotta una maniera per disabilitare questa -funzionalità, non è consigliato usare Proton Mail per contribuire allo sviluppo -del kernel. +HacKerMaiL (hkml) è una semplice casella pubblica per la gestione dei messaggi +di posta che non richiede alcuna sottoscrizione ad una lista di discussione. +Viene sviluppato e mantenuto dal manutentore di DAMON e si pone come obiettivo +quello di gestire il processo di sviluppo semplice come quello di DAMON e più in +generale i sottosistemi del kernel. Per maggiori dettagli, fate riferimento al +documento README (https://github.com/sjp38/hackermail/blob/master/README.md). diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst index 052f1b3610cb..f51288602ee3 100644 --- a/Documentation/translations/it_IT/process/howto.rst +++ b/Documentation/translations/it_IT/process/howto.rst @@ -85,8 +85,8 @@ relativi file di documentatione che spiegano come usarele. Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia con lo spazio utente, è raccomandabile che inviate una notifica o una correzione alle pagine *man* spiegando tale modifica agli amministratori di -queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo -in CC la lista linux-api@vger.kernel.org. +queste pagine all'indirizzo alx@kernel.org, aggiungendo in CC la +lista linux-api@vger.kernel.org. Di seguito una lista di file che sono presenti nei sorgente del kernel e che è richiesto che voi leggiate: @@ -144,7 +144,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che dello sviluppo di Linux ed è molto importante per le persone che arrivano da esperienze con altri Sistemi Operativi. - :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>` + :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>` Se ritenete di aver trovato un problema di sicurezza nel kernel Linux, seguite i passaggi scritti in questo documento per notificarlo agli sviluppatori del kernel, ed aiutare la risoluzione del problema. @@ -344,7 +344,7 @@ principale 4.x, sarà necessario un test d'integrazione. A tale scopo, esiste un repositorio speciale di test nel quale virtualmente tutti i rami dei sottosistemi vengono inclusi su base quotidiana: - https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git + https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che ci si aspetterà essere nel kernel principale nel successivo periodo @@ -389,12 +389,12 @@ sviluppatori del kernel partecipano alla lista di discussione Linux Kernel. I dettagli su come iscriversi e disiscriversi dalla lista possono essere trovati al sito: - http://vger.kernel.org/vger-lists.html#linux-kernel + https://subspace.kernel.org/subscribing.html Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore di ricerca per trovarli. Per esempio: - https://lore.kernel.org/lkml/ + https://lore.kernel.org/linux-kernel/ É caldamente consigliata una ricerca in questi archivi sul tema che volete sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state @@ -407,13 +407,13 @@ discussione e il loro uso. Molte di queste liste sono gestite su kernel.org. Per informazioni consultate la seguente pagina: - http://vger.kernel.org/vger-lists.html + https://subspace.kernel.org Per favore ricordatevi della buona educazione quando utilizzate queste liste. Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee guida per interagire con la lista (o con qualsiasi altra lista): - http://www.albion.com/netiquette/ + https://subspace.kernel.org/etiquette.html Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index cd7977905fb8..5a5214f5fd72 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -21,47 +21,83 @@ l'accettazione delle vostre modifiche con il minimo sforzo. Di seguito le guide che ogni sviluppatore dovrebbe leggere. +Introduzione al funzionamento dello sviluppo del kernel +------------------------------------------------------- + +Innanzitutto, leggete questi documenti che vi aiuteranno ad entrare nella +comunità del kernel. + .. toctree:: :maxdepth: 1 howto - code-of-conduct development-process submitting-patches + submit-checklist + +Strumenti e guide tecniche per gli sviluppatori del kernel +---------------------------------------------------------- + +Quella che segue è una raccolta di documenti che uno sviluppatore del kernel +Linux dovrebbe conoscere. + +.. toctree:: + :maxdepth: 1 + + changes programming-language coding-style maintainer-pgp-guide email-clients - kernel-enforcement-statement - kernel-driver-statement + applying-patches + adding-syscalls + volatile-considered-harmful + botching-up-ioctls -Poi ci sono altre guide sulla comunità che sono di interesse per molti -degli sviluppatori: +Politiche e dichiarazioni degli sviluppatori +-------------------------------------------- + +Quelle che seguono rappresentano le regole che cerchiamo di seguire all'interno +della comunità del kernel (e oltre). .. toctree:: :maxdepth: 1 - changes + code-of-conduct + kernel-enforcement-statement + kernel-driver-statement stable-api-nonsense - management-style stable-kernel-rules - submit-checklist - kernel-docs + management-style + +Gestire i bachi +--------------- + +I bachi sono parte della nostra vita; dunque è importante che vengano trattati +con riguardo. I documenti che seguono descrivono le nostre politiche riguardo al +trattamento di alcune classi particolari di bachi: le regressioni e i problemi +di sicurezza. + +Informazioni per i manutentori +------------------------------ + +Come trovare le persone che accetteranno le vostre modifiche. + +.. toctree:: + :maxdepth: 1 + maintainers -Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo -perché non si è trovato un posto migliore. +Altri documenti +--------------- + +Poi ci sono altre guide sulla comunità che sono di interesse per molti +degli sviluppatori: .. toctree:: :maxdepth: 1 - applying-patches - adding-syscalls - magic-number - volatile-considered-harmful - botching-up-ioctls - clang-format - ../riscv/patch-acceptance + kernel-docs .. only:: subproject and html diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/process/security-bugs.rst index 20994f4bfa31..20994f4bfa31 100644 --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst +++ b/Documentation/translations/it_IT/process/security-bugs.rst diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 248bf1e4b171..b1592f10f7a7 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -11,32 +11,31 @@ Tutto quello che volevate sapere sui rilasci -stable di Linux Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti "-stable": - - Ovviamente dev'essere corretta e verificata. - - Non dev'essere più grande di 100 righe, incluso il contesto. - - Deve correggere una cosa sola. - - Deve correggere un baco vero che sta disturbando gli utenti (non cose del - tipo "Questo potrebbe essere un problema ..."). - - Deve correggere un problema di compilazione (ma non per cose già segnate - con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati, - un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene". - In pratica, qualcosa di critico. - - Problemi importanti riportati dagli utenti di una distribuzione potrebbero - essere considerati se correggono importanti problemi di prestazioni o di - interattività. Dato che questi problemi non sono così ovvi e la loro - correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero - essere sottomessi solo dal manutentore della distribuzione includendo un - link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive - sull'impatto che ha sugli utenti. - - Non deve correggere problemi relativi a una "teorica sezione critica", - a meno che non venga fornita anche una spiegazione su come questa si - possa verificare. - - Non deve includere alcuna correzione "banale" (correzioni grammaticali, - pulizia dagli spazi bianchi, eccetera). - - Deve rispettare le regole scritte in - :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` - - Questa patch o una equivalente deve esistere già nei sorgenti principali di - Linux - +- Questa patch o una equivalente deve esistere già nei sorgenti principali di + Linux (upstream) +- Ovviamente dev'essere corretta e verificata. +- Non dev'essere più grande di 100 righe, incluso il contesto. +- Deve rispettare le regole scritte in + :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` +- Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge + un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso: + + - Corregge un problema come un oops, un blocco, una corruzione di dati, un + vero problema di sicurezza, una stranezza hardware, un problema di + compilazione (ma non per cose già segnate con CONFIG_BROKEN), o problemi + del tipo "oh, questo non va bene". + - Problemi importanti riportati dagli utenti di una distribuzione potrebbero + essere considerati se correggono importanti problemi di prestazioni o di + interattività. Dato che questi problemi non sono così ovvi e la loro + correzione ha un'alta probabilità d'introdurre una regressione, + dovrebbero essere sottomessi solo dal manutentore della distribuzione + includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni + aggiuntive sull'impatto che ha sugli utenti. + - Non si accettano cose del tipo "Questo potrebbe essere un problema ..." + come una teorica sezione critica, senza aver fornito anche una spiegazione + su come il baco possa essere sfruttato. + - Non deve includere alcuna correzione "banale" (correzioni grammaticali, + pulizia dagli spazi bianchi, eccetera). Procedura per sottomettere patch per i sorgenti -stable ------------------------------------------------------- @@ -44,179 +43,206 @@ Procedura per sottomettere patch per i sorgenti -stable .. note:: Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo di revisione -stable, ma dovrebbe seguire le procedure descritte in - :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. - -Per tutte le altre sottomissioni, scegliere una delle seguenti procedure ------------------------------------------------------------------------- + :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`. + +Ci sono tre opzioni per inviare una modifica per i sorgenti -stable: + +1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della + sottomissione per l'inclusione nei sorgenti principali. +2. Chiedere alla squadra "stable" di prendere una patch già applicata sui + sorgenti principali +3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già + fatta sui sorgenti principali. + +Le seguenti sezioni descrivono con maggiori dettagli ognuna di queste opzioni + +L':ref:`it_option_1` è **fortemente** raccomandata; è il modo più facile e +usato. L':ref:`it_option_2` si usa quando al momento della sottomissione non si +era pensato di riportare la modifica su versioni precedenti. +L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch +nei sorgenti principali ha bisogno di aggiustamenti per essere applicata su +versioni precedenti (per esempio a causa di cambiamenti dell'API). + +Quando si utilizza l'opzione 2 o 3 è possibile chiedere che la modifica sia +inclusa in specifiche versioni stabili. In tal caso, assicurarsi che la correzione +o una equivalente sia applicabile, o già presente in tutti i sorgenti +stabili più recenti ancora supportati. Questo ha lo scopo di prevenire +regressioni che gli utenti potrebbero incontrare in seguito durante +l'aggiornamento, se ad esempio una correzione per 5.19-rc1 venisse +riportata a 5.10.y, ma non a 5.15.y. .. _it_option_1: Opzione 1 ********* -Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili, -aggiungete l'etichetta +Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch +che state inviando per l'inclusione nei sorgenti principali venga presa +automaticamente anche per quelli stabili:: -.. code-block:: none + Cc: stable@vger.kernel.org - Cc: stable@vger.kernel.org +Invece, usate ``Cc: stable@vger.kernel.org`` quando state inviando correzioni +per vulnerabilità non ancora di pubblico dominio: questo riduce il rischio di +esporre accidentalmente al pubblico la correzione quando si usa 'git +send-email', perché i messaggi inviati a quell'indirizzo non vengono inviati da +nessuna parte. -nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà -applicata anche sui sorgenti stabili senza che l'autore o il manutentore -del sottosistema debba fare qualcosa. +Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti +stabili senza che l'autore o il manutentore del sottosistema debba fare +qualcosa. -.. _it_option_2: +Per lasciare una nota per la squadra "stable", usate commenti in linea in stile +shell (leggere oltre per maggiori dettagli). -Opzione 2 -********* +* Specificate i prerequisiti per le patch aggiuntive:: -Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a -stable@vger.kernel.org includendo: il titolo della patch, l'identificativo -del commit, il perché pensate che debba essere applicata, e in quale versione -del kernel la vorreste vedere. + Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle + Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle + Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic + Cc: <stable@vger.kernel.org> # 3.3.x + Signed-off-by: Ingo Molnar <mingo@elte.hu> -.. _it_option_3: + La sequenza di etichette ha il seguente significato:: -Opzione 3 -********* + git cherry-pick a1f84a3 + git cherry-pick 1b9508f + git cherry-pick fd21073 + git cherry-pick <this commit> -Inviata la patch, dopo aver verificato che rispetta le regole descritte in -precedenza, a stable@vger.kernel.org. Dovete annotare nel changelog -l'identificativo del commit nei sorgenti principali, così come la versione -del kernel nel quale vorreste vedere la patch. + Notate che per una serie di patch non dovere elencare come necessarie tutte + le patch della serie stessa. Per esempio se avete la seguente serie:: -L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato. -L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento -dell'inclusione dei sorgenti principali, si ritiene che non debbano essere -incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero -fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è -particolarmente utile se una patch dev'essere riportata su una versione -precedente (per esempio la patch richiede modifiche a causa di cambiamenti di -API). + patch1 + patch2 -Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei -sorgenti principali (per esempio perché è stato necessario un lavoro di -adattamento) allora dev'essere ben documentata e giustificata nella descrizione -della patch. + dove patch2 dipende da patch1, non dovete elencare patch1 come requisito per + patch2 se avete già menzionato patch1 per l'inclusione in "stable" -L'identificativo del commit nei sorgenti principali dev'essere indicato sopra -al messaggio della patch, così: +* Evidenziate le patch che hanno dei requisiti circa la versione del kernel:: -.. code-block:: none + Cc: <stable@vger.kernel.org> # 3.3.x - commit <sha1> upstream. + L'etichetta ha il seguente significato:: -o in alternativa: + git cherry-pick <this commit> -.. code-block:: none + per ogni sorgente "-stable" che inizia con la versione indicata. - [ Upstream commit <sha1> ] + Notate che queste etichette non sono necessarie se la squadre "stable" può + dedurre la versione dalle etichette Fixes: -In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero -dipendere da altre che devo essere incluse. Questa situazione può essere -indicata nel seguente modo nell'area dedicata alle firme: +* Ritardare l'inclusione di patch:: + Cc: <stable@vger.kernel.org> # after -rc3 -.. code-block:: none +* Evidenziare problemi noti:: - Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle - Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle - Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic - Cc: <stable@vger.kernel.org> # 3.3.x - Signed-off-by: Ingo Molnar <mingo@elte.hu> + Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3 -La sequenza di etichette ha il seguente significato: +Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare +allo strumento di *backporting* di ignorare un cambiamento:: -.. code-block:: none + Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present - git cherry-pick a1f84a3 - git cherry-pick 1b9508f - git cherry-pick fd21073 - git cherry-pick <this commit> -Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del -kernel. Questo può essere indicato usando il seguente formato nell'area -dedicata alle firme: +.. _it_option_2: + +Opzione 2 +********* + +Se la patch è già stata inclusa nei sorgenti Linux, inviate una mail a +stable@vger.kernel.org includendo: il titolo della patch, l'identificativo +del commit, il perché pensate che debba essere applicata, e in quali versioni +del kernel la vorreste vedere. + +.. _it_option_3: -.. code-block:: none +Opzione 3 +********* - Cc: <stable@vger.kernel.org> # 3.3.x +Dopo aver verificato che rispetta le regole descritte in precedenza, inviata la +patch a stable@vger.kernel.org facendo anche menzione delle versioni nella quale +si vorrebbe applicarla. Nel farlo, dovete annotare nel changelog +l'identificativo del commit nei sorgenti principali, così come la versione del +kernel nel quale vorreste vedere la patch.:: -L'etichetta ha il seguente significato: + commit <sha1> upstream. -.. code-block:: none +o in alternativa:: - git cherry-pick <this commit> + [ Upstream commit <sha1> ] -per ogni sorgente "-stable" che inizia con la versione indicata. +Se la patch inviata devia rispetto all'originale presente nei sorgenti +principali (per esempio per adattarsi ad un cambiamento di API), allora questo +dev'essere giustificato e dettagliato in modo chiaro nella descrizione. -Dopo la sottomissione: +Dopo la sottomissione +--------------------- - - Il mittente riceverà un ACK quando la patch è stata accettata e messa in - coda, oppure un NAK se la patch è stata rigettata. A seconda degli impegni - degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni. - - Se accettata, la patch verrà aggiunta alla coda -stable per essere - revisionata dal altri sviluppatori e dal principale manutentore del - sottosistema. +Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda, +oppure un NAK se la patch è stata rigettata. La risposta potrebbe richiedere +alcuni giorni in funzione dei piani dei membri della squadra "stable", +Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata +dal altri sviluppatori e dal principale manutentore del sottosistema. Ciclo di una revisione ---------------------- - - Quando i manutentori -stable decidono di fare un ciclo di revisione, le - patch vengono mandate al comitato per la revisione, ai manutentori soggetti - alle modifiche delle patch (a meno che il mittente non sia anche il - manutentore di quell'area del kernel) e in CC: alla lista di discussione - linux-kernel. - - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK - alle patch. - - Se una patch viene rigettata da un membro della commissione, o un membro - della lista linux-kernel obietta la bontà della patch, sollevando problemi - che i manutentori ed i membri non avevano compreso, allora la patch verrà - rimossa dalla coda. - - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di - un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e - dai testatori. - - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi - importanti, alcune patch potrebbero essere modificate o essere scartate, - oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate - nuove -rc e così via finché non si ritiene che non vi siano più problemi. - - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email - con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al - commit rilascio. - - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le - patch che erano in coda e sono state verificate. - - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente - dalla squadra per la sicurezza del kernel, e non passerà per il normale - ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli - su questa procedura. +- Quando i manutentori -stable decidono di fare un ciclo di revisione, le + patch vengono mandate al comitato per la revisione, ai manutentori soggetti + alle modifiche delle patch (a meno che il mittente non sia anche il + manutentore di quell'area del kernel) e in CC: alla lista di discussione + linux-kernel. +- La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK + alle patch. +- Se una patch viene rigettata da un membro della commissione, o un membro + della lista linux-kernel obietta la bontà della patch, sollevando problemi + che i manutentori ed i membri non avevano compreso, allora la patch verrà + rimossa dalla coda. +- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di + un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e + dai testatori. +- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi + importanti, alcune patch potrebbero essere modificate o essere scartate, + oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate + nuove -rc e così via finché non si ritiene che non vi siano più problemi. +- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email + con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al + commit rilascio. +- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le + patch che erano in coda e sono state verificate. +- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente + dalla squadra per la sicurezza del kernel, e non passerà per il normale + ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli + su questa procedura. Sorgenti -------- - - La coda delle patch, sia quelle già applicate che in fase di revisione, - possono essere trovate al seguente indirizzo: +- La coda delle patch, sia quelle già applicate che in fase di revisione, + possono essere trovate al seguente indirizzo: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git - - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere - trovato in rami distinti per versione al seguente indirizzo: +- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere + trovato in rami distinti per versione al seguente indirizzo: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git - - I rilasci candidati di tutti i kernel stabili possono essere trovati al - seguente indirizzo: +- I rilasci candidati di tutti i kernel stabili possono essere trovati al + seguente indirizzo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ - - .. warning:: - I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e - subirà frequenti modifiche, dunque verrà anche trapiantato spesso. - Dovrebbe essere usato solo allo scopo di verifica (per esempio in un - sistema di CI) + .. warning:: + I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e + subirà frequenti modifiche, dunque verrà anche trapiantato spesso. + Dovrebbe essere usato solo allo scopo di verifica (per esempio in un + sistema di CI) Comitato per la revisione ------------------------- - - Questo comitato è fatto di sviluppatori del kernel che si sono offerti - volontari per questo lavoro, e pochi altri che non sono proprio volontari. +- Questo comitato è fatto di sviluppatori del kernel che si sono offerti + volontari per questo lavoro, e pochi altri che non sono proprio volontari. diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 2fc09cc1f0be..692be4af9c9b 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -5,8 +5,9 @@ .. _it_submitchecklist: +============================================================================ Lista delle verifiche da fare prima di inviare una patch per il kernel Linux -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +============================================================================ Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per vedere le proprie patch accettate più rapidamente. @@ -15,118 +16,126 @@ Tutti questi punti integrano la documentazione fornita riguardo alla sottomissione delle patch, in particolare :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`. +Revisiona il tuo codice +======================= + 1) Se state usando delle funzionalità del kernel allora includete (#include) i file che le dichiarano/definiscono. Non dipendente dal fatto che un file d'intestazione include anche quelli usati da voi. -2) Compilazione pulita: - - a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun - avviso/errore di ``gcc`` e nessun avviso/errore dal linker. - - b) con ``allnoconfig``, ``allmodconfig`` - - c) quando si usa ``O=builddir`` - - d) Qualsiasi modifica in Documentation/ deve compilare con successo senza - avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare - e correggere i problemi - -3) Compilare per diverse architetture di processore usando strumenti per - la cross-compilazione o altri. +2) Controllate lo stile del codice della vostra patch secondo le direttive + scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`. -4) Una buona architettura per la verifica della cross-compilazione è la ppc64 - perché tende ad usare ``unsigned long`` per le quantità a 64-bit. +3) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``, + ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei + sorgenti che ne spieghi la logica: cosa fanno e perché. -5) Controllate lo stile del codice della vostra patch secondo le direttive - scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`. - Prima dell'invio della patch, usate il verificatore di stile - (``script/checkpatch.pl``) per scovare le violazioni più semplici. - Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella - vostra patch. +Revisionate i cambiamenti a Kconfig +=================================== -6) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu +1) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu di configurazione e sono preimpostate come disabilitate a meno che non soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst`` alla punto "Voci di menu: valori predefiniti". -7) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto. +2) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto. -8) La patch è stata accuratamente revisionata rispetto alle più importanti +3) La patch è stata accuratamente revisionata rispetto alle più importanti configurazioni ``Kconfig``. Questo è molto difficile da fare correttamente - un buono lavoro di testa sarà utile. -9) Verificare con sparse. +Fornite documentazione +====================== -10) Usare ``make checkstack`` e correggere tutti i problemi rilevati. +1) Includete :ref:`kernel-doc <kernel_doc>` per documentare API globali del + kernel. - .. note:: +2) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``. - ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione - che usa più di 512 byte sullo stack è una buona candidata per una - correzione. +3) Tutti i nuovi parametri d'avvio del kernel sono documentati in + ``Documentation/admin-guide/kernel-parameters.rst``. -11) Includete commenti :ref:`kernel-doc <kernel_doc>` per documentare API - globali del kernel. Usate ``make htmldocs`` o ``make pdfdocs`` per - verificare i commenti :ref:`kernel-doc <kernel_doc>` ed eventualmente - correggerli. +4) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. -12) La patch è stata verificata con le seguenti opzioni abilitate - contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, - ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, - ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, - ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``. +5) Tutte le nuove interfacce verso lo spazio utente sono documentate in + ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori + informazioni. Le patch che modificano le interfacce utente dovrebbero + essere inviate in copia anche a linux-api@vger.kernel.org. -13) La patch è stata compilata e verificata in esecuzione con, e senza, - le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. +6) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate + ``Documentation/userspace-api/ioctl/ioctl-number.rst``. -14) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere - verificata con, e senza, l'opzione ``CONFIG_LBDAF``. +Verificate il vostro codice con gli strumenti +============================================= -15) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità - di lockdep abilitate. +1) Prima dell'invio della patch, usate il verificatore di stile + (``script/checkpatch.pl``) per scovare le violazioni più semplici. + Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella + vostra patch. -16) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``. +2) Verificare il codice con sparse. -17) Tutti i nuovi parametri d'avvio del kernel sono documentati in - ``Documentation/admin-guide/kernel-parameters.rst``. -18) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. +3) Usare ``make checkstack`` e correggere tutti i problemi rilevati. Da notare + che ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione + che usa più di 512 byte sullo stack è una buona candidata per una correzione. -19) Tutte le nuove interfacce verso lo spazio utente sono documentate in - ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori - informazioni. Le patch che modificano le interfacce utente dovrebbero - essere inviate in copia anche a linux-api@vger.kernel.org. +Compilare il codice +=================== + +1) Compilazione pulita: + + a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun + avviso/errore di ``gcc`` e nessun avviso/errore dal linker. -20) La patch è stata verificata con l'iniezione di fallimenti in slab e - nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``. + b) con ``allnoconfig``, ``allmodconfig`` + + c) quando si usa ``O=builddir`` - Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere - l'iniezione di fallimenti specifici per il sottosistema. + d) Qualsiasi modifica in Documentation/ deve compilare con successo senza + avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare + e correggere i problemi -21) Il nuovo codice è stato compilato con ``gcc -W`` (usate +2) Compilare per diverse architetture di processore usando strumenti per la + cross-compilazione o altri. Una buona architettura per la verifica della + cross-compilazione è la ppc64 perché tende ad usare ``unsigned long`` per le + quantità a 64-bit. + +3) Il nuovo codice è stato compilato con ``gcc -W`` (usate ``make KCFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo per scovare bachi come "warning: comparison between signed and unsigned". -22) La patch è stata verificata dopo essere stata inclusa nella serie di patch - -mm; questo al fine di assicurarsi che continui a funzionare assieme a - tutte le altre patch in coda e i vari cambiamenti nei sottosistemi VM, VFS - e altri. +4) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o + funzionalità del kernel che è associata a uno dei seguenti simboli + ``Kconfig``, allora verificate che il kernel compili con diverse + configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la + possibilità) [non tutti contemporaneamente, solo diverse combinazioni + casuali]: -23) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``, - ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei - sorgenti che ne spieghi la logica: cosa fanno e perché. + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, + ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``). -24) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate - ``Documentation/userspace-api/ioctl/ioctl-number.rst``. +Verificate il vostro codice +=========================== + +1) La patch è stata verificata con le seguenti opzioni abilitate + contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, + ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``. + +2) La patch è stata compilata e verificata in esecuzione con, e senza, + le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. + +3) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità + di lockdep abilitate. -25) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o - funzionalità del kernel che è associata a uno dei seguenti simboli - ``Kconfig``, allora verificate che il kernel compili con diverse - configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la - possibilità) [non tutti contemporaneamente, solo diverse combinazioni - casuali]: +4) La patch è stata verificata con l'iniezione di fallimenti in slab e + nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``. + Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere + l'iniezione di fallimenti specifici per il sottosistema. - ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, - ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, - ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``). +5) La patch è stata verificata sul tag più recente di linux-next per assicurarsi + che funzioni assieme a tutte le altre patch in coda, assieme ai vari + cambiamenti nei sottosistemi VM, VFS e altri. diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index f91c8092844f..1cc4808139ce 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -106,9 +106,29 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo comportamento. +Se volete far riferimento a uno specifico commit, non usate solo +l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga +riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. +Per esempio:: + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + +Dovreste anche assicurarvi di usare almeno i primi 12 caratteri +dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e +questo rende possibile la collisione fra due identificativi con pochi +caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il +vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. + Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi -riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere +riferimento. Se la patch è il risultato di una discussione avvenuta +precedentemente o di un documento sul presente sul web, allora fatevi +riferimento. + +Per esempio, se la vostra patch corregge un baco potete aggiungere quest'etichetta per fare riferimento ad un rapporto su una lista di discussione o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far riferimento ad una discussione precedentemente avvenuta su una lista di @@ -117,10 +137,10 @@ questione. Quando volete fare riferimento ad una lista di discussione, preferite il servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è -sufficiente usare il campo ``Message-Id``, presente nell'intestazione del +sufficiente usare il campo ``Message-ID``, presente nell'intestazione del messaggio, senza parentesi angolari. Per esempio:: - Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così creato funzioni e che indirizzi verso il messaggio desiderato. @@ -129,21 +149,16 @@ Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno condotto all'invio della patch. -Se volete far riferimento a uno specifico commit, non usate solo -l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga -riassuntiva del commit per rendere la chiaro ai revisori l'oggetto. -Per esempio:: +Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch, +allora usate l'etichetta "Closes:":: - Commit e21d2170f36602ae2708 ("video: remove unnecessary - platform_set_drvdata()") removed the unnecessary - platform_set_drvdata(), but left the variable "dev" unused, - delete it. + Closes: https://example.com/issues/1234 optional-other-stuff -Dovreste anche assicurarvi di usare almeno i primi 12 caratteri -dell'identificativo SHA-1. Il repositorio del kernel ha *molti* oggetti e -questo rende possibile la collisione fra due identificativi con pochi -caratteri. Tenete ben presente che anche se oggi non ci sono collisioni con il -vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi. +Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere +automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni +automatismi che monitorano la liste di discussione possono anche tracciare +queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono +proibiti. Se la vostra patch corregge un baco in un commit specifico, per esempio avete trovato un problema usando ``git bisect``, per favore usate l'etichetta @@ -237,13 +252,19 @@ nella vostra patch. 5) Selezionate i destinatari della vostra patch ----------------------------------------------- -Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi -interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia -delle revisioni per scoprire chi si occupa del codice. Lo script -scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle -vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su -cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la -vostra ultima possibilità. +Dovreste sempre inviare una copia della patch ai manutentori e alle liste di +discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al +file MAINTAINERS e alla storia delle revisioni per scoprire chi si occupa del +codice. Lo script scripts/get_maintainer.pl può esservi d'aiuto (passategli il +percorso alle vostre patch). Se non riuscite a trovare un manutentore per il +sottosistema su cui state lavorando, allora Andrew Morton +(akpm@linux-foundation.org) sarà la vostra ultima possibilità. + +La lista linux-kernel@vger.kernel.org dovrebbe essere usata per l'invio di tutte +le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni +sviluppatori a non seguirla più. Dunque, per favore, evitate di inviare messaggi +scorrelati al tema della lista o a persone che non dovrebbero essere +interessate all'argomento. Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org @@ -254,11 +275,9 @@ patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le lis di discussione che non sono interessate al vostro lavoro. Molte delle liste di discussione relative al kernel vengono ospitate su -vger.kernel.org; potete trovare un loro elenco alla pagina -http://vger.kernel.org/vger-lists.html. Tuttavia, ci sono altre liste di -discussione ospitate altrove. - -Non inviate più di 15 patch alla volta sulle liste di discussione vger!!! +kernel.org; potete trovare un loro elenco alla pagina +https://subspace.kernel.org. Tuttavia, ci sono altre liste di discussione +ospitate altrove. L'ultimo giudizio sull'integrazione delle modifiche accettate spetta a Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>. @@ -343,12 +362,40 @@ questo caso, rispondete con educazione e concentratevi sul problema che hanno evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando le differenze rispetto a sottomissioni precedenti (vedere -:ref:`it_the_canonical_patch_format`). +:ref:`it_the_canonical_patch_format`). Aggiungete a CC tutte le persone che +vi hanno fornito dei commenti per notificarle di eventuali nuove versioni. Leggete Documentation/translations/it_IT/process/email-clients.rst per le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare sulle liste di discussione. +.. _it_interleaved_replies: + +Rispondere alle email in riga e riducendo la citazioni +------------------------------------------------------ + +Nelle discussioni riguardo allo sviluppo del kernel viene fortemente scoraggiato +l'uso di risposte in cima ai messaggi di posta elettronica. Rispondere in riga +rende le conversazioni molto più scorrevoli. Maggiori dettagli possono essere +trovati qui: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +Come spesso citato nelle liste di discussione:: + + R: http://en.wikipedia.org/wiki/Top_post + D: Dove posso trovare informazioni riguardo alle "risposte in cima"? + R: Perché incasina il normale ordine con cui si legge un testo. + D: Perché è così terribile rispondere in cima? + R: Risposte in cima. + Q: Qual è la cosa più fastidiosa nei messaggi di posta elettronica? + +Allo stesso modo, per favore eliminate tutte le citazioni non necessarie per la +vostra risposta. Questo permette di trovare più facilmente le risposte, e +permette di risparmiare tempo e spazio. Per maggiori dettagli: +http://daringfireball.net/2007/07/on_top :: + + R: No. + D: Dovrei includere un blocco di citazione dopo la mia risposta? + .. _it_resend_reminders: Non scoraggiatevi - o impazientitevi @@ -358,10 +405,10 @@ Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate. I revisori sono persone occupate e potrebbero non ricevere la vostra patch immediatamente. -Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, -ma ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti -in una settimana o poco più; se questo non dovesse accadere, assicuratevi di -aver inviato le patch correttamente. Aspettate almeno una settimana prima di +Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma +ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti in poche +settimane (tipicamente 2 o 3); se questo non dovesse accadere, assicuratevi di +aver inviato le patch correttamente. Aspettate almeno una settimana prima di rinviare le modifiche o sollecitare i revisori - probabilmente anche di più durante la finestra d'integrazione. @@ -525,6 +572,10 @@ e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro. Rammentate che se il baco è stato riportato in privato, dovrete chiedere il permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va usata per i bachi, dunque non usatela per richieste di nuove funzionalità. +Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al +rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può +essere usata in alternativa a Closes: se la patch corregge solo in parte il +problema riportato nel rapporto. L'etichetta Tested-by: indica che la patch è stata verificata con successo (su un qualche sistema) dalla persona citata. Questa etichetta informa i @@ -781,6 +832,71 @@ giungla di riferimenti all'interno dei programmi di posta. Se un collegamento ad una versione precedente di una serie di patch (per esempio, potete usarlo per l'email introduttiva alla serie). +Fornire informazioni circa i sorgenti +------------------------------------- + +Quando gli altri sviluppatori ricevono le vostre patch e iniziano il processo di +revisione, è assolutamente necessario che sappiano qual è il commit/ramo di base +su cui si base il vostro lavoro: considerate l'enorme quantità di sorgenti dei +manutentori presenti al giorno d'oggi. Si noti ancora una volta la voce **T:** +nel file MAINTAINERS spiegato sopra. + +Questo è ancora più importante per i processi automatizzati di CI che tentano di +eseguire una serie di test per stabilire la qualità del codice prima che il +manutentore inizi la revisione. + +Se si usa ``git format-patch`` per generare le patch, si possono includere +automaticamente le informazioni sull'albero di base nell'invio usando il flag +``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami +topici:: + + $ git checkout -t -b my-topical-branch master + Branch 'my-topical-branch' set up to track local branch 'master'. + Switched to a new branch 'my-topical-branch' + + [perform your edits and commits] + + $ git format-patch --base=auto --cover-letter -o outgoing/ master + outgoing/0000-cover-letter.patch + outgoing/0001-First-Commit.patch + outgoing/... + +Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà +che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli +strumenti CI informazioni sufficienti per eseguire correttamente ``git am`` +senza preoccuparsi dei conflitti:: + + $ git checkout -b patch-review [base-commit-id] + Switched to a new branch 'patch-review' + $ git am patches.mbox + Applying: First Commit + Applying: ... + +Consultate ``man git-format-patch`` per maggiori informazioni circa questa +opzione. + +.. note:: + + L'opzione ``--base`` fu introdotta con git versione 2.9.0 + +Se non si usa git per produrre le patch, si può comunque includere +``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il +lavoro. Dovreste aggiungerlo nella lettera di accompagnamento o nella prima +patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a +tutti gli altri contenuti, subito prima della vostra firma e-mail. + +Assicuratevi che il commit si basi su sorgenti ufficiali del +manutentore/mainline e non su sorgenti interni, accessibile solo a voi, +altrimenti sarebbe inutile. + +Strumenti +--------- + +Molti degli aspetti più tecnici di questo processo possono essere automatizzati +usando b4, la cui documentazione è disponibile all'indirizzo +<https://b4.docs.kernel.org/en/latest/>. Può aiutare a tracciare la dipendenze, +eseguire checkpatch e con la formattazione e l'invio di messaggi di posta. + Riferimenti ----------- @@ -803,9 +919,6 @@ Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema" <http://www.kroah.com/log/linux/maintainer-06.html> -No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org! - <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> - Kernel Documentation/translations/it_IT/process/coding-style.rst. E-mail di Linus Torvalds sul formato canonico di una patch: diff --git a/Documentation/translations/it_IT/staging/index.rst b/Documentation/translations/it_IT/staging/index.rst new file mode 100644 index 000000000000..6b56707f3a3a --- /dev/null +++ b/Documentation/translations/it_IT/staging/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +:Original: :ref:`Documentation/staging/index.rst <process_index>` + +Documenti in ordine sparso +========================== + +.. toctree:: + :maxdepth: 2 + + magic-number diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/staging/magic-number.rst index ae92ab633c16..cd8f23571835 100644 --- a/Documentation/translations/it_IT/process/magic-number.rst +++ b/Documentation/translations/it_IT/staging/magic-number.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>` +:Original: :ref:`Documentation/staging/magic-number.rst <magicnumbers>` :Translator: Federico Vaga <federico.vaga@vaga.pv.it> .. _it_magicnumbers: |