diff options
| author | Fabio Fantoni <fantonifabio@tiscali.it> | 2023-04-25 13:01:58 +0200 |
|---|---|---|
| committer | Jonathan Corbet <corbet@lwn.net> | 2023-04-26 12:42:08 -0600 |
| commit | 3ee23096add52c84aae23b8569a4d6fc8d47f2ac (patch) | |
| tree | 28c51df5556b7c1d692ceb35fbb602dcc8852d93 /Documentation/translations | |
| parent | 7e8472c820f04517ae5d5a27c1aecfa2263a0aa5 (diff) | |
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 <fantonifabio@tiscali.it>
Reviewed-by: Federico Vaga <federico.vaga@vaga.pv.it>
Link: https://lore.kernel.org/r/20230425110158.9755-1-fantonifabio@tiscali.it
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/translations')
3 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index a9e781d2e323..4c21cf60f775 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 57b501f0dfa4..ba0ed7dc154c 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 5131a3963e7e..06399d497843 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 |