1.. SPDX-License-Identifier: GPL-2.0 2 3============================================================== 4Lista de verificação para submissão de patches do kernel Linux 5============================================================== 6 7Aqui estão algumas coisas básicas que os desenvolvedores devem fazer se 8quiserem ver suas submissões de patches de kernel aceitas mais rapidamente. 9 10Estas diretrizes vão além da documentação fornecida em 11:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 12e em outros locais sobre o envio de patches para o kernel Linux. 13 14Revise seu código 15================= 16 171) Se você usar um recurso, faça o #include do arquivo que define/declara 18 esse recurso. Não dependa de outros arquivos de cabeçalho que incluam 19 os que você usa de forma indireta. 20 212) Verifique o estilo geral do seu patch conforme detalhado em 22 :ref:`Documentation//process/coding-style.rst <codingstyle>`. 23 243) Todas as barreiras de memória {por exemplo, ``barrier()``, ``rmb()``, 25 ``wmb()``} precisam de um comentário no código-fonte que explique a 26 lógica do que estão fazendo e o porquê. 27 28Revise as alterações do Kconfig 29=============================== 30 311) Quaisquer novas ou modificadas opções de ``CONFIG`` não bagunçam o 32 menu de configuração e têm 'desativado' (off) como padrão, a menos que 33 atendam aos critérios de exceção documentados em 34 ``Documentation/kbuild/kconfig-language.rst``, atributos de menu: valor 35 padrão. 36 372) Todas as novas opções de ``Kconfig`` possuem texto de ajuda. 38 393) Foram cuidadosamente revisadas com relação às combinações relevantes de 40 ``Kconfig``. Isso é muito difícil de acertar apenas com testes --- exige 41 capacidade de raciocínio. 42 pays off here. 43 44Forneça documentação 45==================== 46 471) Inclua :ref:`kernel-doc <kernel_doc>` para documentar as APIs globais 48 do kernel. (Não é obrigatório para funções estáticas, mas também é 49 aceitável nelas.) 50 512) Todas as novas entradas em ``/proc`` devem ser documentadas sob 52 ``Documentation/``. 53 543) Todos os novos parâmetros de inicialização (boot) do kernel devem ser 55 documentados em ``Documentation/admin-guide/kernel-parameters.rst``. 56 574) Todos os novos parâmetros de módulo devem ser documentados com 58 ``MODULE_PARM_DESC()``. 59 605) Todas as novas interfaces com o espaço de usuário (userspace) devem ser 61 documentadas em ``Documentation/ABI/``. Consulte 62 ``Documentation/admin-guide/abi.rst`` (ou ``Documentation/ABI/README``) 63 para obter mais informações. Patches que alteram interfaces de espaço 64 de usuário devem incluir em cópia (CC) linux-api@vger.kernel.org. 65 666) Se quaisquer ioctls forem adicionados pelo patch, atualize também 67 ``Documentation/userspace-api/ioctl/ioctl-number.rst``. 68 69Verifique seu código com ferramentas 70==================================== 71 721) Verifique se há violações triviais com o verificador de estilo de patch 73 antes do envio (``scripts/checkpatch.pl``). Você deve ser capaz de 74 justificar todas as violações que permanecerem no seu patch. 75 762) Faça uma verificação limpa com o sparse. 77 783) Use ``make checkstack`` e corrija quaisquer problemas encontrados por ele. 79 Observe que o ``checkstack`` não aponta problemas explicitamente, mas 80 qualquer função individual que utilize mais de 512 bytes na pilha é uma 81 candidata a alteração. 82 83Compile seu código 84================== 85 861) Compila de forma limpa: 87 88 a) com as opções de ``CONFIG`` aplicáveis ou modificadas definidas como 89 ``=y``, ``=m`` e ``=n``. Sem avisos/erros do ``gcc``, sem avisos/erros do 90 vinculador (linker). 91 92 b) Passa em ``allnoconfig``, ``allmodconfig`` 93 94 c) Compila com sucesso ao usar ``O=builddir`` 95 96 d) Quaisquer alterações em Documentation/ compilam com sucesso sem novos 97 avisos/erros. Use ``make htmldocs`` ou ``make pdfdocs`` para verificar 98 a compilação e corrigir quaisquer problemas. 99 1002) Compila em múltiplas arquiteturas de CPU usando ferramentas locais de 101 compilação cruzada (cross-compile) ou alguma outra fazenda de compilação 102 (build farm). 103 Observe que testar em arquiteturas de diferentes tamanhos de palavra 104 (32 e 64 bits) e diferentes endianness (big- e little-endian) é eficaz 105 para capturar vários problemas de portabilidade decorrentes de falsas 106 suposições sobre o intervalo de quantidade representável, alinhamento 107 de dados ou endianness, entre outros. 108 1093) O novo código adicionado foi compilado com ``gcc -W`` (use 110 ``make KCFLAGS=-W``). Isso gerará muito ruído, mas é bom para encontrar 111 bugs como "warning: comparison between signed and unsigned". 112 1134) Se o seu código-fonte modificado depender ou usar quaisquer APIs ou 114 recursos do kernel relacionados aos seguintes símbolos do ``Kconfig``, 115 teste múltiplas compilações com os símbolos relacionados do ``Kconfig`` 116 desativados e/ou definidos como ``=m`` (se essa opção estiver disponível) 117 [não todos ao mesmo tempo, apenas combinações variadas/aleatórias deles]: 118 119 ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, 120 ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, 121 ``CONFIG_NET``, ``CONFIG_INET=n`` (mas este último com ``CONFIG_NET=y``). 122 123Teste seu código 124================ 125 1261) Foi testado com ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 127 ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, 128 ``CONFIG_DEBUG_MUTEXES``, ``CONFIG_DEBUG_SPINLOCK``, 129 ``CONFIG_DEBUG_ATOMIC_SLEEP``, ``CONFIG_PROVE_RCU`` e 130 ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` todos habilitados simultaneamente. 131 1322) Foi testado em tempo de compilação e de execução com e sem ``CONFIG_SMP`` 133 e ``CONFIG_PREEMPT``. 134 1353) Todos os caminhos de código foram executados com todos os recursos de 136 lockdep ativados. 137 1384) Foi verificado com a injeção de falhas de pelo menos slab e alocação de 139 páginas. Consulte ``Documentation/fault-injection/``. 140 Se o novo código for substancial, a adição de injeção de falhas específica 141 do subsistema pode ser apropriada. 142 1435) Testado com a tag mais recente do linux-next para garantir que ele ainda 144 funcione com todos os outros patches enfileirados e com várias alterações 145 na VM, VFS e outros subsistemas. 146