Translate the submit-checklist document from Documentation/process/ to Portuguese (pt_BR) to make the kernel contribution guidelines more accessible to Portuguese-speaking developers. Also, add the newly translated file to the main index in the pt_BR translation directory to ensure it compiles and links correctly within the Sphinx build. Signed-off-by: Daniel Pereira --- Documentation/translations/pt_BR/index.rst | 1 + .../pt_BR/process/submit-checklist.rst | 145 ++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 Documentation/translations/pt_BR/process/submit-checklist.rst diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst index 2ab14c5d6..841b49657 100644 --- a/Documentation/translations/pt_BR/index.rst +++ b/Documentation/translations/pt_BR/index.rst @@ -83,3 +83,4 @@ kernel e sobre como ver seu trabalho integrado. Conformidade de DTS para SoC Processo do subsistema KVM x86 Adicionando uma nova chamada de Sistema + Lista de verificação para submissão de patches do kernel Linux diff --git a/Documentation/translations/pt_BR/process/submit-checklist.rst b/Documentation/translations/pt_BR/process/submit-checklist.rst new file mode 100644 index 000000000..003fc9568 --- /dev/null +++ b/Documentation/translations/pt_BR/process/submit-checklist.rst @@ -0,0 +1,145 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================== +Lista de verificação para submissão de patches do kernel Linux +============================================================== + +Aqui estão algumas coisas básicas que os desenvolvedores devem fazer se +quiserem ver suas submissões de patches de kernel aceitas mais rapidamente. + +Estas diretrizes vão além da documentação fornecida em +:ref:`Documentation/process/submitting-patches.rst ` +e em outros locais sobre o envio de patches para o kernel Linux. + +Revise seu código +================= + +1) Se você usar um recurso, faça o #include do arquivo que define/declara + esse recurso. Não dependa de outros arquivos de cabeçalho que incluam + os que você usa de forma indireta. + +2) Verifique o estilo geral do seu patch conforme detalhado em + :ref:`Documentation//process/coding-style.rst `. + +3) Todas as barreiras de memória {por exemplo, ``barrier()``, ``rmb()``, + ``wmb()``} precisam de um comentário no código-fonte que explique a + lógica do que estão fazendo e o porquê. + +Revise as alterações do Kconfig +=============================== + +1) Quaisquer novas ou modificadas opções de ``CONFIG`` não bagunçam o + menu de configuração e têm 'desativado' (off) como padrão, a menos que + atendam aos critérios de exceção documentados em + ``Documentation/kbuild/kconfig-language.rst``, atributos de menu: valor + padrão. + +2) Todas as novas opções de ``Kconfig`` possuem texto de ajuda. + +3) Foram cuidadosamente revisadas com relação às combinações relevantes de + ``Kconfig``. Isso é muito difícil de acertar apenas com testes --- exige + capacidade de raciocínio. + pays off here. + +Forneça documentação +==================== + +1) Inclua :ref:`kernel-doc ` para documentar as APIs globais + do kernel. (Não é obrigatório para funções estáticas, mas também é + aceitável nelas.) + +2) Todas as novas entradas em ``/proc`` devem ser documentadas sob + ``Documentation/``. + +3) Todos os novos parâmetros de inicialização (boot) do kernel devem ser + documentados em ``Documentation/admin-guide/kernel-parameters.rst``. + +4) Todos os novos parâmetros de módulo devem ser documentados com + ``MODULE_PARM_DESC()``. + +5) Todas as novas interfaces com o espaço de usuário (userspace) devem ser + documentadas em ``Documentation/ABI/``. Consulte + ``Documentation/admin-guide/abi.rst`` (ou ``Documentation/ABI/README``) + para obter mais informações. Patches que alteram interfaces de espaço + de usuário devem incluir em cópia (CC) linux-api@vger.kernel.org. + +6) Se quaisquer ioctls forem adicionados pelo patch, atualize também + ``Documentation/userspace-api/ioctl/ioctl-number.rst``. + +Verifique seu código com ferramentas +==================================== + +1) Verifique se há violações triviais com o verificador de estilo de patch + antes do envio (``scripts/checkpatch.pl``). Você deve ser capaz de + justificar todas as violações que permanecerem no seu patch. + +2) Faça uma verificação limpa com o sparse. + +3) Use ``make checkstack`` e corrija quaisquer problemas encontrados por ele. + Observe que o ``checkstack`` não aponta problemas explicitamente, mas + qualquer função individual que utilize mais de 512 bytes na pilha é uma + candidata a alteração. + +Compile seu código +================== + +1) Compila de forma limpa: + + a) com as opções de ``CONFIG`` aplicáveis ou modificadas definidas como + ``=y``, ``=m`` e ``=n``. Sem avisos/erros do ``gcc``, sem avisos/erros do + vinculador (linker). + + b) Passa em ``allnoconfig``, ``allmodconfig`` + + c) Compila com sucesso ao usar ``O=builddir`` + + d) Quaisquer alterações em Documentation/ compilam com sucesso sem novos + avisos/erros. Use ``make htmldocs`` ou ``make pdfdocs`` para verificar + a compilação e corrigir quaisquer problemas. + +2) Compila em múltiplas arquiteturas de CPU usando ferramentas locais de + compilação cruzada (cross-compile) ou alguma outra fazenda de compilação + (build farm). + Observe que testar em arquiteturas de diferentes tamanhos de palavra + (32 e 64 bits) e diferentes endianness (big- e little-endian) é eficaz + para capturar vários problemas de portabilidade decorrentes de falsas + suposições sobre o intervalo de quantidade representável, alinhamento + de dados ou endianness, entre outros. + +3) O novo código adicionado foi compilado com ``gcc -W`` (use + ``make KCFLAGS=-W``). Isso gerará muito ruído, mas é bom para encontrar + bugs como "warning: comparison between signed and unsigned". + +4) Se o seu código-fonte modificado depender ou usar quaisquer APIs ou + recursos do kernel relacionados aos seguintes símbolos do ``Kconfig``, + teste múltiplas compilações com os símbolos relacionados do ``Kconfig`` + desativados e/ou definidos como ``=m`` (se essa opção estiver disponível) + [não todos ao mesmo tempo, apenas combinações variadas/aleatórias deles]: + + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, + ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (mas este último com ``CONFIG_NET=y``). + +Teste seu código +================ + +1) Foi testado com ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, + ``CONFIG_DEBUG_MUTEXES``, ``CONFIG_DEBUG_SPINLOCK``, + ``CONFIG_DEBUG_ATOMIC_SLEEP``, ``CONFIG_PROVE_RCU`` e + ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` todos habilitados simultaneamente. + +2) Foi testado em tempo de compilação e de execução com e sem ``CONFIG_SMP`` + e ``CONFIG_PREEMPT``. + +3) Todos os caminhos de código foram executados com todos os recursos de + lockdep ativados. + +4) Foi verificado com a injeção de falhas de pelo menos slab e alocação de + páginas. Consulte ``Documentation/fault-injection/``. + Se o novo código for substancial, a adição de injeção de falhas específica + do subsistema pode ser apropriada. + +5) Testado com a tag mais recente do linux-next para garantir que ele ainda + funcione com todos os outros patches enfileirados e com várias alterações + na VM, VFS e outros subsistemas. -- 2.47.3