* [PATCH v1 1/3] docs: translations: pt_BR: process: add driver_development_debugging_guide
2026-10-13 23:45 [PATCH v1 0/3] docs: translations: pt_BR: Add process documentation Lucas Adryell Ramalho
@ 2026-10-13 23:45 ` Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 2/3] docs: translations: pt_BR: process: Translate researcher-guidelines.rst Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 3/3] docs: translations: pt_BR: Translate stable-kernel-rules.rst Lucas Adryell Ramalho
2 siblings, 0 replies; 4+ messages in thread
From: Lucas Adryell Ramalho @ 2026-10-13 23:45 UTC (permalink / raw)
To: Daniel Pereira, Jonathan Corbet
Cc: Shuah Khan, Randy Dunlap, linux-doc, linux-kernel,
Lucas Adryell Ramalho
Translate driver_development_debugging_guide and add to debugging/index.rst.
Signed-off-by: Lucas Adryell Ramalho <lucasadramalho@gmail.com>
---
.../driver_development_debugging_guide.rst | 244 ++++++++++++++++++
.../pt_BR/process/debugging/index.rst | 6 +-
2 files changed, 249 insertions(+), 1 deletion(-)
create mode 100644 Documentation/translations/pt_BR/process/debugging/driver_development_debugging_guide.rst
diff --git a/Documentation/translations/pt_BR/process/debugging/driver_development_debugging_guide.rst b/Documentation/translations/pt_BR/process/debugging/driver_development_debugging_guide.rst
new file mode 100644
index 000000000..4d0613ddf
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/debugging/driver_development_debugging_guide.rst
@@ -0,0 +1,244 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================================
+Orientações de depuração para o desenvolvimento de drivers
+==========================================================
+
+Este documento serve como ponto de partida e referência geral para a
+depuração de drivers de dispositivos.
+Enquanto este guia se concentra na depuração que exige recompilar o
+módulo ou o kernel, o :doc:`guia de depuração em espaço de usuário
+</process/debugging/userspace_debugging_guide>` orienta sobre ferramentas
+como depuração dinâmica, Ftrace e outras ferramentas úteis para investigar
+problemas e analisar comportamentos.
+Para orientações gerais sobre depuração, consulte o
+:doc:`guia geral de depuração </process/debugging/index>`.
+
+.. contents::
+ :depth: 3
+
+As seções a seguir mostram as ferramentas disponíveis.
+
+printk() e amigos
+-----------------
+
+Esses derivados de printf() podem enviar mensagens a destinos diferentes e
+podem ser ativados ou desativados dinamicamente, quando há suporte para isso.
+
+Simples printk()
+~~~~~~~~~~~~~~~~
+
+O método clássico é simples e pode ser muito útil para desenvolver módulos
+rapidamente ou extrair dados necessários para investigar problemas.
+
+Pré-requisito: ``CONFIG_PRINTK`` (geralmente habilitado por padrão)
+
+**Prós**:
+
+- Não há necessidade de aprender nada, simples de usar
+- Fácil de adaptar às suas necessidades, incluindo a formatação dos dados
+ (consulte :doc:`/core-api/printk-formats`) e a visibilidade no log
+- Pode causar atrasos na execução do código (benéfico para confirmar se o
+ tempo é um fator)
+
+**Contras**:
+
+- Requer reconstrução do kernel/módulo
+- Pode causar atrasos na execução do código (o que pode fazer com que os
+ problemas não sejam reproduzíveis)
+
+Para a documentação completa, consulte :doc:`/core-api/printk-basics`.
+
+trace_printk()
+~~~~~~~~~~~~~~
+
+Pré-requisito: ``CONFIG_DYNAMIC_FTRACE`` & ``#include <linux/ftrace.h>``
+
+É um pouco menos confortável de usar que printk(), porque as mensagens devem
+ser lidas no arquivo de rastreamento (consulte :ref:`read_ftrace_log`),
+em vez de no log do kernel. Ainda assim, é muito útil quando printk() causa
+atrasos indesejados na execução do código, tornando os problemas intermitentes
+ou difíceis de reproduzir.
+
+Se isso ainda causar problemas de temporização, tente trace_puts().
+
+Para a documentação completa, consulte trace_printk().
+
+dev_dbg
+~~~~~~~
+
+Chamada de depuração que pode ser controlada por
+:ref:`process/debugging/userspace_debugging_guide:dynamic debug` e inclui
+informações adicionais sobre o dispositivo associado.
+
+**Quando é apropriado manter uma mensagem de depuração no código?**
+
+
+As mensagens de depuração permanentes devem ajudar o desenvolvedor a investigar
+problemas no funcionamento do driver. Avaliar quais mensagens são úteis é mais
+uma arte do que uma ciência, mas algumas diretrizes estão nas
+:ref:`Diretrizes de estilo de codificação
+<translations/pt_BR/process/coding-style:13) Imprimindo mensagens do kernel>`.
+Em quase todos os casos, as mensagens de depuração não devem ser enviadas
+ao upstream, pois um driver funcional deve ser silencioso.
+
+printk personalizado
+~~~~~~~~~~~~~~~~~~~~
+
+Exemplo::
+
+ #define core_dbg(fmt, arg...) do { \
+ if (core_debug) \
+ printk(KERN_DEBUG pr_fmt("core: " fmt), ## arg); \
+ } while (0)
+
+**Quando você deve fazer isso?**
+
+É melhor usar pr_debug(), que pode ser ativado ou desativado posteriormente
+com a depuração dinâmica. Além disso, muitos drivers ativam essas mensagens
+por meio de uma variável como ``core_debug``, definida por um parâmetro do
+módulo. No entanto, os parâmetros de módulo `não são mais recomendados
+<https://lore.kernel.org/all/2024032757-surcharge-grime-d3dd@gregkh>`_.
+
+Ftrace
+------
+
+Criando um ponto de rastreamento Ftrace personalizado
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Um ponto de rastreamento adiciona um gancho ao seu código que será chamado e
+registrado quando o ponto de rastreamento estiver ativado. Isso pode ser usado,
+por exemplo, para rastrear a execução de um ramo condicional ou para gerar um
+dump do estado interno em pontos específicos do fluxo do código durante uma
+sessão de depuração.
+
+Aqui está uma descrição básica de
+:ref:`como implementar novos pontos de rastreamento
+<trace/tracepoints:usage>`.
+
+Para a documentação completa sobre rastreamento de eventos, consulte
+:doc:`/trace/events`.
+
+Para a documentação completa do Ftrace, consulte :doc:`/trace/ftrace`.
+
+DebugFS
+-------
+
+Pré-requisito: ``CONFIG_DEBUG_FS`` e ``#include <linux/debugfs.h>``
+
+O DebugFS difere das outras abordagens de depuração, pois não grava mensagens
+no log do kernel nem adiciona rastros ao código. Em vez disso, permite que o
+desenvolvedor gerencie um conjunto de arquivos.
+Com esses arquivos, é possível armazenar valores de variáveis ou gerar
+dumps de registros/memória, ou ainda tornar esses arquivos graváveis e modificar
+valores/configurações no driver.
+
+Possíveis casos de uso, entre outros:
+
+- Armazenar valores de registros
+- Acompanhar variáveis
+- Armazenar erros
+- Armazenar configurações
+- Ativar ou desativar uma configuração, como o modo de depuração
+- Injeção de erros
+
+Isso é especialmente útil quando o tamanho de um dump de dados dificultaria
+sua análise como parte do log geral do kernel (por exemplo, ao despejar dados
+brutos de um fluxo de bits) ou quando você não precisa acompanhar todos os
+valores continuamente, mas quer poder inspecioná-los quando necessário.
+
+A ideia geral é:
+
+- Criar um diretório durante a execução do ``probe`` (``struct dentry *parent =
+ debugfs_create_dir("my_driver", NULL);``)
+- Criar um arquivo:
+
+ ``debugfs_create_u32("my_value", 444, parent, &my_variable);``
+
+ - Neste exemplo, o arquivo está localizado em
+ ``/sys/kernel/debug/my_driver/my_value`` (com permissões de leitura para
+ usuário/grupo/outros)
+ - Qualquer leitura do arquivo retornará o conteúdo atual da variável
+ ``my_variable``
+
+- Limpe o diretório ao remover o dispositivo
+ (``debugfs_remove(parent);``)
+
+Para a documentação completa, consulte :doc:`/filesystems/debugfs`.
+
+KASAN, UBSAN, lockdep e outros verificadores de erros
+-----------------------------------------------------
+
+KASAN (Kernel Address Sanitizer)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Pré-requisito: ``CONFIG_KASAN``
+
+O KASAN é um detector dinâmico de erros de memória que ajuda a identificar
+bugs de uso após liberação (*use-after-free*) e acessos fora dos limites
+(*out-of-bounds*). Ele utiliza instrumentação em tempo de compilação para
+verificar cada acesso à memória.
+
+Para a documentação completa veja :doc:`/dev-tools/kasan`.
+
+UBSAN (Undefined Behavior Sanitizer)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Pré-requisito: ``CONFIG_UBSAN``
+
+O UBSAN usa instrumentação do compilador e verificações em tempo de execução
+para detectar comportamentos indefinidos. Ele identifica vários problemas,
+incluindo estouro de inteiro com sinal e índice de array fora dos limites.
+
+Para a documentação completa, consulte :doc:`/dev-tools/ubsan`.
+
+lockdep (Lock Dependency Validator)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Pré-requisito: ``CONFIG_DEBUG_LOCKDEP``
+
+O lockdep é um validador de dependências de bloqueio em tempo de execução que
+detecta possíveis deadlocks e outros problemas relacionados a bloqueios no
+kernel. Ele rastreia a aquisição e a liberação de bloqueios, constrói um
+gráfico de dependências e o analisa em busca de possíveis deadlocks. O lockdep
+é especialmente útil para validar a ordem correta dos bloqueios no kernel.
+
+PSI (Pressure stall information tracking)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Pré-requisito: ``CONFIG_PSI``
+
+O PSI é uma ferramenta de medição que identifica a sobrecarga excessiva dos
+recursos de hardware, capaz de causar perda de desempenho ou até encerramentos
+de processos por falta de memória (OOM).
+
+coredump do dispositivo
+-----------------------
+
+Pré-requisito: ``CONFIG_DEV_COREDUMP`` e ``#include <linux/devcoredump.h>``
+
+Essa infraestrutura permite que um driver envie dados arbitrários ao espaço do
+usuário. Ela é usada com frequência em conjunto com o udev ou outro aplicativo
+de espaço de usuário que monitore os uevents do kernel indicando que o dump
+está pronto. O udev pode ter regras para copiar o arquivo para armazenamento e
+análise de longo prazo, pois, por padrão, os dados do dump são removidos após
+cinco minutos. Esses dados são analisados com ferramentas específicas do driver
+ou com o GDB.
+
+Um coredump do dispositivo pode ser criado a partir de uma área vmalloc, com
+métodos de leitura e liberação ou como uma lista scatter/gather.
+
+Você pode encontrar um exemplo de implementação em:
+`drivers/media/platform/qcom/venus/core.c
+<https://elixir.bootlin.com/linux/v6.11.6/source/drivers/media/platform/qcom/venus/core.c#L30>`__,
+na camada HCI do Bluetooth, em vários drivers sem fio e em vários
+drivers DRM.
+
+Interfaces do devcoredump
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/devcoredump.h
+
+.. kernel-doc:: drivers/base/devcoredump.c
+
+**Copyright** ©2024 : Collabora
diff --git a/Documentation/translations/pt_BR/process/debugging/index.rst b/Documentation/translations/pt_BR/process/debugging/index.rst
index b223fae34..5c2c73493 100644
--- a/Documentation/translations/pt_BR/process/debugging/index.rst
+++ b/Documentation/translations/pt_BR/process/debugging/index.rst
@@ -7,9 +7,13 @@ Dicas de depuração para desenvolvedores do Kernel Linux
Guias gerais
------------
+.. toctree::
+ :maxdepth: 1
+
+ Orientações de depuração para o desenvolvimento de drivers <driver_development_debugging_guide>
+
Todolist:
-* driver_development_debugging_guide
* gdb-kernel-debugging
* kgdb
* userspace_debugging_guide
--
2.55.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH v1 2/3] docs: translations: pt_BR: process: Translate researcher-guidelines.rst
2026-10-13 23:45 [PATCH v1 0/3] docs: translations: pt_BR: Add process documentation Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 1/3] docs: translations: pt_BR: process: add driver_development_debugging_guide Lucas Adryell Ramalho
@ 2026-10-13 23:45 ` Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 3/3] docs: translations: pt_BR: Translate stable-kernel-rules.rst Lucas Adryell Ramalho
2 siblings, 0 replies; 4+ messages in thread
From: Lucas Adryell Ramalho @ 2026-10-13 23:45 UTC (permalink / raw)
To: Daniel Pereira, Jonathan Corbet
Cc: Shuah Khan, Randy Dunlap, linux-doc, linux-kernel,
Lucas Adryell Ramalho
Translate researcher-guidelines.rst into Brazilian Portuguese
and add it to the process documentation index.
Signed-off-by: Lucas Adryell Ramalho <lucasadramalho@gmail.com>
---
.../translations/pt_BR/process/index.rst | 1 +
.../pt_BR/process/researcher-guidelines.rst | 188 ++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/researcher-guidelines.rst
diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
index d072f7e46..31704e28d 100644
--- a/Documentation/translations/pt_BR/process/index.rst
+++ b/Documentation/translations/pt_BR/process/index.rst
@@ -64,6 +64,7 @@ Estas são as regras pelas quais tentamos viver na comunidade do kernel
Declaração sobre Drivers do Kernel <kernel-driver-statement>
A interface de drivers do kernel Linux <stable-api-nonsense>
Estilo de gerenciamento do kernel Linux <management-style>
+ Diretrizes para pesquisadores <researcher-guidelines>
Assistentes de código <coding-assistants>
O manual da árvore tip <maintainer-tip>
Conclave (Continuidade do projeto) <conclave>
diff --git a/Documentation/translations/pt_BR/process/researcher-guidelines.rst b/Documentation/translations/pt_BR/process/researcher-guidelines.rst
new file mode 100644
index 000000000..8209b0e17
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/researcher-guidelines.rst
@@ -0,0 +1,188 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_researcher-guidelines:
+
+Diretrizes para pesquisadores
++++++++++++++++++++++++++++++
+
+A comunidade do kernel do Linux acolhe com satisfação pesquisas
+transparentes sobre o kernel do Linux, as atividades envolvidas em seu
+desenvolvimento e quaisquer outros subprodutos de seu desenvolvimento. O
+Linux se beneficia enormemente desse tipo de pesquisa, e a maioria dos
+aspectos do Linux é impulsionada por pesquisas, de uma forma ou de outra.
+
+A comunidade agradece imensamente se os pesquisadores puderem compartilhar
+descobertas preliminares antes de tornar seus resultados públicos,
+especialmente se tal pesquisa envolver segurança. O envolvimento antecipado
+da comunidade ajuda a melhorar tanto a qualidade da pesquisa quanto a
+capacidade do Linux de se beneficiar de seus resultados. De qualquer forma,
+recomenda-se compartilhar com a comunidade cópias de acesso aberto das
+pesquisas publicadas.
+
+Este documento tem como objetivo esclarecer o que a comunidade do kernel
+Linux considera práticas aceitáveis e inaceitáveis na condução desse tipo
+de pesquisa. No mínimo, tais pesquisas e atividades relacionadas devem
+seguir os princípios fundamentais da ética em pesquisa. Para obter mais
+informações sobre ética em pesquisa em geral, ética em tecnologia e
+pesquisa sobre comunidades de desenvolvedores em particular, consulte:
+
+* `História da Ética em Pesquisa
+ <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
+* `Ética do IEEE <https://www.ieee.org/about/ethics/index.html>`_
+* `Opiniões de desenvolvedores e pesquisadores sobre a ética de
+ experimentos em projetos de código aberto
+ <https://arxiv.org/pdf/2112.13217.pdf>`_
+
+A comunidade do kernel Linux espera que todos os que interagem com o
+projeto estejam participando de boa-fé para tornar o Linux melhor.
+Pesquisas sobre qualquer material disponível publicamente (incluindo, mas
+não se limitando ao código-fonte) produzido pela comunidade do kernel Linux
+são bem-vindas, embora pesquisas envolvendo desenvolvedores exijam
+consentimento explícito dos participantes.
+
+Pesquisas passivas baseadas inteiramente em fontes publicamente
+disponíveis, incluindo postagens em listas de discussão públicas e commits
+em repositórios públicos, são claramente permitidas. No entanto, como em
+qualquer pesquisa, os princípios éticos padrão devem ser seguidos.
+
+A pesquisa ativa sobre o comportamento dos desenvolvedores, no entanto,
+deve ser realizada com o consentimento explícito e a plena divulgação aos
+desenvolvedores individuais envolvidos. Não é permitido interagir com os
+desenvolvedores ou realizar experimentos com eles sem o consentimento; isso
+também faz parte da ética padrão da pesquisa.
+
+Questionários
+=============
+
+A pesquisa geralmente assume a forma de questionários enviados a
+mantenedores ou colaboradores. Como regra geral, porém, a comunidade do
+kernel obtém pouco valor desses questionários. O processo de
+desenvolvimento do kernel funciona porque cada desenvolvedor se beneficia
+de sua participação, mesmo trabalhando com outras pessoas que têm objetivos
+diferentes. Responder a um questionário, porém, é uma exigência unilateral
+imposta a desenvolvedores ocupados, sem nenhum benefício correspondente
+para eles próprios ou para a comunidade do kernel como um todo. Por esse
+motivo, esse método de pesquisa não é recomendado.
+
+Os membros da comunidade do kernel já recebem e-mails em excesso e
+provavelmente perceberão os pedidos de pesquisa como apenas mais uma
+exigência sobre seu tempo. O envio desses pedidos priva a comunidade do
+valioso tempo dos colaboradores e é improvável que gere uma resposta
+estatisticamente útil.
+
+Como alternativa, os pesquisadores devem considerar participar de eventos
+de desenvolvedores, organizar sessões nas quais o projeto de pesquisa e
+seus benefícios para os participantes possam ser explicados e interagir
+diretamente com a comunidade no local. As informações recebidas serão
+muito mais ricas do que as obtidas por meio de uma pesquisa por e-mail, e a
+comunidade também se beneficiará da oportunidade de aprender com suas
+percepções.
+
+Patches
+=======
+
+Para ajudar a esclarecer: enviar patches aos desenvolvedores *é* interagir
+com eles, mas eles já consentiram em receber *contribuições de boa-fé*.
+Esse consentimento não se estende ao envio de patches intencionalmente
+defeituosos ou vulneráveis, nem ao fornecimento de informações enganosas
+durante as discussões. Essas interações podem prejudicar os desenvolvedores
+ao consumir tempo, esforço e motivação, além de prejudicar o projeto ao
+minar a confiança de toda a comunidade de desenvolvedores no colaborador (e
+na organização do colaborador como um todo), prejudicando os esforços para
+fornecer feedback construtivo aos colaboradores e colocando os usuários
+finais em risco de falhas de software.
+
+A participação de pesquisadores no desenvolvimento do próprio Linux, assim
+como a de qualquer pessoa, é bem-vinda e incentivada. A pesquisa no código
+do Linux é uma prática comum, especialmente quando se trata de desenvolver
+ou executar ferramentas de análise que produzam resultados que possam ser
+utilizados na prática.
+
+Ao interagir com a comunidade de desenvolvedores, enviar um patch tem sido,
+tradicionalmente, a melhor maneira de causar impacto. O Linux já possui
+muitos bugs conhecidos — o que é muito mais útil é dispor de correções
+revisadas e verificadas. Antes de contribuir, leia atentamente a
+documentação apropriada:
+
+* Documentation/process/development-process.rst
+* Documentation/process/submitting-patches.rst
+* Documentation/admin-guide/reporting-issues.rst
+* Documentation/process/security-bugs.rst
+
+Em seguida, envie um patch (incluindo uma mensagem de commit com todos os
+detalhes listados abaixo) e responda aos comentários dos outros
+desenvolvedores.
+
+Ao enviar patches resultantes de pesquisas, as mensagens de commit devem
+conter, no mínimo, os seguintes detalhes, para que os desenvolvedores
+tenham o contexto adequado para compreender a contribuição. Responda às
+seguintes perguntas:
+
+* Qual é o problema específico que foi identificado?
+* Como o problema poderia ser reproduzido em um sistema em execução?
+* Que efeito a ocorrência do problema teria no sistema?
+* Como o problema foi identificado? Inclua, especificamente, detalhes sobre
+ quaisquer testes, programas de análise estática ou dinâmica e quaisquer
+ outras ferramentas ou métodos utilizados para realizar o trabalho.
+* Em qual versão do Linux o problema foi identificado? É altamente
+ recomendável utilizar a versão mais recente ou um ramo recente do
+ linux-next (consulte Documentation/process/howto.rst).
+* O que foi alterado para corrigir o problema e por que se acredita que a
+ correção esteja correta?
+* Como a alteração foi testada na compilação e em tempo de execução?
+* Qual commit anterior esta alteração corrige? Isso deve constar na tag
+ “Fixes:” conforme descrito na documentação.
+* Quem mais revisou este patch? Isso deve constar nas tags apropriadas
+ “Reviewed-by:”; veja abaixo.
+
+Por exemplo::
+
+ From: Author <author@email>
+ Subject: [PATCH] drivers/foo_bar: Add missing kfree()
+
+ The error path in foo_bar driver does not correctly free the allocated
+ struct foo_bar_info. This can happen if the attached foo_bar device
+ rejects the initialization packets sent during foo_bar_probe(). This
+ would result in a 64 byte slab memory leak once per device attach,
+ wasting memory resources over time.
+
+ This flaw was found using an experimental static analysis tool we are
+ developing, LeakMagic[1], which reported the following warning when
+ analyzing the v5.15 kernel release:
+
+ path/to/foo_bar.c:187: missing kfree() call?
+
+ Add the missing kfree() to the error path. No other references to
+ this memory exist outside the probe function, so this is the only
+ place it can be freed.
+
+ x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
+ 11.2 show no new warnings, and LeakMagic no longer warns about this
+ code path. As we don't have a FooBar device to test with, no runtime
+ testing was able to be performed.
+
+ [1] https://url/to/leakmagic/details
+
+ Reported-by: Researcher <researcher@email>
+ Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
+ Signed-off-by: Author <author@email>
+ Reviewed-by: Reviewer <reviewer@email>
+
+Se você estiver contribuindo pela primeira vez, recomenda-se que o patch
+seja avaliado por outras pessoas em particular antes de ser enviado às
+listas de discussão públicas.
+(Isso é obrigatório caso tenha sido explicitamente informado de que seus
+patches precisam de uma revisão interna mais cuidadosa.) Espera-se que
+essas pessoas tenham sua tag “Reviewed-by” incluída no patch resultante.
+Encontrar outro desenvolvedor familiarizado com contribuições para o Linux,
+especialmente dentro da sua própria organização, e pedir que ele ajude nas
+revisões antes de enviá-las para as listas de discussão públicas tende a
+melhorar significativamente a qualidade dos patches resultantes e, com isso,
+reduz a carga de trabalho sobre outros desenvolvedores.
+
+Se não for possível encontrar ninguém para revisar os patches internamente
+e você precisar de ajuda para encontrar essa pessoa, ou se tiver quaisquer
+outras dúvidas relacionadas a este documento e às expectativas da
+comunidade de desenvolvedores, entre em contato com a lista de discussão
+privada do Conselho Consultivo Técnico:
+<tech-board@groups.linuxfoundation.org>.
--
2.55.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH v1 3/3] docs: translations: pt_BR: Translate stable-kernel-rules.rst
2026-10-13 23:45 [PATCH v1 0/3] docs: translations: pt_BR: Add process documentation Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 1/3] docs: translations: pt_BR: process: add driver_development_debugging_guide Lucas Adryell Ramalho
2026-10-13 23:45 ` [PATCH v1 2/3] docs: translations: pt_BR: process: Translate researcher-guidelines.rst Lucas Adryell Ramalho
@ 2026-10-13 23:45 ` Lucas Adryell Ramalho
2 siblings, 0 replies; 4+ messages in thread
From: Lucas Adryell Ramalho @ 2026-10-13 23:45 UTC (permalink / raw)
To: Daniel Pereira, Jonathan Corbet
Cc: Shuah Khan, Randy Dunlap, linux-doc, linux-kernel,
Lucas Adryell Ramalho
Translate the stable kernel rules documentation into Brazilian Portuguese.
Signed-off-by: Lucas Adryell Ramalho <lucasadramalho@gmail.com>
---
.../translations/pt_BR/process/index.rst | 1 +
.../pt_BR/process/stable-kernel-rules.rst | 258 ++++++++++++++++++
2 files changed, 259 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/stable-kernel-rules.rst
diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
index 31704e28d..29f6c7735 100644
--- a/Documentation/translations/pt_BR/process/index.rst
+++ b/Documentation/translations/pt_BR/process/index.rst
@@ -63,6 +63,7 @@ Estas são as regras pelas quais tentamos viver na comunidade do kernel
Declaração de Aplicação do Kernel Linux <kernel-enforcement-statement>
Declaração sobre Drivers do Kernel <kernel-driver-statement>
A interface de drivers do kernel Linux <stable-api-nonsense>
+ Tudo o que você sempre quis saber sobre as versões estáveis do Linux <stable-kernel-rules>
Estilo de gerenciamento do kernel Linux <management-style>
Diretrizes para pesquisadores <researcher-guidelines>
Assistentes de código <coding-assistants>
diff --git a/Documentation/translations/pt_BR/process/stable-kernel-rules.rst b/Documentation/translations/pt_BR/process/stable-kernel-rules.rst
new file mode 100644
index 000000000..103108be4
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/stable-kernel-rules.rst
@@ -0,0 +1,258 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_BR_stable_kernel_rules:
+
+Tudo o que você sempre quis saber sobre as versões estáveis do Linux
+====================================================================
+
+Regras sobre quais tipos de correções são aceitos na árvore "-stable" e
+quais não são:
+
+- A correção, ou uma equivalente, já deve existir na linha principal do
+ Linux (upstream).
+- Deve estar obviamente correta e ter sido testada.
+- Não pode ter mais de 100 linhas, incluindo o contexto.
+- Deve seguir as regras de
+ :ref:`Documentation/translations/pt_BR/process/submitting-patches.rst
+ <submittingpatches>`.
+- Deve corrigir um erro real que afete as pessoas ou apenas adicionar um ID
+ de dispositivo. Em mais detalhes, o primeiro caso inclui:
+
+ - Corrigir um problema como um oops, travamento, corrupção de dados,
+ problema real de segurança, peculiaridade de hardware, erro de
+ compilação (exceto itens CONFIG_BROKEN) ou algum problema do tipo "isso
+ não é nada bom".
+ - Problemas graves relatados por usuários de um kernel de distribuição
+ também podem ser considerados se as correções resolverem um problema
+ notável de desempenho ou interatividade. Como essas correções não são
+ tão óbvias e apresentam maior risco de causar uma regressão sutil, elas
+ só devem ser enviadas pelo mantenedor do kernel da distribuição e
+ devem incluir um complemento com um link para uma entrada no Bugzilla,
+ se houver, e informações adicionais sobre o impacto percebido pelo
+ usuário.
+ - Não são aceitos problemas do tipo "isto pode ser um problema...", como
+ uma "condição de corrida teórica", a menos que também seja fornecida
+ uma explicação de como o erro pode ser explorado.
+ - Não são aceitas correções "triviais" sem benefício para os usuários
+ (alterações ortográficas, limpeza de espaços em branco etc.).
+
+
+Procedimento para enviar correções à árvore -stable
+----------------------------------------------------
+
+.. note::
+
+ Correções de segurança não devem ser tratadas exclusivamente pelo
+ processo de revisão -stable; devem seguir os procedimentos em
+ :ref:`Documentation/translations/pt_BR/process/security-bugs.rst
+ <securitybugs>`.
+
+Há três opções para enviar uma alteração às árvores -stable:
+
+1. Adicionar uma "stable tag" à descrição de uma correção que será enviada
+ para inclusão na linha principal.
+2. Pedir à equipe stable que inclua uma correção já integrada à linha
+ principal.
+3. Enviar à equipe stable uma correção equivalente a uma alteração já
+ integrada à linha principal.
+
+As seções abaixo descrevem cada opção em mais detalhes.
+
+A :ref:`pt_BR_option_1` é **fortemente** preferida; é a opção mais fácil e
+mais comum.
+A :ref:`pt_BR_option_2` destina-se principalmente a alterações para as
+quais o backport não foi considerado no momento do envio.
+A :ref:`pt_BR_option_3` é uma alternativa às opções anteriores quando uma
+correção integrada à linha principal precisa de ajustes para ser aplicada
+a séries mais antigas (por exemplo, devido a alterações na API).
+
+Ao usar a opção 2 ou 3, você pode pedir que sua alteração seja incluída em
+séries stable específicas. Nesse caso, certifique-se de que a correção ou
+uma equivalente seja aplicável, tenha sido enviada ou já esteja presente em
+todas as árvores stable mais novas que ainda recebem suporte. Isso evita
+regressões que os usuários poderiam encontrar ao atualizar. Por exemplo,
+uma correção integrada para 5.19-rc1 poderia ser portada para
+5.10.y, mas não para 5.15.y.
+
+.. _pt_BR_option_1:
+
+Opção 1
+*******
+
+Para que uma correção enviada para inclusão na linha principal seja
+selecionada automaticamente depois pelas árvores stable, adicione esta
+etiqueta à seção de assinaturas (sign-off)::
+
+ Cc: stable@vger.kernel.org
+
+Use ``Cc: stable@kernel.org`` em vez disso ao corrigir vulnerabilidades
+ainda não divulgadas: isso reduz a chance de expor acidentalmente a
+correção ao público por meio do 'git send-email', pois as mensagens
+enviadas a esse endereço não são entregues.
+
+Depois que a correção for integrada à linha principal, ela será aplicada à
+árvore stable sem que o autor ou o mantenedor do subsistema precise fazer
+mais nada.
+
+Para enviar instruções adicionais à equipe stable, use um comentário em
+linha no estilo do shell para passar observações arbitrárias ou
+predefinidas:
+
+* Especifique pré-requisitos adicionais para a seleção por cherry-pick::
+
+ Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+ Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+ Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+ Cc: <stable@vger.kernel.org> # 3.3.x
+ Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+ A sequência de etiquetas indica que se deve executar::
+
+ git cherry-pick a1f84a3
+ git cherry-pick 1b9508f
+ git cherry-pick fd21073
+ git cherry-pick <this commit>
+
+ Observe que, em uma série de correções, não é necessário listar como
+ pré-requisitos as correções que fazem parte da própria série. Por
+ exemplo, nesta série::
+
+ patch1
+ patch2
+
+ patch2 depende de patch1, mas não é necessário listar patch1 como
+ pré-requisito de patch2 se você já tiver marcado patch1 para inclusão no
+ stable.
+
+* Indique os pré-requisitos de versão do kernel::
+
+ Cc: <stable@vger.kernel.org> # 3.3.x
+
+ A etiqueta indica que se deve executar::
+
+ git cherry-pick <this commit>
+
+ em cada árvore -stable a partir da versão especificada.
+
+ Observe que essa etiqueta é desnecessária se a equipe stable puder
+ deduzir as versões apropriadas a partir das etiquetas Fixes:.
+
+* Adiar a inclusão de correções::
+
+ Cc: <stable@vger.kernel.org> # after -rc3
+
+* Aponte problemas conhecidos::
+
+ Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
+
+Também há uma variante da etiqueta stable que pode ser usada para fazer com
+que as ferramentas de backport da equipe stable (por exemplo, AUTOSEL ou
+scripts que procuram commits com uma etiqueta 'Fixes:') ignorem uma
+alteração::
+
+ Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
+
+.. _pt_BR_option_2:
+
+Opção 2
+*******
+
+Se a correção já tiver sido integrada à linha principal, envie um e-mail
+para stable@vger.kernel.org com o assunto da correção, o ID do commit, o
+motivo pelo qual você acredita que ela deve ser aplicada e as versões do
+kernel às quais deve ser aplicada.
+
+.. _pt_BR_option_3:
+
+Opção 3
+*******
+
+Depois de verificar que a correção segue as regras acima, envie-a para
+stable@vger.kernel.org e indique as versões do kernel às quais deseja que
+ela seja aplicada. Nesse caso, você deve indicar o ID do commit upstream no
+registro de alterações do envio, em uma linha separada acima do texto do
+commit, assim::
+
+ commit <sha1> upstream.
+
+Ou, alternativamente::
+
+ [ Upstream commit <sha1> ]
+
+Se a correção enviada diferir da correção upstream original (por exemplo,
+porque precisou ser adaptada à API mais antiga), isso deve ser documentado
+e justificado com muita clareza na descrição da correção.
+
+
+Acompanhamento do envio
+-----------------------
+
+O remetente receberá um ACK quando a correção for aceita na fila, ou um NAK
+se for rejeitada. Essa resposta pode levar alguns dias, dependendo da
+disponibilidade dos membros da equipe stable.
+
+Se for aceita, a correção será adicionada à fila -stable para revisão por
+outros desenvolvedores e pelo mantenedor do subsistema relevante.
+
+
+Ciclo de revisão
+----------------
+
+- Quando os mantenedores -stable decidirem iniciar um ciclo de revisão, as
+ correções serão enviadas ao comitê de revisão, ao mantenedor da área
+ afetada pela correção (a menos que o remetente seja o mantenedor dessa
+ área) e em cópia (CC:) para a lista de discussão linux-kernel.
+- O comitê de revisão tem 48 horas para aprovar (ACK) ou rejeitar (NAK) a
+ correção.
+- Se um membro do comitê rejeitar a correção ou membros da lista
+ linux-kernel apresentarem objeções levantando problemas que os
+ mantenedores e os membros não perceberam, a correção será removida da
+ fila.
+- As correções aprovadas serão publicadas novamente como parte de uma
+ versão candidata (-rc), para serem testadas por desenvolvedores e
+ testadores.
+- Geralmente é publicada apenas uma versão -rc. No entanto, se houver
+ problemas pendentes, algumas correções poderão ser modificadas ou
+ removidas, ou outras poderão ser adicionadas à fila. Nesse caso, versões
+ -rc adicionais serão publicadas e testadas até que nenhum problema seja
+ encontrado.
+- É possível responder às versões -rc na lista de discussão enviando um
+ e-mail "Tested-by:" com as informações de teste desejadas. As etiquetas
+ "Tested-by:" serão reunidas e adicionadas ao commit de lançamento.
+- Ao final do ciclo de revisão, a nova versão -stable será lançada com
+ todas as correções enfileiradas e testadas.
+- Correções de segurança serão aceitas diretamente na árvore -stable pela
+ equipe de segurança do kernel e não passarão pelo ciclo normal de
+ revisão. Entre em contato com a equipe de segurança do kernel para saber
+ mais sobre esse procedimento.
+
+
+Árvores
+-------
+
+- As filas de correções, tanto das versões concluídas quanto das versões em
+ andamento, podem ser encontradas em:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+- As versões finalizadas e identificadas por tags de todos os kernels
+ estáveis podem ser encontradas em ramificações separadas por versão em:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+- As versões candidatas de todas as versões do kernel stable podem ser
+ encontradas em:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
+
+ .. warning::
+ A árvore -stable-rc é um instantâneo da árvore stable-queue e muda com
+ frequência; por isso, é rebaseada frequentemente. Ela deve ser usada
+ apenas para testes (por exemplo, por sistemas de integração contínua).
+
+
+Comitê de revisão
+-----------------
+
+- É formado por vários desenvolvedores do kernel que se voluntariaram para
+ essa tarefa e por alguns que não se voluntariaram.
--
2.55.0
^ permalink raw reply related [flat|nested] 4+ messages in thread