Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst- Extension
.rst- Size
- 2906 bytes
- Lines
- 61
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. include:: ../../disclaimer-ita.rst
:Original: :doc:`../../../../arch/riscv/patch-acceptance`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
arch/riscv linee guida alla manutenzione per gli sviluppatori
=============================================================
Introduzione
------------
L'insieme di istruzioni RISC-V sono sviluppate in modo aperto: le
bozze in fase di sviluppo sono disponibili a tutti per essere
revisionate e per essere sperimentare nelle implementazioni. Le bozze
dei nuovi moduli o estensioni possono cambiare in fase di sviluppo - a
volte in modo incompatibile rispetto a bozze precedenti. Questa
flessibilità può portare a dei problemi di manutenzioni per il
supporto RISC-V nel kernel Linux. I manutentori Linux non amano
l'abbandono del codice, e il processo di sviluppo del kernel
preferisce codice ben revisionato e testato rispetto a quello
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
-------------------------------------------------------------------------
Accetteremo le patch per un nuovo modulo o estensione se la fondazione
RISC-V li classifica come "Frozen" o "Retified". (Ovviamente, gli
sviluppatori sono liberi di mantenere una copia del kernel Linux
contenente il codice per una bozza di estensione).
In aggiunta, la specifica RISC-V permette agli implementatori di
creare le proprie estensioni. Queste estensioni non passano
attraverso il processo di revisione della fondazione RISC-V. Per
questo motivo, al fine di evitare complicazioni o problemi di
prestazioni, accetteremo patch solo per quelle estensioni che sono
state ufficialmente accettate dalla fondazione RISC-V. (Ovviamente,
gli implementatori sono liberi di mantenere una copia del kernel Linux
contenente il codice per queste specifiche estensioni).
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.