From: Fabio Fantoni Date: Tue, 25 Apr 2023 11:01:58 +0000 (+0200) Subject: doc:it_IT: fix some typos X-Git-Tag: v6.6.17~4908^2~7 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=3ee23096add52c84aae23b8569a4d6fc8d47f2ac;p=platform%2Fkernel%2Flinux-rpi.git doc:it_IT: fix some typos Fix of some typos spotted reading documentation in italian and latest changes for 6.4 Signed-off-by: Fabio Fantoni Reviewed-by: Federico Vaga Link: https://lore.kernel.org/r/20230425110158.9755-1-fantonifabio@tiscali.it Signed-off-by: Jonathan Corbet --- diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index a9e781d..4c21cf60 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1030,7 +1030,7 @@ alle corse critiche, dovreste usare timer_delete_sync() (``include/linux/timer.h``) per gestire questo caso. Prima di rilasciare un temporizzatore dovreste chiamare la funzione -timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato. +timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato. Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente ignorato. diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index 57b501f..ba0ed7d 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -386,7 +386,7 @@ combinazione con struct_size() e flex_array_size():: Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY() (da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una -struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi +struttura, e l'altro quando è parte di un unione. Per motivi non tecnici, entrambi i casi d'uso non sono permessi dalla specifica C99. Per esempio, per convertire il seguente codice:: diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index 5131a39..06399d4 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -532,7 +532,7 @@ manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare persone che possano verificare il codice in futuro, e garantisce che queste stesse persone ricevano credito per il loro lavoro. -Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata +Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata considerata accettabile in accordo con la dichiarazione dei revisori: Dichiarazione di svista dei revisori @@ -563,13 +563,13 @@ una modifica che si ritiene appropriata e senza alcun problema tecnico importante. Qualsiasi revisore interessato (quelli che lo hanno fatto) possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve a dare credito ai revisori e a informare i manutentori sul livello di revisione -che è stato fatto sulla patch. L'etichetta Reviewd-by, quando fornita da +che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la loro serietà nella revisione, accrescerà le probabilità che la vostra patch venga integrate nel kernel. Quando si riceve una email sulla lista di discussione da un tester o -un revisore, le etichette Tested-by o Reviewd-by devono essere +un revisore, le etichette Tested-by o Reviewed-by devono essere aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se la patch è cambiata in modo significativo, queste etichette potrebbero non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia